Testing Methodology

STLC
The process of creating a systematic way and well planned approach for the project  is called software testing life cycle.

STLC Phases

1. Requirements Analysis
2. Test Planning
3. Test Analysis
4. Test Design
5. Test Construction and verifications
6. Test Execution and Bug Reporting
7. Final testing and implementations
8. Post implementations

Requirement Analysis

1. Test team Analyze the customer requirements and work with developers during the design phase.
2. QA team identify the requirements and interact with the client, stake holders, technical leads to understand the requirements in detail.
3. Both functional and Non functional requirements analyze in this phase.

Entry criteria

1. Requirement specification documents
2. Acceptance criteria should be well defined.

Activities

1. Prepare Requirement specification document form the business analyst, client, technical leads
2. identify the type of test should be performed like functional , security, performance testing.
3. Prepare and identify the test environment details where testing should be done.
4. Check out the automation feasibility if required.

Deliverables.

1. Prepare the answer for the list of question and it should be resolved.
2. Automation feasibility if needed

Test planning

1. Test lead or test manager determines the effort and cost estimation of the projects.
2. Based on the requirements phase analysis, start preparing the test plan
3. Once test plan is completed, QA team develops the test cases completely.

Entry criteria

1. Requirements Documents
2. Automation feasibility report

Activities

1. List the types of testing should be involved.
2. Prepare Test effort estimation documents
3. Prepare test schedule, test environment, roles and responsibility,

Deliverables

1. Test plan document
2. Effort and cost estimation documents.

Test case Development

1. This is the phase where testing team can work on the test cases and also prepared test data for the test cases.
2. once the test cases are ready, it should moved to QA lead for reviewing
3. Prepared requirement traceability matrix. It is an inductry accepted format by mapping the requirements with the test cases.

Entry criteria

1. Requirement  documents with the missing functionality

Activities

1. Preparation of test cases and test data
2. Preparation of test automation scripts.

Deliverables

1. Test cases, Test data, test automation scripts.

Test Environment setup

1. It decides the software and hardware conditions under which the work is tested.
2. Test team is not involved in this process.
3. Developer or customer creates the test environment set up.
4. In this time, test team should prepare the smoke test cases to chek the readiness of the  tets environment set up.

Entry criteria

1. Test plan, Test cases, Test data , smoke test is available.

Activities

1. Analyze the software and hardware requirements and prepare the environment setup.
2. Once the environment setup, execute the smoke test to check the readiness of the software.

Deliverables.

1. Test Environment will be ready with test data.
2. Smoke test result will be available.

Test Execution

1. Testing team starts testing based on the test planning and test cases.
2. Bugs will be reported back to the development team for correction and retesting will be performed.

Entry criteria

1. Test plan, Test cases , Test data is available for the Test Execution purpose.

Activities

1. Based on Test planning, execute the test cases.
2. mark the status of the test cases. passed, failed, blocked, not run .
3. Assigned test id to the development team.
4. Track the defects.

Deliverables.

1. Test case Execution and defect report.

Test cycle closure

1. Test team will meet and analyze the cost, quality, business perspective.
2. Discussed about the good perspective and what are all the future needs to improve in the future projects.
3. This meeting helps to improve bottleneck in the STLC process.
4. Once team complete the test cycle, test closure report and test metrics will be prepared.

Entry criteria

1. Test case execution report and defect report

Activities

1. Evaluate the project based on cost, quality, time , critical business aspects and software metrics prepared based on these conditions

Deliverables

1. Test closure report and Test metrics will be available.

BUG LIFE CYCLE

New

when issue is raised and posted for the first time . This state is named as new state.

Assigned

After the tester has posted the bugs , the test lead verifies the bug and he assigns the bug to the developer This state is known as Assigned.

Open :

Developer has open and analyzing the bug and started working on that. this state is knows as open state

   
Fixed : 

when developer making changes everything on the code and he assigned the status as fixed and the bug is passed to the testing team.

Pending

After fixing the defects from the developers side. developer has assign the coding to the testing team. In this state the status is pending.

   
Retest :

In this stage, tester op retesting the code which is given by developer team, whether the defect got fixed or not.

   
Verified :

The tester tests the bug and after it got fixed by the developer. If the bug is not present in the software , he approves  the bug as fixed status.

Reopen

If the bug still exists, after fixing by the developer, the tester changes the status to reopen. the bug goes through the life cycle once again.

Closed :

once the bug is fixed. if the tester feels that the bug is no longer exists, the status changed to closed.

Duplicate:

If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status i

Rejected:

If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to rejected

Deferred

The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

Not a bug:

The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.