Saturday, 3 June 2017

Test Plan Document



Hello Friends,


Welcome to All About Software Testing blog.
 
In last blog we took the important STLC process, In this Blog we are going to see about Test Plan Document. 


Test plan is the most important question in interview, whenever I have to prepare for the interview I have prepare the following points, so If any buddy would ask me about test plan, this time I explain this following points.

What is Test Plan?
Test plan is a document which design and develop for executing the testing process in systematic way. Test plan is similar like user manual or day to day activity instructions.
This document is developed by Test team lead. In test plan Test lead mentioned all the details for a team which are followed while doing testing. So this is not just one person affords test plan is the continues activity which is followed by each team member.
Test plan usually developed during the early phase of the project.
Test Lead mentioned the following details in test plan, This plan might be change as per the Team Lead, so this is just for your reference.

Test Objectives
The test Objectives provide a prioritized list of verification or validation objectives for the project. You use this list of objectives to measure testing progress, and verify that testing activity is consistent with project objectives.

Scope and Risks
While doing the risk analysis test lead’s experience is most important factor, He is assuming what kind of difficulties might be comes in future.
In scope analysis test lead mentioning about important functionality which will going to test (Scope and Out of scope functionality).

  •        Features to be tested: Important features that needs to tested.
  •       Features not to be tested: Identify the features and the reasons for not including as part of testing.

In out of scope, you have to mention what are the things which are not dealing with.
If you will not going to perform Performance testing you have to mentioned in the Test plan.
Or If any module required some data for testing and the data is not available this time the particular module is out of scope and need to mention in your test plan document.
  
Test Strategy
On the basis of different phases strategy will change.
Unit testing, Integration testing, system testing and last acceptance testing.

Estimation
Work estimation is calculated before the completing the test plan.
Some peoples are using formula to calculate the time as per the activities, but in next article I will share very easy and useful test estimation process. In this section work is divided into the working hours.
Holidays and employee’s leaves also consider while calculating the Estimation.

Schedule
Scheduling is more about how much time we are giving to take.
Test lead will decide what to test? when to test? and who to test?
Team lead will mention the Start date and End Date for the test Execution Cycle.

Resource Planning
Means what kind of resources we need to use in this testing cycle, for example Hardware, software, team members, network devices.
Resource planning also known as team formation, team member and his task will decide in the resource planning.

Plan Test Environment
In this section team lead will decide the test bed(Testing Environment ), Actually this information is collecting from the client. In which environment the developed module will going to run, so on this basis test environment is decided.

Test Execution
Entry criteria for the test execution is Test cases, so before starting the Test Execution testers should create the Test cases, and execute that test cases as per the condition mentioned in test case document.
In this phase Bug life cycle is introduce.  

I hope you like this article, in next article we will see the creation of Test Estimation Documents.

So please share this link with your friends and add a comment for improvement.

Thank you.











































Monday, 1 May 2017

Software Testing Life Cycle and Bug Life Cycle




Lecture No  : 3
Hello All,

In last blog/lecture(Lecture No:2) we took the important SDLC process, In this Blog we are going to learn each and every phase of STLC (i.e Software Testing Life Cycle) and Bug Life Cycle.
This is the most important question were asking in the Testing Interview.
So let’s start the discussion:

Q) What is STLC? Explain the STCL Cycle?
STLC is the sub part of SDLC(Software Testing Life Cycle). Same like SDLC, STLC also has the various phases. Each phase has various activities.
All different phases are listed in following diagram, please have a look.


1.     Requirement Analysis:
2.     Test Planning
3.     Test Case Writing
4.     Test Execution
5.     Test Closure
Requirement Analysis:
We can say Requirement Analysis is the part of static testing, because Testers are working on the documents. In this phase testers are identifying the testable requirements.
Collect the information about Application.
Understand the Functional and Non-Functional requirements.
Taking the meetings with Client, Business Analyst, Manager, System Architect to understand the requirements in details.
Identify the Levels of Testing and Creating Test Strategy.
Out Put of this phase is:
List Of testable requirement
RTM (Requirement Traceability Matrix)
Test Strategy

Test Planning:
This is the next phase of Testing Life Cycle, in this phase QA team refer the documents which are created in last phase i.e. Requirement Analysis.
QA manager estimate the test efforts
Identify the team size/ Resource Management
Prepare the Testing schedule: Who to test? what to test? and when to test?
Out Put of this phase is:
Test Plan
Test Estimation

Test Case Writing:
This Phase is totally depends on the last two phases, Using RTM creating the Functional and Non functional test cases. Create the test data on the basis of Test Case behavior.
 Out Put of this phase is:
Test Scenario
Test Cases
Test Data

Test Case Execution:
Before going for the test execution, QA team should check that required build is deployed in Test Environment.
Executing the application and performing steps by referring to a Test Case.
Maintain the result of the Test case, compare the Actual result with expected result as written in the test case. Bugs will be reported back to the development team for correction and retesting will be performed. and follow BUG LIFE CYCLE.
Out Put of this phase is:
Defect Report
Daily Test Status Report

Test Closure:
Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future.
Prepare Test closure report.
All Test Deliverables from all phases of STLC to be checked in Configuration Management Tool
Out Put of this phase is:
Test Closure report 
Test metrics

Q) What is BUG LIFE CYCLE?
Bug life cycle is the part of STLC process. This is the process which is start from finding the bug till fixing that bug. This Cycle is divided into multiple phases, which is shown in following fig.


a) New:
When a new Bug or Defect found and Submitted in Bug Tracking tool for the first time this time the status of the Bug is NEW.

b) Assign:
After BUG is submitted in the Bug Tracking tool, Test Lead checks that bug if the Bug is valid then assigns to the responsible developer.

c) Open:
After assigning developer gets notification about Bug, Developer change the state of that bug as Open.
After that Developer starts analyzing and works on to fix that defect.

d) Fixed:
When the developer does the necessary changes in the code to fix that bug and verifies the changes, after getting the confidence developer change the status as Fixed.

e) Verify:
In this phase tester comes to the picture, tester will do the re-testing and regression testing to check whether the defect is fixed by the developer or not if the bug is fixed then change the status to "Verify."

f) Re-Open:
If the bug is not fixed even after the developer has fixed the bug, the tester changes the status to "reopen". Once again the bug goes through the life cycle.

g) Close:
If the bug is no longer exists then tester assigns the status as "Close." 

h) Deferred:
If the present bug is not high priority and high severity, and if it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs, this state will assigned by Test team lead or Project Manager.

i) Reject:
This state is assigned by Developer, If the developer feels that the bug is not genuine this time he will change the state as “Rejected.”

j) Not Bug:
If bug does not affect the functionality of the application then the status assigned to a bug is "Not bug".

k) Duplicate:
This is happens many times in testing life, same bug reported by multiple team members, this time state change to the “Duplicate”.

If the bug state is set as (i) Reject, (j) Not a Bug, and (k) Duplicate, reported bug will be closed. 

I hope this information is useful for you, If you have any doubts or have some suggestions for my blog post please write a comment.

Thanks in advance.
 

Test Plan Document

Hello Friends, Welcome to All About Software Testing blog.   In last blog we took the important STLC process, In this Blo...