Module 1: Manual

Lecture 2: Note

STLC- Software Testing Life Cycle. It is a part of SDLC (Software Development

Life Cycle).

 Anything we type in the application is called data.

STLC has 7 major phases.

1. Requirement Analysis
2. Test Planning
3. Test Cases Designing
4. Test data setup
5. Test Environment Setup
6. Test Execution
7. Test Closure
 How does a QA Engineer work step by step in STLC?
 First, we (QA Engineer) analyze the requirements, then, according to the
requirements, we create our test plan (But now we don't make any test
plan); after that, we create test cases, which we always do. We always write
our test cases according to the requirements. Then we should create the test
data that should be done before developers deploy the code in the QA
environment. If I need to add more test cases, I can add them after
deploying the code, but we must need to prepare test cases before deploying
the code. Then we should check if our environment is working well or not.
Checking the environment is just a one-time job only when we hire. Then
we test the application step by step according to our test cases, and if we see
there is no more defect, our test case works fine, and the application runs
 smoothly; no issue or bug is found. Then we sign off, close the test, and
send it to the PO (Product Owner). Then PO also can test that application or
not. When we (QA) test the application, it's called functional testing,
and when PO tests the application, it's called UAT (User Acceptance
Testing), BUT Both are the same testing, but it happens in two
different departments. Hence, if we see any bug or defect (In technical
language, we call a bug or defect instead of a problem), then we raise a
ticket, attach a screenshot as proof, and report it to the developer, who will
start fixing it.
 ********ANYTHING TYPABLE THING IS CALLED DATA. ONLY
TYPABLE THING IS DATA AND CLICKABLE THING IS NOT
DATA.
 *****We always validate the application in the GUI version (Graphical
User Interface).
 Describe the Defect Life Cycle workflow in detail:
 As a QA engineer, when we find a defect, we raise a ticket then it's called a
new ticket. Once we create a ticket, we will assign the ticket to the
developer then. When the developer starts to fix the defect, it's called the
Active stage. Active stage means the developer is working on it/ in
progress. After fixing the defect developer deployed the code in the QA
environment. Then we test it and complete validation. After validation, if
we don't see any defect, then we close it.
 Another Scenario: After completing fixing part of the previous defect,
when the developer deploys the code again and sends it to us for testing
again if we see any defect again or see the previous defect again, then we
reopen the ticket and assign again the developer for fixing it. Then the
 developer fixes it again and sends it to us, and if we see this time this
application has no more defects this time, we close the testing.
 Another scenario: When we raise a ticket and report to the developer after
checking the defect, he can reject it if the developer feels this is not a
defect. Why does it happen? Because we were not aware of the
requirement. That's why we should analyze the requirements properly.
 Interview question: when you create a defect, and the developer can
reject it, why could be the reason for this?
Answer: There might be some mismatch issue. Maybe the requirement
changed, and I didn't notice. Then, when the developer checks, the
developer sees this is not a defect and rejects it. Or, I have to check the
environment. When I validate the code in one environment, but maybe the
developer sends it to another environment, I create a wrong defect, and then
the developer rejects it.
 Sometimes, developers also can make mistakes in understanding the
requirements, and we can protest by informing the PO and conforming to
the requirements because PO is the only person who knows about the
correct requirement.
 Another Scenario: When we raise a ticket and assign it to the developer,
then if the developer feels this is a low-priority defect like a period sign or
punctuation mark missing or a spelling mistake, he will fix it later. Now he
wants to complete the high-priority defects; this stage is called the
Deferred stage.
 What is Low/ Medium/ High/ Urgent Priority?
 Low Priority: The defect can be fixed after the critical ones are done.
Example: Period sign/ punctuation mark/ spelling mistake
 Medium Priority: As a test engineer, we never put anything in medium
Priority without copy update; every functional defect is in high priority
for us.
High Priority: As a test engineer, any functional defect is a high
Priority for us without copy update. Example: log in button.
Urgent: Not widely used; some companies use it. Example: Any
application shut down like Facebook.
 Some companies also have severity options as well as Priority.
 Critical/ Severity 1: Same as urgent Priority
 Major/ Severity 2: Same as high Priority
 Medium/ Severity 3: Same as medium Priority
 Low/ Severity 4: Same as low Priority
 Interview Question:
Do you maintain the tress ability matrix, or Do you have any Test
Completion Matrix?
Answer: This matrix we maintain once a month/ at the end of the
month/ every sprint (One sprint = 2 weeks). Upon completion of testing,
various matrix are collected to prepare the test reports. The criteria for
preparing the reports include the following:
1. Number of Tests Executed.
2. Number of tests passed.
3. Number of tests Failed.
4. Number of Test Failed based on each module.
5. Number of test Defects raised during the execution cycle.
6. Number of test Defects Accepted.
7. Number of test Defects Rejected.
8. Number of test Defects Deferred.
9. Status of Active defects.
10.Calculating the Quality Index of the build.