Professional Documents
Culture Documents
Activities designed to ensure the software corresponds to The process of exploring a system in order to find defects.
specific.
Involves activities related to the implementation of Involves actives concerning verification of product Example
processes, procedures, and standards. Example - Audits - Review Testing
Training
The scope of SQA applied to all products that will be The scope of Software Testing applies to a particular
created by the organization product being tested
Defect Priority has defined the order in which the developer Defect Severity is defined as the degree of impact that
should resolve a defect a defect has on the operation of the product
Priority is categorized into three types Severity is categorized into five types
Low Critical
Medium Major
High Moderate
Minor
Cosmetic
Priority indicates how soon the bug should be fixed Severity indicates the seriousness of the defect on the
product functionality
Priority of defects is decided in consultation with the QA engineer determines the severity level of the defect
manager/client
Its value is subjective and can change over a period of time Its value is objective and less likely to change
depending on the change in the project situation
High priority and low severity status indicate, defect have to High severity and low priority status indicate defect
be fixed on immediate bases but does not affect the have to be fixed but not on immediate bases
application
Priority status is based on customer requirements Severity status is based on the technical aspect of the
product
During UAT the development team fix defects based on During SIT, the development team will fix defects based
priority on the severity and then priority
High Severity, Low Priority :- Web page not found when user clicks on a link
(user's does not visit that page generally)
Customers who use very old browsers cannot continue with their purchase of a product.
Because the number of customers with very old browsers is very low, it is not a high
priority to fix the issue.
Low Severity High Priority :- If the company name is misspelled in the home page of the
website, then the priority is high and severity is low to fix it.
The logo or name of the company is not displayed on the website. It is important to fix
the issue as soon as possible, although it may not cause a lot of damage.
4) “QA activity should start at the beginning of the project”. Justify the statement.
I agree with the statement that a good time to start the QA is from the beginning of the project
startup. This will lead to plan the process which will make sure that product coming out meets
the customer quality expectation. Indeed, QA also plays a major role in the communication
between teams.
Software testing life cycle (STLC) is a sequence of specific activities conducted during the testing
process to ensure software quality goals are met. STLC involves both verification and validation
activities.
phases of STLC:
Requirement Analysis
During this phase, test team studies the requirements from a testing point of view to identify the
testable requirements.
The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System
Architects etc.) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non-Functional
(defining system performance /security availability )
Test Planning
Typically, in this stage, a Senior QA manager will determine effort and cost estimates for the project and
would prepare and finalize the Test Plan. In this phase, Test Strategy is also determined.
This phase involves the creation, verification and rework of test cases & test scripts. Test data, is
identified/created and is reviewed and then reworked as well.
Test environment decides the software and hardware conditions under which a work product is tested.
Test environment set-up is one of the critical aspects of testing process and can be done in parallel with
Test Case Development Stage. Test team may not be involved in this activity if the
customer/development team provides the test environment in which case the test team is required to
do a readiness check (smoke testing) of the given environment.
Test Execution
During this phase, the testers will carry out the testing based on the test plans and the test cases
prepared. Bugs will be reported back to the development team for correction and retesting will be
performed.
Testing team will meet, discuss and analyze testing artifacts to identify strategies that have to be
implemented in the future, taking lessons from the current test cycle. The idea is to remove the process
bottlenecks for future test cycles and share best practices for any similar projects in the future
Agile testing is all about changes and making differences in requirements even in the future with
later on better development phases. It is very important to understand the basics of Agile
methodology.
The main objective of Agile testing is to deliver the product with minimal functionalities to the client
itself. These only happen when you have adapted to agile development fully.
Agile testing is a continuous process normally and is done in multiple phases. With every new
delivery adds more features, smoother functions and more capabilities added on to the product.
This method results in higher customer satisfaction.
When a testing team uses Agile methodology, the test does not finish in just one phase it is done in
various intervals. Testing it earlier ensured minimal damage and risk in the end application.
Applications with minimal functionalities are ready faster and hence satisfying the customer/client.
Testing is a process which ensures that the product will meet all the requirements in each iteration
as there is sign of progress.
The process of testing is conducted by the entire team and not by testers.
Instead of test documentation there are lightweight documents and checklist suffices.
The developers and testers only consider the application complete once the tests are implemented
and tested.
9) What are the contents of test plans?
Verification Validation
2. It does not involve executing the code. 2. It always involves executing the code.
6. It can catch errors that validation 6. It can catch errors that verification
cannot catch. It is low level exercise. cannot catch. It is High Level Exercise.
A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect from which it goes
through covering the different states in its entire life. This starts as soon as any new defect is
found by a tester and comes to an end when a tester closes that defect assuring that it won’t get
reproduced again.
The number of states that a defect goes through varies from project to project.
New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and
assigns the bug to the developer team
Open: The developer starts analyzing and works on the defect fix
Fixed: When a developer makes a necessary code change and verifies the change, he or she can
make bug status as "Fixed."
Pending retest: Once the defect is fixed the developer gives a particular code for retesting the
code to the tester. Since the software testing remains pending from the testers end, the status
assigned is "pending retest."
Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by
the developer or not and changes the status to "Re-test."
Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug
detected in the software, then the bug is fixed and the status assigned is "verified."
Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the
status to "reopened". Once again, the bug goes through the life cycle.
Closed: If the bug is no longer exists then tester assigns the status "Closed."
Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the
bug, the status is changed to "duplicate."
Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to
"rejected."
Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next
release, then status "Deferred" is assigned to such bugs
Not a bug: If it does not affect the functionality of the application then the status assigned to a
bug is "Not a bug".