QA METHODOLOGY

Bogdan Catana
What is software testing?

Software testing is a process, to evaluate the functionality of a software application with an

intent to find whether the developed software met the specified requirements or not and to
identify the defects to ensure that the product is defect free in order to produce the quality
product.
Software development life cycle
Software test life cycle
 Test Strategy
● Items to test and not to test such as test product features, interfaces, reporting tools

● Risks, issues, mitigation strategies, and contingencies plans

● Testing approach defining methods and tools to be used for testing

● Item pass/fail criteria specifying what constitutes a successful test

● Entry and exit criteria specifying what constitutes a completed test

● Test deliverables such as a test plan, test cases, test tools

● Environmental needs outlining any requirements for where testing will take place

● Staffing and training needs

● Acceptance criteria
 Test Design
● Determine the test objectives

● Preparation of the list of items to be tested

● Identification of test cases.

● Selection of test case design techniques.

● Creating test cases and test data

● Setting up the test environment and supporting tools.

● Creating test procedure specification.

Test Execution

● Test cases start after the completion of a module

● Test results are documented in the test incident reports, test logs, testing status and test
summary reports

Test Review
● Bugs will be reported to the developers

● Analyze bugs, related issues and get feedback so that maximum number of bugs can be
fixed
Software testing levels
Testing Types

Functional Non-Functional

● Functional testing is performed using ● Non-Functional testing checks the

the functional specification provided Performance, reliability, scalability and
by the client and verifies the system other non-functional aspects of the
against the functional requirements software system
● Functional testing is executed first ● Non-Functional testing should be
● Business requirements are the inputs performed after functional testing
to functional testing ● Performance parameters like speed,
● Functional testing describes what the scalability are inputs to non-functional
product does testing
● Non-Functional testing describes how
good the product works
Functional Testing Types

Smoke Sanity

● Testing that is done after each build is ● Testing that is done to ensure that all
released to test to ensure build major and vital functionalities of the
stability application/system are working
correctly
Regression integration

● Testing performed to ensure that ● When the system relies on multiple

adding new code, enhancements, functional modules that might
fixing of bugs is not breaking existing individually work perfectly but have to
functionality or cause instability and work coherently when clubbed
still works according to the together to achieve an end to end
specifications scenario
Non-Functional Testing Types

● Usability testing ● Reliability testing

● Maintainability testing ● Security testing
● Portability testing ● Recovery testing - rollback
● Compatibility testing ● Compliance testing

● Performance testing
Performance Testing Types

Stress Load

● It involves testing beyond normal ● A load test is usually conducted to

operational capacity, often to a understand the behavior of the
breaking point, in order to observe application under a specific expected
the results load

Endurance Redline

● Endurance testing is used to check ● It helps to identify the maximum

how much time the system will operating capacity of an application
behave as expected under maximum as well as any bottlenecks and
load or under a specific load determine which element is causing
degradation
Software Testing Methods

Black box testing White box testing

● software test engineer tests an ● software testing method in which

application without knowledge of the internal structure is being known to
internal workings of the application software test engineer who is going to
being tested test the software
Boundary Value Analysis
Equivalence Partitioning
Test cases
A test case is used to examine whether the system displays the desired behaviour under
specific circumstances. A well-known way to describe system behaviour is:
Input → Processing → Output

Negative testing
Positive testing
● Negative testing ensures that your
● the type of testing that can be
application can gracefully handle an
performed on the system by providing
invalid input or unexpected user
the valid data as input
behavior
Positive testing Negative testing

vs

● Positive Testing means testing the ● Negative Testing means testing the
application or system by giving valid application or system by giving invalid
data data
● It is always done to verify the known ● It is always done to check if the
set of Test Conditions application handles improper user
● Positive testing ensures that the behaviour correctly
business use case is validated ● Negative testing ensures that the
delivered software has no flaws that
can be a deterrent in its usage by the
customer
Test Case Management
Test Case Workflow
● New/Design – Software test engineer has identified the scenario/requirement under test
and has begun writing it

● Ready for Review – Software test engineer has completed documenting the steps and
other specific test requirements and the test case is ready to be reviewed by either a peer
software test engineer from inside the project or the project Business Analyst

● Released – The test has been reviewed by the above mentioned and has been marked as
approved or ready to be executed

● Automated – The test cases have been automated using various automation tools

● Canceled / Obsolete – The test case no longer covers an active functionality or due to
changes in the system is no longer a valid/executable scenario
Organising your test cases

By Release By module/application component

● depending on the delivery model, your ● a more granular level than an actual
application can have one or several requirement, for example the login module
incremental releases over a period of time inside the banking application
until it reaches the final state

By requirements By test types

● as the main starting point for all test cases, ● Depending on the type of testing executed
individual requirements also serve as a good
way to group your test cases, for example in
the movie app “The users should be able to
choose their seats” all tests that are written
for the seat reservation process will sit in the
same location
What is a defect/bug?
● When actual result deviates from the expected result while testing a software application
or product then it results into a defect. Hence, any deviation from the specification
mentioned in the product functional specification document is a defect. In different
organisations it’s called differently like bug, issue, incident or problem

● When the result of the software application or product does not meet with the end user
expectations or the software requirements then it results into a Bug or Defect. These
defects or bugs occur because of an error in logic or in coding which results into the failure
or unpredicted or unanticipated results
Bug report

● Bug Description
● Version
● Priority
● Sanity
● Actual behaviour
● Expected behaviour
● Steps to reproduce
● Test environment
● Additional Info
Bug’s priority
● P0 Blocker: This means the defect is a show stopper with high potential damages and has
no workaround to avoid the defect. An example could be that the application does not
launch at all and causes the operating system to shut down. This requires immediate
attention and action and fix.

● P1 Critical: This means that some major functionalities of the applications are either
missing or do not work and a workaround exists.

● P2 Major: This means that a part of functionality does not work, but a workaround exists to
be used as a temporary solution.

● P3 Medium: This means that the failure causes inconvenience and annoyance.

● P4 Minor: This is not normally a defect and a suggestion to improve a functionality. This
can be GUI or viewing preferences.
Bug life cycle
● New: When a new defect is logged and posted for the first time. It is assigned a status
NEW.
● Assigned: Once the bug is posted by the software test engineer, the lead of the software
test engineer approves the bug and assigns the bug to developer team
● Open: The developer starts analysing and works on the defect fix
● Fixed: When developer makes necessary code change and verifies the change, he or she
can make bug status as "Fixed."
● Retest: software test engineer does the retesting of the code at this stage to check whether
the defect is fixed by the developer or not and change the status to "Re-test."
● Reopen: If the bug persists even after the developer has fixed the bug, the software test
engineer changes the status to "reopened". Once again, the bug goes through the life cycle.
● Closed: If the bug does no longer exist then software test engineer assigns the status
"Closed."
Resolution types

● Duplicate: If the defect is repeated twice or the defect corresponds 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".
Thank you!