Learning & Knowledge Sharing Schedule for Next 21 days effect from tonight 12 am till 14th April

Notes will be created & shared (using memory mapping technique) as per below plan

Module Date
1.       Principle of testing 3/25/2020
2.       SDLC Models 3/26/2020
3.       White Box Testing & its types 3/27/2020
4.       Black Box Testing & its types 3/28/2020
5.       Integration testing 3/29/2020
6.       System & Acceptance Testing 3/30/2020
7.       Performance Testing 3/31/2020
8.       Regression Testing 4/1/2020
9.       Internationalization testing 4/2/2020
10.   Ad HoC Testing 4/3/2020
11.   Testing Object Oriented Systems 4/4/2020
12.   Usability & Accessibility testing 4/5/2020
13.   Common People issues 4/6/2020
14.   Organization Structure for Testing Team 4/7/2020
15.   Test planning, Management, Execution Reporting 4/8/2020
16.   Software Test Automation 4/9/2020
17.   Test Metrics & Measurement 4/10/2020
18.   Recap & Revised Notes for 1 to 5 points 4/11/2020
19.   Recap & Revised Notes for 5 to 10 points 4/12/2020
20.   Recap & Revised Notes for 11 to 15 points 4/13/2020
21.   Interview Questions on the above topics 4/14/2020
m till 14th April

Status
Completed
Principle of t
Average Read Time ~30 m
e of testing
ead Time ~30 minutes
What is software testing
the process of ensuring the functionality of final product meets the user's requirement.

Why its needed

To avoid critical failures iin the real world

Fundament testing priciples

1. Goal of testing is to find defects before customers find them out
2. Exhausting testing is not possible
3. Early Testing : Testing applies all through the software life cycle & is not an end of cycle activity
4. Understand the reason behind the test
5. Test the test first
6. Tests develop immunity & have to be revised constsantly
7. Defects occurs in convoys or clusters, & testing should focus on these convoys
8. Testing encompasses defect prevention
9. Testing is fine balance of defect prevention & defect detection
10. Intelligent & well planned automation is key to realizing the benefits of testing
11. Testing requires talaented, commited people who belive I nthemselves
requirement.

an end of cycle activity

Goal of testing is to find defects before customers find them out

Short Story
The Incomplete Car

Car Salesman to Cutomer

This car is complete - you just need to paint it
Customer to Car Salesman
Okay…Can I have a test drive
Car Salesman to Cutomer
Sure..(While driving)
This car has the best accelartion machanism & reches
80 mph in 20 seconds
Customer
Well …Unfortuantly it accelarates faster when I press Break pedal

Conclusion
Testing should focus on finding defects before customers find them
sm & reches
Exhaustive testing Not Possible

What it is
Exersizing all combinations of inputs & precondtions

How much time required

Impractical amount of time

Conclusion
Testing proves presence of defects, never their absence
Early Testing
Testing applies all through the software life cycle & is not an end of cycle activity

Requirment Phase Correct requirment Defect In Requirment

Design Phase Correct Design Defect In Requirment Defect in Design

Coding Phase Correct Code Defect In Requirment Defect in Design

Testing Phase Defect Found Defect In Requirment Defect in Design

Conclusion
A test in Time
Defects in Code

Defects in Code Defects not Found

Understand the reason behind the test
Testing requires asking about & understanding what you are trying to test, knowing what the correct out

White Box Testing checks Various paths in the code

Black Box Testing checks Externatal functionality of product

Integration Testing checks Different component fits together

Regrssion Testing checks Introduced changes do not have any uninteded

Conclusion
Why one test
is as important as
What to test
&
How to test
nowing what the correct outcoem is & why you are performing any test

lity of product

t fits together

do not have any uninteded side effect

Test the Tests First
Test are artifacts like the code as its also produced by Human

Can't assume it to be perfect

Should that Expected output drafted & verified by SMEs & Busienss

Conclusion
A defective test is more worst than a defect product
Pesticide Paradox
Defects are like pests
Testing is like designing right pesticide to catch an kill the pests

Pesticide paradox says - if the same set of test cases are executed again and again over the period of time then thes

Given the complex nature of softwares & integrated components, somehow it difficult to kill all the pests & they srv

And that’s where we QEAs comes into picture

Conclusion
Test are like Pesticide
You have to constantly revise their composition
to tackle new pests
er the period of time then these set of tests are not capable enough to identify new defects in the system

t to kill all the pests & they srvive and keep haunting customer & cause untold havoc
Defect Clusting

majority of the defects are caused by a small number of modules,

i.e. the distribution of defects are not across the application but rather centralized in
limited sections of the application.

Conclusion
Testing can only find a part of defects that exitin a cluster
Fixing a defect may introduce another defect to the cluster
Defect Prevention
Testing encompassed defect prevention
Tester should analyze the root cause for falling & advise prevention action

Quality Control focuses on Defect Detection

Quality Assurance focuses on Defect Prevention

Conclusion
Prevention is better than Cure
Automation Syndrome

Testin by nature, involves repetative work. Its lends itself natuarally to Autoamtion

Autoamtion is a double-edged sword

Things to keep in mind before adopting automation

Why you want to automate & what you want to automate

Do proper POC (Proof of concept) before choosing tools
Choose tools to match customer & product requriment
Train people first then expect
Do not expect overnight returns

Conclusion
Autoamtion requries carefull
Planining
evaluation
Training
SDLC Mod
Average Read Time ~ 25 m
C Models
ad Time ~ 25 minutes
Phases of SW Projects
Reqirment Gathering & Analysis
Specific requriments of the software to be built are gathered & documented
Requriments are documented in terms of SRS
SRS acts as a bridge between Customers & designers charted to build the product
Planing
States that come up with a schedule, the scope & resource requirment for release
It explains how requirment will be met & by which time
Design
Phase to figure out the requirments enumerated in the SRS docs
Design has two levels
Low Level design details
High Level design details
Developers uses SDD( System Design Discription) to produce the program that realize the des
Testing
Software builds is throughly tested to esure functional & non functional aspects beforr hando
Deployment & Maintenance
Customers deployed the product in to PROD envirnment after perfromign UAT
Deployed product is then under continuous maintenace
There are two types of maintenace
Corrective Provides hot fixes for the i
Adeptive Provides fixes as per the ch
uild the product

ment for release

rogram that realize the design

tional aspects beforr handovering to Customers

fromign UAT

Provides hot fixes for the issues identifed by real users

Provides fixes as per the chaning needs of the business
Quality
Meeting the requirments expected of the software, consistently & predictably

QC{Quality Control}
discovery of the defects and modifying them while making the product
detects defects in product
Product oriented
failure detection system.
Focus on method to verify the quality-Validation
Comes once QA is Done
 QA{Quality Assurance}
processes are planned to evade the defects
detects weakness of product
Process oriented & Domain Experts
failure prevention system
Focus on method to manage the quality- Verification
Comes before QC
Testing
Investigation process to make product free of any critcal (user impact) issue
BUG FREE PRODUCT DO EXITS IN WORLD OF DREMS NOT IN REALITY
Investigation process carried out in two methods or ways or approaches
tion process to make product free of any critcal (user impact) issue
BUG FREE PRODUCT DO EXITS IN WORLD OF DREMS NOT IN REALITY
tion process carried out in two methods or ways or approaches

Verification
3. It is performed, over software product, which is under the development stage.
4. Verification is answerable for "Are we building the product, right?"

6. It is carried out, for preventing defects in the software product.

7. Techniques to perform verification includes static activities, such as:

Reviews. {Test Plan, Code, Test Case Rewiew etc}
Inspections.{Formal Approach to requirment Schedule. It has proper schedule}
Walkthroughs. {Formal Review & can take palce at any Time. Its not Meeting}
Meetings.
8. The job is done by the QA team.
9. A type of low level activity.
10. Performed, only manually.
11. Verification is cost effective and less time-taken activity.
Note
Quality Assurance = Verification
 Validation
3. It takes on final software product, produced, after the completion of the development process.
4. Validation is accountable for "Are we building the right product?"
6. Responsible for tracing and removing the defects, that were missed or unavoidable, by the verification
process.
7. It covers all the actual and dynamic testing techniques, such as:
Black-Box testing.
White-Box testing.
Grey-Box testing.
Acceptance testing.
8. Requires specific and dedicated testing team.
9. A form of high level exercise.
10. May be manual or automated or both.
11.Whereas Validation is costly and time-consuming process.

Quality Control = Validation/Testing

Process Model
A way to represent any given phase of software development that effectively builds in the concepts of validation &
between defect injection & defect detection (i.e. Characterize a phase of a project)

Type of Process Model High Level ETVX Model

ETVX stands for Entry, Task, Verification, and Exit.

ENTRY CRITERIA: Input with ‘condition’ attached.

e.g. Approved SRS document is the entry criteria for the design phase.
TASK: Procedures.
e.g. Preparation of HLD, LLD etc.
VALIDATION: Building quality & Verification activities
e.g. Technical reviews
EXIT CRITERIA: Output with ‘condition’ attached.
e.g. Approved design document
Low Level ETVX model

Entry Criteria
Approval of SRS by customers

Input
Approved SRS
n the concepts of validation & verification to prevent & minimize delays

l ETVX Model

ETVX model Steps :

1. Evolve an architecture
2. Perform High level design
3. Perform detailed low level Exit Criteria
of SRS by customers design Complete tracebility between design & SRS
4. Write program spaces
Development team ready to start programming

Approved SRS Output

Architecture document
Design Document & program specification
Life Cycle Model
Represents how the phases combine together to form a complete project or life cycle
It is characterized by following attributes :

Activites Performed Requirment gathering & analysis, development, te

Deliverables for Each Activites Requirment gathering produces SRS docs
Method of validaiton of deliverables
Sequence of activites
Methods of Verification
Types of Life Cycle Model

Waterfall
Phaaes are strictly time squenced
Characterized by three attributes
1. Project is divided into separate distinct phases
2. Each pahse commuincates to the next through specifed output
3. When error is detected it is traced back to one previous pashes at a time until its gets resol

Prototyping
1. Uses constant user intreaction, early in the requirment gathering stage to produce a protot
2. SRS will be drived from devloped prototype
3. Appropriate life cycle model is chosen to for building the actual product
Spiral or Iterative
1.Requirment gathering & analysis, development, testing are perfomed iteratively until requir
2. Good amount of overlap is the key of this model
V Model
1. Splits testing into two parts - design & execution
2. Test design is done early, while test execution is done in the end
3. There are different types of tests for each phhase of life cycle
 g & analysis, development, testing & maintenance
g produces SRS docs

es at a time until its gets resolved.

ring stage to produce a prototype

erfomed iteratively until requirments are met.