Software Testing Life Cycle

SOFTWARE TESTING LIFE CYCLE:

1) TEST INITIATION:

In General, System testing process or STLC starts with test initiation or test commencement. In this phase, project manager or Test Manager selects the reasonable approaches which are followed by Test Engineers. He prepares a document called TEST STRATEGY DOCUMENT in IEEE 829 Format.

TEST STRATEGY document is developed for each project. This document defines the scope and general directions or approach or path for testing in the project.

TEST STRATEGY MUST ANSWER THE FOLLOWING:

1. When will testing occur?
2. What kind of testing occur?
3. What kinds of risks come?
4. What are the critical success factors?
5. What is the testing objective?
6. What tools will be used?

TEST STRATEGY DOCUMENT FEATURES ARE AS FOLLOWS:

1) SCOPE & OBJECTIVE:
Brief account & purpose of the project.

2) BUDGET ISSUES:
Allocated budget for the project

3) TEST APPROACH:
Defines test approach between development stages & testing factors.

4) TEST ENVIRONMENT SPECIFICATIONS:
Require test documents developed by testing team during testing.

5) ROLES & RESPONSIBILITIES:
The consecutive jobs in both development & testing and their responsibility.

6) COMMUNICATION & STATUS REPORTING:
Required negotiation in between two consecutive roles development & Testing.

7) TESTING MEASUREMENTS & METRICS:
To estimate the work completion in terms of quality assessment, test management process capabilities.

8) TEST AUTOMATION
Possibilities to get test automation with respect to corresponding project requirements & testing facilities (or) tools availability.

9) DEFECT TRACKING SYSTEM:
Required negotiation in between development and testing team to fix the defects and resolve.

10) CHANGE & CONFIGURATION MANAGEMENT:
Required strategy to handle change request of users side.

11) RISK ANALYSIS & MITIGATIONS or Solutions:
Common problems appears during testing and possible solutions to recover.

12)TRAINING PLAN:
The required number of training sessions for test engineers before starting of project.

NOTE: RISKS ARE FUTURE UNCERTAIN OR UNEXPECTED EVENTS WITH A PROBABILITY OF OCCURRENCE AND POTENTIAL FOR LOSS.

2) TEST PLAN:

After completion of the test strategy document, the test lead category people defines test plan in terms of

WHAT TO TEST? (Development Plan)
HOW TO TEST? (From SRS document)
WHEN TO TEST? (Design document/Tentative Plan)
WHO WILL TEST? (Team Foundation)

Converting of System plan to Module plan:

SYSTEM PLAN MODULE PLAN

Development Plan > Team Foundation
Test Strategy >Risk Analysis
>Prepare test plan document
>Review on test.

TEST TEAM FORMATION:

In General, the test planning process starts with test team formation depends upon the below factors:

Availability of testers
Availability of the test environment resources.
Identifying Tactical Risk.

After completion of test team formation the test lead concentrate on risk analysis and mitigations or solutions.

Types of Risks:

1. Lack of knowledge on the domain.
2. Lack of budget.
3. Lack of resources.
4. Delay in deliveries.
5. Lack of development team seriousness.
6. Lack of communication.

Prepare Test Plan Document:

After completion of test formation and risk analysis, the test lead concentrate on test plan document in IEEE format as follows:

TEST PLAN ID:

The unique name and number will be assigned for every test plan.

INTRODUCTION/SUMMARY:

Brief account about the project.

TEST ITEMS:

Number of modules in the project.                                            

FEATURES TO BE TESTED:

Testing only responsible modules (or) the names of the modules to be tested.

TEST ENVIRONMENT:

Required documents to prepare during testing & required H/W & S/W used in the project.

NOTE: ABOVE ALL THE POINTS FOR WHAT TO TEST

ENTRY CRITERIA:

Whenever the test engineers, starts test execution.
i. All test cases are completed
ii. Receive stable build or software build from developer
iii. Establish test environment.

SUSPENSION CRITERIA:

Whenever the test engineers are able to interrupt test execution
i. Major bugs or severe bugs occur.
ii. Resources are not working.

EXIT CRITERIA:

Whenever the test engineers are able to stop test execution

i. All the test cases should be completed.
ii. Cross the schedule.
iii. All the defects resolved.

TEST DELIVERABLES:

The number of required documents submitted to the test lead by the test engineers.

Documents are 1.Test Case documents.
2. Test Summary documents.
3. Test Log.
4. Defect report documents.
5. Defect summary documents.

NOTE: The above mentioned points for HOW TO TEST?

ROLES & RESPONSIBILITIES:

The work allocation to the selected test engineers and their responsibilities.

STAFF & TRAINING PLAN:

The names of selected testing team and number of training sessions required for them.

NOTE: The above two points for WHO WILL TEST?

SCHEDULE:

The date and time allocated for project.

APPROVALS:

Signature of PM/QA/responsible people.

NOTE: The above two points for WHEN TO TEST? 

REVIEW ON TEST PLAN:

After completion of test plan document, the test lead concentrate on review of the document for completeness & correctness.

In this review meeting, testing team conducts Coverage Analysis.

3) TEST DESIGN PHASE

After preparing the test plan document. The test engineers who are selected by Team leaders will concentrate to prepare Test Cases in IEEE 829 format.

TEST CASE:

A set of inputs, execution conditions and expected results developed for a particular objective or test object such as to exercise a particular program path (or) To verify complaints with a specific requirement.

The test case is not a necessarily design to expose a defect, but to gain a knowledge or information.

Eg) Whether the program PASS/FAIL the test.

WHY TEST CASE REQUIRED?

Necessary to verify successful and acceptable implementation of product requirement.

Helps to finds the problems in the requirements of an application.

Determines whether we reached clients expectations.

Helps testers SHIP (valid) or NO SHIP (Invalid) decisions.

1. Randomly selecting or writing test cases doesnt indicate effective of testing.
2. Writing large number of test cases doesnt mean that many errors in the system would be uncover.

The Test engineers are writing test cases in 2methods:

1) USER INTERFACE BASED TEST CASE DESIGN.
2) FUNCTIONAL & SYSTEM BASED TEST CASE DESIGN.

USER INTERFACE BASED TEST CASE DESIGN:
A test case in applications development is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. All the below test cases are static, because the test cases are applicable on build without operating.

TEST CASE TITLES:

1. Check the spellings.
2. Check font uniqueness in every screen.
3. Check style uniqueness in every screen.
4. Check label uniqueness in every screen.
5. Check color contrast in every screen.
6. Check alignments of objects in every screen.
7. Check name uniqueness in every screen.
8. Check spacing uniqueness in between labels and objects.
9. Check dependent object grouping.
10. Check border of object group.
11. Check tool tips of icons in all screens.
12. Check abbreviations (or) full forms.
13. Check multiple data object positions in all screens. Eg) List Box, Menu, Tables.
14. Check Scroll bars in every screen.
15. Check short cut keys in keyboard to operate on our build.
16. Check visibility of all icons in every screen.
17. Check help documents. (Manual support testing)
18. Check Identity controls. Eg) Title of software, Version of S/w, Logo of company, Copy Rights etc.

NOTE:

Above usability test cases are applicable on any GUI application for usability test.
For these above test cases, Testers give priority as P2

Test Case Prioritization
Different organizations use different scales for prioritization of test cases. One of the most commonly used scale prioritizes the Test Scenarios into the following 4 levels of Priorities.
1. BVT
2. P1
3. P24. P3