Software Testing Introduction

What is Testing
SDLC Life cycle
Software Testing Methodologies
Requirements Evaluation

Testing is checking for the defects , checking if product is as per customer’s

expectations
We evaluate the requirements documentation against the product

Losses due to lack of Software Testing :

Loss of Money
Loss of Time
Loss of Business Reputation

Activities of Software Testing :

Test Planning
Test Analysis
Test Designing
Test Implementation
Report the test Progress

Manual Testing : Write Testcases and then we execute testcases , without any tool
support

Automation Testing : Testing using Tools like selenium , UFT

Who does Testing ?

Developers do the testing – Unit Testing
Users do the testing – Acceptance Testing
Everyone does the testing ----- Stakeholders

When Do we do testing ?
Testing is done right from the requirements gathering
Static Testing – testing of documents and code
Dynamic Testing – run the testcases over the product
When dynamic testing –
-Build ready and thoroughly tested by dev team
-Testcases are written and reviewed
- Test Environment should be all set
- Test data should be ready
- Testers should be ready

When to stop testing :

- All of the planned testcases are executed and there are no any critical defects in
the product
- Management decides considering many of the business factors
- Risk is minimal

Software Development Lifecycle :

- Sequential Software Development Model ( WaterFall Model)

When to use Waterfall Model
1. When the requirements are constant and not changed regularly
2. A project has enough amount of time to develop.

V- Model : Early Testing , Ontime delivery

Iterative Incremental Model : Based on V-Model, we deliver the chunk of
prioritized requirements in iterations and then keep on adding more
requirements as increments.
 Agile Methodology : Its not a Model, but it’s a way we work.

• Quick/ Swift
• Based on iterative increamental model
• Focus on working software
• Less Documentation
• 2-4 weeks for iteration

Spiral Model : objective is : Risk Handling

Testers Quality :
Positive Psychology / Attitude
Start with collaboration rather than battles
Communicate test results in neutral , fact focused, do not criticizing developers
Try to understand how other person feels
Confirm that the other person has understood clearly what u r saying
Critical eye, attention to detail, Motivated, positively behaviour

STLC: Software Testing Lifecycle

Test Design Techniques :

EP
BVA
Decision Table
State Transition Testing
Use Case Testing

QA / QC :
QA ( Quality Assurance) : QA is an Activity that ensures the approaches, techniques,
processes are implements and followed correctly to prevent the defects.
It’s a defect prevention technique

Quality Control : We test the working software to find defects and controlling the
quality
Reactive process

QC is a subset of QA

Regression Testing :
Type of testing which is performed to find out whether the changes which r done
recently had caused new defects in the existing functionalities.

Agile Methodology : (Continuous Iterations)

Why to go for agile

Increased customer satisfaction

Lower defect rates
Faster development times
Rapidly changing requirements - uses early feedback on technology features of project
deliverables

Disadvantages :
Poor resource planning may happen
Limited Documentation
No Finite End

Agile Manifesto – Policy

Principles of Agile Manifesto

12 Principles of Agile as Propagated by Agile Alliance are:

1. One of the top priorities of the Agile approach is to aim for

customer satisfaction through prompt and continual

delivery of value-added products.

2. The agile approach has to embrace changes, even at later

stages of development. Change is considered as a valuable

agent offering a competitive edge to the customers.

3. Working software should be delivered to the customers for

any feedback or suggestions at a periodic interval of weeks

or months, preferably in shorter time spans.

4. The business management and system developers should

work collaboratively throughout the project cycle

5. The agile approach believes in assigning projects to

motivated individuals and provide the individuals with a

good working environment and support system by

inculcating trust in them to get the work done.

6. Agile Values And Principles are about fostering face-to-face

discussions and promoting them as an effective means

of communication to and within the team of developers

7. Working software is one of the primary means of measuring

system progress in agile.

8. The agile approach aims at facilitating consistent and

sustainable progress in system development. The

stakeholders are required to maintain steady and continual

velocity in product development.

9. Staying updated by bringing in continual technological up-

gradation and efficiency facilitates the agile approach

10. The agile process is about adopting simplicity by reducing

comprehensive tasks and focusing on the tasks that

essentially add value.

11. Self-organized teams help in bringing good structures,

requirements, and developments. The agile teams are proactive,

which enables them to overcome any hurdles and minimize

errors to deliver excellence.

12. Agile teams continually upgrade themselves and aim to

become more productive by adapting to changes effectively.

The development teams constantly mold and are at peace with the

changing external conditions. It enables continual improvisation to

deliver value

Introduction to Scrum

Scrum is an agile software development process to manage software projects

Teams using Scrum focus on delivering working software to their customers on a

frequent basis
There are three main roles in a Scrum team: ScrumMaster, Product Owner, and

Development Team including tester(usually 1 tester)

The ScrumMaster role is somewhat similar to a project manager.

ScrumMaster is responsible for making sure the team is moving as quickly as

possible, this role is more of a facilitator and coach than one that exercises control

and makes decisions. The ScrumMaster must be available at all times to remove

roadblocks and ensure that the team has all required resources for the job.
The Product Owner is a representative from the business side who determines

the priorities of the items to be developed. The Product Owner must be either on

site or highly available to the team at all times to answer questions and clarify

unclear requirements

The Development Team in Scrum can be composed of developers, QA, and

business analysts. They work technically.

Scrum Process:

Scrum projects are managed in short iterations (Sprints) where the team works

on the most important items of the project, as defined by the Product Owner, and

delivers potentially shippable code at the end of each iteration.

Everything in Scrum revolves around Sprints

Product Backlog - The entire list of requirements

Sprint Backlog – list of the requirements for one sprint

Daily Meeting : During the Sprint, team members get together on a daily basis

to report status to the team. The Scrum daily meeting-or daily scrum-is a

short meeting time boxed at 15 minutes in which each participant answers

three questions:

 What did you do since the last daily meeting?

 What will you do from now until the next daily meeting?
 Are there any roadblocks in your way?

Definition of “Done” in scrum

The Definition of Done is an agreed-upon set of items that must be completed before a

project or user story can be considered complete.

What is User Story : A user story is the smallest unit of work in an agile framework. It's an

end goal, not a feature, expressed from the software user's perspective
Sample User stories :

As a customer, I want to easily transfer money between my

accounts

As a manager, I want to be able to understand my

colleagues progress, so I can better report our success and

failures.

What are Story Points?

story point is a metric, used in agile project management to figure out

the implementation difficulty of a certain user story
Epic – Parent of multiple user stories

Smoke Testing:

Done to ensure that acute/basic functionalities of software are working well .

Done after a build is produced.

It’s a quick and shallow check

Sanity Testing : used to check if specific low level functionalities are working fine or

not
Done before product is released to the customer

It’s a detailed check of the functionalities

Verification : making sure that product is being developed the right way. = Static

testing

We do not run the product, but we verify if product is being developed in the right

way/manner.

Validation : Making sure that product is as per customer’s requirements. = Dynamic

testing

We run the product and verify if product is as per customer’s requirements

Verification is followed by Validation

Test Policy : One for the complete organization

Test Strategy : Separate Test Strategies per group project

Risk Based Testing : Risks related with the product are considered first and

testcases are prioritized based on the risks identified

Regression Averse : Regression is performed often in intervals

Reactive Test Strategy – we execute the product and we find defects. Depending on

the defects, we take actions

Test Plan – Project based test execution planning

Functional Testing : Testing the product as per requirements whether it is functioning

as per requirements or not.

Non functional Testing : Testing the product’s behavior.

Performance Testing – Response time of the app – 3s

Load Testing : Normal load is given to the application and measure the

performance(response time)

Stress Testing : Extreme load is given to the website and measure the performance

Volume Testing : Extreme Data load is given to the website and measure the

performance

Portability testing, reliability testing, security testing