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.
