Showing posts with label TESTING LIFE CYCLE. Show all posts
Showing posts with label TESTING LIFE CYCLE. Show all posts

INDEPENDENT SOFTWARE TESTING

The primary responsibility of individuals accountable for testing activities is to ensure that uality is measured accurately.

Often, just knowing that the organization is measuring quality is enough to cause improvements in the applications being developed. In the loosest definition of independence, just having a tester or someone in the organization devoted to test activities is a form of independence.

The roles and reporting structure of test resources differs across and within organizations.

These resources may be business or systems analysts assigned to perform testing activities, or may be testers who report to the project manager. Ideally, the test resources will have a reporting structure independent from the group designing or developing the application in order to assure that the quality of the application is given as much consideration as the project budget and time line.

Misconceptions abound regarding the skill set required to perform testing, including:
  1. • Testing is easy
  2. • Anyone can perform testing
  3. • No training or prior experience is necessary
In truth, to test effectively, an individual must:
  1. Thoroughly understand the system
  2. Thoroughly understand the technology the system is being deployed upon (e.g., client/server or Internet technologies introduce their own challenges)
  3. Possess creativity, insight, and business knowledge
  4. Understand the development methodology used and the resulting artifacts
Often, successful development teams will have a peer perform the unit testing on a program or class. Once a portion of the application is ready for integration testing, the same benefits can be achieved by having an independent person plan and coordinate the integration testing.

Where an independent test team exists, they are usually responsible for system testing, the oversight of acceptance testing, and providing an unbiased assessment of the quality of an application. The team may also support or participate in other phases of testing as well as executing special test types such as performance and load testing.

An independent test team is usually comprised of a test manager or team leader and a team of testers. The test manager should join the team no later than the start of the requirements definition stage.

Key testers may also join the team at this stage on large projects to assist with test planning activities. Other testers can join later to assist with the creation of test cases and scripts, and right before system testing is scheduled to begin.

The test manager ensures that testing is performed, that it is documented, and that testing techniques are established and developed. They are responsible for ensuring that tests are designed and executed in a timely and productive manner, as well as:
  1. Test planning and estimation
  2. Designing the test strategy
  3. Reviewing analysis and design artifacts
  4. Chairing the Test Readiness Review
  5. Managing the test effort
  6. Overseeing acceptance tests
Testers are usually responsible for:
  1. Developing test cases and procedures
  2. Test data planning, capture, and conditioning
  3. Reviewing analysis and design artifacts
  4. Testing execution
  5. Utilizing automated test tools for regression testing
  6. Preparing test documentation
  7. Defect tracking and reporting
Other testers joining the team will primarily focus on test execution, defect reporting, and regression testing. These testers may be junior members of the test team, users, marketing or
product representatives, and so on.

The test team should be represented in all key requirements and design meetings including:
  1. JAD or requirements definition sessions
  2. Risk analysis sessions
  3. Prototype review sessions

They should also participate in all inspections or walkthroughs for requirements and design artifacts.

The previous post is regarding software testing matrices .



To Do Next: Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .


Life cycle Teting

Life cycle testing involves continuous testing of the solution even after software plans are complete and the tested system is implemented. At several points during the development process, the test team should test the system in order to identify defects at the earliest possible
point.

It testing cannot occur until you formally develop your process. IT must provide and agree to a strict schedule for completing various phases of the process for proper life cycle testing to occur. If IT does not determine the order in which they deliver completed pieces of software, it’s impossible to schedule and conduct appropriate tests.

It testing is best accomplished by forming a test team. The team is composed of project members responsible for testing the system. They must use structured methodologies when testing; they should not use the same methodology for testing that they used for developing the system.

The effectiveness of the test team depends on developing the system under one methodology and testing it under another. The life cycle testing concept is illustrated in Figure.


It shows that when the project starts, both the development process and system test process also begin. Thus, the testing and implementation teams begin their work at the same time and with the same information.

The development team defines and documents the requirements for implementation purposes, and the test team uses those requirements for the purpose of testing the system. At appropriate points during the development process the test team runs the compliance process to uncover defects. The test team should use the structured testing techniques a basis of evaluating the corrections.

As you’re testing the implementation, prepare a series of tests that your dept can run periodically after your revised system goes live. Testing does not stop once you’ve completely implemented your system; it must continue until you replace or update it again!


SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

Testing Life Cycle part three

This post is in contiunation with TESTING life cycle part two.

Program (Build/Construction)

Actual testing occurs during the construction stage of development. Many testing tools and techniques exist for this stage of system development. Code walkthrough and code inspection are effective manual techniques.

Static analysis techniques detect errors by analyzing program characteristics such as data flow and language construct usage. For programs of significant size, automated tools are required to perform this analysis.

Dynamic analysis, performed as the code actually executes, is used to determine test coverage through various instrumentation techniques. Formal verification or proof techniques are used to provide further quality control.

Test Process

During the test process, careful control and management of test information is critical. Test sets, test results, and test reports should be catalogued and stored in a database. For all but very small systems, automated tools are required to do an adequate job – the bookkeeping chores alone become too large to handle manually. A test driver, test data generation aids, test coverage tools, test results management aids, and report generators are usually required.

Installation

The process of placing tested programs into production is an important phase normally executed within a narrow time span. Testing during this phase must ensure that the correct versions of the program are placed into production; that data if changed or added is correct; and that all involved parties know their new duties and can perform them correctly.

Maintenance

A large portion of the life cycle costs of a software system are spent on maintenance. As the system is used, it is modified either to correct errors or to augment the original system. After each modification the system must be retested. Such retesting activity is termed regression testing. The goal of regression testing is to minimize the cost of system re validation.

Usually only those portions of the system impacted by the modifications are retested. However, changes at any level may necessitate retesting, re-verifying and updating documentation at all levels below it. For example, a design change requires design re-verification, unit retesting and subsystem retesting.

Test cases generated during system development are reused or used after appropriate modifications. The quality of the test documentation generated during system development and modified during maintenance will affect the cost of regression testing. If test data cases have been catalogued and preserved, duplication of effort will be minimized.

95

Testing Life Cycle part two

This article is in continuation with testing life cycle part one.

The following activities should be performed at each phase of the life cycle:

1 • Analyze the structures produced at this phase for internal testability and adequacy.

2 • Generate test sets based on the structure at this phase.

In addition, the following should be performed during design and programming:

1 • Determine that the structures are consistent with structures produced during previous phases.

2 • Refine or redefine test sets generated earlier.

Throughout the entire life cycle, neither development nor verification is a straight-line activity. Modifications or corrections to a structure at one phase will require modifications or re-verification of structures produced during previous phases.

Requirements

The verification activities that accompany the problem definition and requirements analysis phase of software development are extremely significant. The adequacy of the requirements must be thoroughly analyzed and initial test cases generated with the expected (correct) responses.

Developing scenarios of expected system use helps to determine the test data and anticipated results. These tests form the core of the final test set. Generating these tests and the expected behavior of the system clarifies the requirements and helps guarantee that they are testable.

Vague requirements or requirements that are not testable leave the validity of the delivered product in doubt. Late discovery of requirements inadequacy can be very costly. A determination of the criticality of software quality attributes and the importance of validation should be made at this stage. Both product requirements and validation requirements should be established.

Design

Organization of the verification effort and test management activities should be closely integrated with preliminary design. The general testing strategy – including test methods and test evaluation criteria – is formulated, and a test plan is produced. If the project size or criticality warrants, an independent test team is organized. In addition, a test schedule with observable milestones is constructed. At this same time, the framework for quality assurance and test documentation should be established.

During detailed design, validation support tools should be acquired or developed and the test procedures themselves should be produced. Test data to exercise the functions introduced during the design process, as well as test cases based upon the structure of the system, should be generated. Thus, as the software development proceeds, a more effective set of test cases is built.

In addition to test organization and the generation of test cases, the design itself should be analyzed and examined for errors. Simulation can be used to verify properties of the system structures and subsystem interaction; the developers should verify the flow and logical structure of the system, while the test team should perform design inspections using design walk troughs.

Missing cases, faulty logic, module interface mismatches, data structure inconsistencies, erroneous I/O assumptions, and user interface inadequacies, are items of concern. The detailed design must prove to be internally coherent, complete, and consistent with the preliminary design and requirements.

95.1

The previous post is regarding C SHARP programming of Microsoft dot net and you can have a glance at that here.

Testing Life Cycle part one

Often, testing after coding is the only method used to determine the adequacy of the system. When testing is constrained to a single phase and confined to the later stages of development, severe consequences can develop.

It is not unusual to hear of testing consuming 50 percent of the development budget. All errors are costly, but the later in the life cycle that the error discovered is made, the more costly the error.

An error discovered in the latter parts of the life cycle must be paid for four different times.

The first cost is developing the program erroneously, which may include writing the wrong specifications, coding the system wrong, and documenting the system improperly.

Second, the system must be tested to detect the error.

Third, the wrong specifications and coding must be removed and the proper specifications, coding, and documentation added.

Fourth, the system must be retested to determine that it is now correct.

If lower cost and higher quality systems are the information services goals, verification must not be isolated to a single phase in the development process, but rather, incorporated into each phase of development.

One of the most prevalent and costly mistakes on systems development projects today is to defer the activity of detecting and correcting problems until late in the project. A major justification for an early verification activity is that many costly errors are made before coding begins.

Studies have shown that the majority of system errors occur in the design phase. These numerous studies show that approximately two-thirds of all detected system errors can be attributed to errors made during the design phase. This means that almost two-thirds of the errors must be specified and coded into programs before they can be detected.

The recommended testing process is presented in Table 1-5 as a life cycle chart showing the verification activities for each phase. The success of conducting verification throughout the development cycle depends upon the existence of clearly defined and stated products at each development stage.

The more formal and precise the statement of the development product, the more amenable it is to the analysis required to support verification. Many of the new system development methodologies encourage firm products even in the early development stages.

The recommended test process involves testing in every phase of the life cycle. During the requirements phase, the emphasis is upon validation to determine that the defined requirements meet the needs of the organization. During the design and program phases, the emphasis is on verification to ensure that the design and programs accomplish the defined requirements.

During the test and installation phases, the emphasis is on inspection to determine that the implemented system meets the system specification. During the maintenance phases, the system will be retested to determine that the changes work and that the unchanged portion continues to work.

93
PREVIOUS POST

ASP PROGRAMMING COMPLETE SERIES PART TWO

ITERATIVE SPIRAL MODEL

Life Cycle : Iterative Spiral Model Life cycle

Phase I

Customer Communication

Overview

To capture customer requirements for the OneManage 5.1

Inputs

URS

Entry Criteria

URS

Deliverables

URS

Exit Criteria

Approved URS

Activity name

Methodology Used

Tools Used

Roles Involved

Requirement Study

NA

NA

Development Team

Customer Approval

NA

Email

Customer





Phase II

Planning & Risk Analysis

Overview

Planning for the OneManage 5.1

Inputs

URS

Entry Criteria

Approved URS

Deliverables

SRS, Planning Documents and RTM

Exit Criteria

Approved SRS, RTM & Planning Documents

Activity name

Methodology Used

Tools Used

Roles Involved

SRS Preparation

SRS Process

SRS template

Development Team

SRS Review

Review Process

Inspection Item log, DSS

Project Manager

EST, SCH, PPL, QPL, CMP documents preparation

Planning process

Template documents

Development team

Planning documents review

Review Process

Inspection Item log, DSS

Development team

RTM Preparation

RTM Process

Template documents

Development Team

RTM Review

Review Process

Inspection Item log, DSS

Development Team





Phase III

Engineering

Overview

Designing for OneManage 5.1

Inputs

SRS, Planning Document & RTM

Entry Criteria

Approved SRS, RTM & Planning Documents

Deliverables

Design Documents and User Interface (HTML screenshots)

Exit Criteria

Successful completion of User Interface design & Design Documents

Activity name

Methodology Used

Tools Used

Roles Involved

High Level Design

Design process

MS-word

Development Team

XML Design

Design process

Word pad

Development Team

Database

Design process

MS-word

Development Team

User Interface Design

Design process

HTML editor

Development Team

Interface Design

Design process

Rational Rose / Magic Draw

Development Team

Class Design

Design process

Rational Rose / Magic Draw

Development Team

Design Review

Review process

Inspection Item Log, DSS

Development Team

Update RTM document

RTM Process

RTM template, MS-Word

Development Team

RTM Review

Review Process

Inspection Item log, DSS

Development Team





Phase IV

Construction & Release

Overview

Test Case Preparation, Coding, Testing and release of product

Inputs

SRS, RTM, User Interface & Design documents

Entry Criteria

Approved User Interface & Design documents

Deliverables

Validation Test Records, Code (executables) & User Manual

Exit Criteria

Successful completion of Validation Testing.

Activity name

Methodology Used

Tools Used

Roles Involved

Preparation of Unit test cases

Testing process

Testing Form

Development Team

Preparation of Integration test cases

Testing process

Testing Form

Development Team

Preparation of Validation test cases

Testing process

Testing Form

SQA Team

Unit Test case Review

Review process

Inspection Item log, DSS

Development Team

Integration Test case Review

Review process

Inspection Item log, DSS

Development Team

Validation Test case Review

Review process

Inspection Item Log, DSS

Development Team with SQA Team

Coding

Coding standards

Any Editor

Development Team

Code review

Review Process

Inspection Item log, DSS

Development Team

Unit testing

Testing process

Unit test cases

Development Team

Unit Test records review

Review process

Inspection Item log, DSS

Development Team

Integration testing

Testing process

Integration test cases

Development Team

Integration test records review

Review process

Inspection Item log, DSS

Development Team

Validation testing

Testing process

Validation test cases

QA Team

Validation test records review

Review process

Inspection Item log, DSS

QA Team with Development Team

Preparation of check list

Release process

Ms-Word

Development Team

Fill the release form

Release process

Release form template

Development Team

Preparation of Release form

Release process

Ms-Word

Development Team

Update RTM document

RTM Process

RTM template, MS-Word

Development Team

RTM Review

Review Process

Inspection Item log, DSS

Development Team





Phase V

Customer Evaluation

Overview

Evaluation of software by customer

Inputs

Validation Test Records, Code (executables), User Manual, UAT form

Entry Criteria

Completion of Validation Testing

Deliverables

UAT report

Exit Criteria

Acceptance from the customer

Activity name

Methodology Used

Tools Used

Roles Involved

User Acceptance Testing

Testing Process

Validation test cases

Customer

UAT support

NA

Bugzilla

Customer and Development team

Closure of Metrics Collection and Handing over documents

Hand Over process

Hand over template

Development and SEPG team


RELATED POST

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

QUALITY TESTING

QUALITY ASSURANCE

QUALITY ASSURANCE PART TWO

QUALITY ASSURANCE SQA

QUALITY OF DESIGN OF TEST CASE

QUALITY MANAGEMENT IN SOFTWARE TESTING

TOOLS FOR QUALITY MANAGEMENT

STATICAL QUALITY ASSURANCE

ISO APPROACH TO QUALITY TESTING