Lesson 3

Testing Stages

I)Document Testing:

In Agile & Fish model, Document testing is the first stage. In Agile model, PO can
prepare PBL with all user stories.

The same PO can review that PBL for completeness and correctness. When PBL
was baselined, the PO can sit with SH's, SM and ST and prepare SBL with some
UserStories. The same PO can review that SBL for completeness and correctness.

When SBL was baselined, the corresponding ST developers can prepare HLD &/
LLD's w.r.t SBL. HLD is a overall design of sprint like shown below:

LLD is a detailed design of specific module or User Story. Due to this reason, one sprint is
having one HLD and multiple LLD's
The same ST developers can review those designs for completeness and correctness.

Case Study:

Document Prepared by Reviewed by Testing techniques

PBL PO Same PO Walk through,
Inspection,
Peer review
SBL PO Same PO "
HLD & LLD'S ST Developers Same ST developers "

Walkthrough: Study a document from first to last

Inspection: search a document for specific factors.

Peer review: compare two documents as point to point

Note: The above 3 techniques are called as Documents testing techniques or verification techniques or
static testing techniques or review techniques.

II)Unit Testing

When HLD and LLD's are baselined, ST developers can start coding/implementation. During coding, ST
developers can write programs and same developers can conduct testing on those programs called as
unit testing.
a)Basic paths coverage:

Developers can use this technique to ensure that a program is running or not
without any runtime errors.
Eg1:

No. of paths=2

run program to cover all coding areas

Eg2:

No of paths=2

run program to cover all coding areas for erros

b)Control Structure coverage

When a program is running without any runtime errors, corresponding

developers can validate that program correctness in terms of inputs & outputs
Eg:Debugging(run program line by line and watch output.

C)Program technique coverage:

When a program is running correctly, corresponding developer can concentrate on

execution speed calculation for that program. If that program is taking more execution
time then the developer can perform change in that program structure without
disturbing functionality

Eg: swapping two numbers

logic1: logic2:

a=10 a=10
b=20 b=20

a=a+b c=a

b=a-b a=b

a=a-b b=c

o/p: a=20 o/p: a=20

b=10 b=10

The above logic is In above, extra memory needed but taking less time in

time taking in execution execution

Mutation coverage:

After completion of previous 3 steps on a program, corresponding ST developers can perform changes in that
program and repeat previous 3 steps to know test coverage.

Note:

In above 4 white box techniques, first 3 techniques are useful to check program and last technique is
useful to check program testing.
Mutation coverage:

After completion of previous 3 steps on a program, corresponding ST developers can perform changes in that
program and repeat previous 3 steps to know test coverage.

Note:

In above 4 white box techniques, first 3 techniques are useful to check program and last technique is
useful to check program testing.

III)Integration Testing

When all /related programs are based lined(tested), corresponding ST developers can start integration
of those programs to build a sprint.

While integrating programs to build a sprint, corresponding ST developers can follow anyone of 4
approaches.
a)Top down Approach:

From this ST developers can interconnect main program and some of sub programs, because remaining
sub programs are under construction. In the place of under constructive sub programs, ST developers can use
temporary program called as stub.

b)Bottom-up Approach:
From this approach, ST developers can interconnect sub modules without involvement of main module because
main module is under construction.

In the place of under constructive main module, ST developers can use a temporary program called as driver.

C)Hybrid/Sandwich Approach:

This approach is a combination of Top-down and bottom-up approach.

Note: The above 3 approaches in Integration are called as Incremental Integration approaches.

d)System/Big bang approach:

 From this approach, ST developers can start integration after completion of 100% coding.

Sprint/S/w Testing
When a sprint or software is ready, ST testers can start testing on that sprint with respect to customer
requirements and customer expectations. This s/w testing is classified into 2 parts such as Functional Testing
and Non Functional Testing.

1)Functional Testing/Requirements Testing:

ST testers can start sprint testing by conducting functional testing as first. During functional testing, ST
testers can conduct below sub tests.

a)GUI Testing:

This testing is also called as behavioural testing or control flow testing. During this test, ST testers can
operate corresponding sprint or s/w to ensure those elements are responding or not.

b)I/p domain testing:

During this test, ST testers can operate sprint or s/w by entering different type of and size of data and
observe those fields are allowing valid data or not.

c)Error handling Testing:

During this test, ST testers can operate sprint or s/w by entering invalid data and observe error
messages/alert messages.
d)Manipulations Testing:

During this test, ST testers can operate sprint or s/w by entering valid data and observe
output/outcome.

Note: The above 4 functional tests are called as Front end testing topics.

DataBase Testing:

During this test, ST testers can operate Front end screens of sprint and observe impact of that operation
on backend DB of sprint.

Eg:

From the above example for DB testing, we need to observe 2 things,in DB testing such as Data Validation and
Data Integrity. Data validation means the correctness of newly inserted data. Data Integrity means the
correctness of changes in existing data due to new data insertion.

f)Data Volume testing:

This testing is also called as memory testing/ storage testing/Data capacity testing. During this test,
testing people can enter model data to sprint/s/w to calculate capacity of that sprint or s/w

Note:

DB testing and Data volume testing combination is called as Backend testing.

g)Recovery Testing:

This testing is also called as Reliability testing. During this test, tester can operate sprint or s/w in Invalid
Environment and observe that sprint or s/w is recover from abnormal state to normal state or not. Here invalid
environment means network disconnection, poweroff, restart system etc.

h)Intersystem Testing:

This testing is also called as End-to-end testing. During this test, testing prople/teesters can observe
that sprint or s/w connected to other s/w's to share common resources or not.

2)Non Functional Testing:

After completion of functional tests, ST testers can concentrate on Non functional testing. This stage is
also called as Expectations testing because non functional testing on sprint or s/w with respect to customer
expectation like Usability, compatability,performance,security....etc. Non Functional testing is also called as
System testing because to conduct non functional testing, we need complete sprint/s/w. This non functional
testing is classified into below sub tests..

a)Usability Testing:

During this test, ST can validate user friendliness sprint or s/w. Here user friendliness means "ease of
use","look & feel" and "short navigations".

b)Compatibility Testing:

This testing is also called as portability testing. During this test, ST testers can operate corresponding
sprint or s/w in various customer expected platforms. Platform means operating system browser,ios and other
system softwares.

c)H/w configuration Testing:

This testing is also called as H/w compatibility testing. During this test, ST testers can operate sprint or
s/w with hardware configurations.

Eg: 1)Different capacity hardware

2)Different topology networks...etc

Performance testing:

Performace means speed in process. Performance testing is classified into subtests

-->Run srpint or s/w in customer expected configured environment by appling customer expected load to
estimate speed in process called as load testing.

--> Run sprint or s/w in customer expected configured environment by applying more than customer expected
load to estimate peakload/load capacity called as stress testing.

-->Run sprint or s/w in customer expected configured environment by applying huge load to estimate server
crashing called as spike testing.

-->Run sprint or s/w in customer expected configured environment by applying customer expected load for long
time to estimate memory leakages called as endurance testing

Security Testing:

This testing is classifed into below subtests

1)Authorization/Authentication testing: It means whether our sprint/S/w is allowing valid user and presenting
invalid user or nor

2)Acess Control testing means that sprint/S/w are accessible to valid users with permissions or previliges or not

Encryption/Decryption testing: It means sprint or s/w Encryption process is strong or not.

Note: In above 3 security testing topics, Encryption/Decryption testing is possible to conduct who have hacking
knoeledge. In general, a separate security testing on bond basis and provide training to the team.

Multilanguity Testing: When a sprint/s/w was developed using java unicoe or dotnet unicode, corresponding
Sprint/S/w can take multiple inputs and give multiple outputs onmultiple people languages like english, french,
hindi, tamil and japanese. During this testing, ST testers can follow below 2 ways.

Parellel Testing: When a sprint/S/w is product based, ST testers can compare corresponding sprint/S/w with
previous versions of some software and with the competitive s/w to identify strength and weaknesses. Due to
this reason Parellel testing is also called as Comparison testing

Compliance Testing: This testing is also called as Standards testing or policy testing. During this test,
management people can verify progress of testers work w.r.to company policies.

Eg:
-->15 to 20 TS's with TC's preparation per day

-->10 to 15 TS's with TC's execution per day

-->3 to 5 defects defected per day

5.Acceptance testing.

During this test, Management(PO and SM) can try to collect feedback fro customer(Real or model). Here
management and ST can follow anyone of 2 ways to collect feedback such as alpha test and beta test

Note: When real/model customer feedback is not good, corresponding team can
perform instant changes and test those changes to satisfy the customet.

VI)Release testing:
-------------------

After completion of acceptance testing, management and ST can perform sprint

relaese. For it, PO will select few developers and testers called as release
team/onsite team/deployment team/Delivery team.

This team can install sprint/s/w in customer site network and observe below factors:
VII) Testing during maintainance:
---------------------------------
After completion of relaese process, Management (PO & SM) can select some trained freshers to form
CCB(Change control board). This team is responsible to handle change requests.
Note1: DRE stands for Defect Removal efficiency
A
DRE=-----
A+B
A--> no of bugs in testing stage by testers =80
B-->no of failures came in customer site to end users =10

80 80 8
DRE=------= ----=----=0.89
80+10 90 9

Note2: Reasoble DRE of a tester is 0.8 to 0.9

Note3: 100% bug free software is not possible.