Testing : in order to identify defects in the application which was developed by the

developer

what is the use of identifying defects in the application:

here tester will play a major role where he will decide the quality of the developed
application and once the tester certified that the application is working properly then only
that organisation will deliver application to the customer

it means tester is testing the application like an end user means how the end user will
perform various kinds of operations on an application tester will do all those things and he
will check application stability and quality as well

what are the various kinds of testing's we have:

testing was broadly categorized into 2 types:

1) functional testing :if we were testing functionality of the application

example: in the user registration for are we able to create an user to the application or not
which comes under functional testing

2) non functional testing : if at all we were testing non functional aspects like user interface
means whether text is properly displayed in the webpage or not, if at all 100 users were
accessing our application whether my application is responding properly or not

example1: whether all the fields were properly aligned or not

example2: if 100 users were accessing my application at a same time from different
locations whether my application will respond properly or not will be calculated here which
we usually call it as performance testing
manual testing: if we were testing the application manually which we call it as manual
testing

example: washing cloth's manually : 6hrs

Automation testing: if we write a small program to test the application which we call it as an
automation testing

example: using washing machine : 30mins

The main difference between manual testing and automation testing is when we go for
automation testing we can finish our execution or testing ASAP or within less time when
compared to that of manual testing

now a days inorder to test the functionality of the application majority of the people were
going for either QTP or selenium,

inorder to calculate the response time most of the people were going for either jmeter or
load runner

differences between functional and non functional automation testing:

functional automation tools will test the application functionality is working properly or not.
whereas the non functional automation tools will test whether application response
time(2secs or 5secs) is within the time limit or not
software application: a set of computer programs and minimum data to run those programs
which we call it as an software application

these set of computer programs may write using anyone of the programming languages or
scripting languages like java, .net, vb script

example: gmail, facebook, twitter etc we were suppossed to login to our gmail application
to login to gmail we need to give uid, pswd so this uid , pswd whatever we were entering to
login to this gmail application which we call it as minimum data and the background code
written by developers is which is an set of computer programs

project: if a software application is developed for a specific client

example: [email protected]

product: if a software application is developed for multiple customers which is an product

example: mobile, laptop, accessories, gmail, facebook, hotmail , yahoomail etc

SDLC: software development lifecycle : inorder to develop a new software or new

application what are all the various stages involved in developing that application comes
over here

The SDLC was broadly categorised into 6 different stages they were:

1) Gathering of requirements : in this stage BA (business Analyst) play a major role in which
he will interact with the customer and he will gather all the customer requirements and he
will prepare a document which we call it as requirement's document.

In the requirement specifications document he will a make a note of the client needs or
what is expecting or looking from that organisation

a) SRS or FRS: software requirement specifications or Function Requirement specification

b) BRS: Business Requirement specification

2) planning: in this phase PM or TM play a major role where they will prepare a plan how to
work on the project and who are going to work on the project and using which technology
they are going to develop that project

example: in our 1st class which is an demo class in which we discussed about how many
hours we are going to spend and on which days , and various topics i am going to cover and
duration of each and very topic

How we prepared a rough plan for our training the same way the organisation will prepare a
detailed plan to develop application and to deliver the application on time to the customer

***3) designing: The design phase comes after a good understanding of customer’s requirements,
this phase defines the elements of a system, the components, the security level, modules,
architecture and the different interfaces and type of data that goes through the system.

A general system design can be done with a pen and a piece of paper to determine how the system
will look like and how it will function, and then a detailed and expanded system design is produced,
and it will meet all functional and technical requirements, logically and physically.

The high-level design (HLD) phase focuses on system architecture and design. It provide overview of
solution, platform, system, product and service/process. An integration test plan is created in this
phase as well in order to test the pieces of the software systems ability to work together.

The low-level design (LLD) phase is where the actual software components are designed. It defines
the actual logic for each and every component of the system. Class diagram with all the methods and
relation between classes comes under LLD. Component tests are created in this phase as well.

example: assume that we were planning to construct a small house by default we won
construct it means we usually prepare a plan like how much area we have in which how
many rooms we want and in which how many floors we want everything will be written on
an paper 1st and then by comparing this paper will construct the house accordingly??

4) coding: here developers plays a major role where based on the client requirement and
prepared design they will write set of computer programs in the selected programming
langauge for the requirements based on architecture and SRS or BRS

5) testing: we the testers plays a major role in which we will test the application which was
developed by the developers as an end user like a customer to check whether the
application is having any issues or not and we will decide the quality of the application

6) delivery and maintenance: once after the tester confirmed that there were no issues in
the application developed by the developer's then that organisation will deliver the
application to the customer which we call it as an delivery of application to the customer
Maintenance: as the customer wont have any idea about the application from our
organisation a person who is having entire knowledge on that project will work with
customer to explain all the application functionality and even if the customer needs any
modifications in the application we will do all those under this maintenance phase

SDLC Models:

An SDLC model will demonstrate or tells us how all SDLC activities will be carried out in
developing an software application

sometimes these activities will be carried out one after another and in some cases these
activities will be done simultaneously or in parallel

SDLC was broadly categorized into 2 models:

1) sequential model

2) iterative model

sequential model: In this model all the SDLC activates will be carried out one after another
like after finishing the requirements gathering then only we will move to planning phase the
same after finishing planning then only will move to designing phase etc. These kind of
model is best suitable for small applications

iterative model : in this model all the SDLC activates will be carried out simultaneously it
means a big project will be divided into multiple modules and a specific team will work on
each and every module. this is suitable for big size of applications

Both waterfall and vmodel will choose for small size of projects
a) Waterfall model: we may observe steps for a building means 1st will gather the
requirements then we will move to next phase which is design then will move to
planning then coding then testing then delivery phase
In this model all the SDLC stages were conducted one after another for entire
application .
 This model is best suitable for small size of applications where the requirements
of the application were clear
For each and every of SDLC activities based on early testing we need to perform
that .. as the requirements were 100% clear we no need to do any verification we
can simply go for a hit with validation itself

b) V model: if at all the requirements were not clear then we will for this model and
here as the requirements were not clear we need to do verification and
validation too
This model is also suitable for small size of applications

Iterative model : this model is suitable for big size of projects where a big project was
divided into multiple modules then for each and every module the SDLC activities
will be conducted

a) RAD model (Rapid application development model): In RAD model a big project
will be divided into multiple small modules and where each and every module is
considered as a separate project and for the individual models if we have
separate teams to work on that
These teams will take care about implementing all SDLC activities for their
corresponding modules simultaneously once all the modules were implemented
these will be combined together and delivered to the customer
This is an expensive model for organisation why because more resources
required to work on these kinds of projects.
When can prefer this model means if there is a short time to deliver the project
to the customer and if the requirements were clear

b) Prototype model: if the requirements were not clear and the application is of big
size
 In this model a dummy application or prototype will be developed and
demonstrated to the customer once we got the approval for that prototype
means then only we will perform the real project implementation based on
customer feedback the remaining stages will be carried out for entire project
Change request: once after successfully finishing the application and while the
customer is testing that application if he needs any modifications we will
documents those as change requests

c) Spiral model: is best suitable for maintenance projects in these the requirements
were frequently changing
In this model once a basic system was developed based o n the customer
business demands the new functionality or we can modify the existing
functionalities

d) Agile Methodology:

Agile model believes that every project needs to be handled differently and
the existing methods need to be tailored to best suit the project
requirements. In agile the tasks are divided to time boxes (small time
frames) to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after

each iteration. Each build is incremental in terms of features; the final
build holds all the features required by the customer.

Here is a graphical illustration of the Agile Model:

Agile Testing: a s/w testing practice that follows the principles of agile s/w development

On a frequent interaction with the customer we r going to dvelop the app and we will devlier the
app to the customer

Advantages of agile testing???

1. Less documentation
2. Regular feedback from the customer
3. Saves time and memory
4. Within the team will help to understand the various issues in advance..

SDLC : Testing as a phase

Agile : we r not considering test as a phase: usually the testing team will interate with the
developers r the agile team and will test the app whenever we got some functionality to test.

Right after story code: immeditaly we will conduct testing n we will provide feedback to the
developers on the user stories/requirement

1. Not only the testing team, within this agile its going to multiple people who supports in
testing.. example for this BA >> if we have bunch of requirements to test then they will help
us in testing in the application… not only testers everyone wil involve In testing the
applications.. we will have sprint demo internal , client demo also… at that time majority of
the cases BA will give demo…
In this agile, developers will get feedback on the requirements within short span of time , including
total no of defects , UI issue and requirement gap all the stuff we r going to provide asap..

Developers are fix the defects whatever we reaised either wintin the same spritn ,pr if there are
more number of defects then they will fix in the ext sprint

Documentation is very limited

● Automation testing is the key point in agile

● Automation regression testing
● Explortray testing on the application

3 definitions:

error/mistake: an incorrect human actions which leads to problem in an application

example: assume that BA captured an invalid requirement it means client is looking for a+b
where as BA captured a*b , based on the BA requirements remaining all phases were
finished and finally when we try to deliver that application to the customer he will simply
reject that because he is looking for a+b where as we developed a*b

bug/defect/incident/issue: if there exists a deviation between expected result and actual

result which we call it as an defect or bug.

example: assume that we were waiting for a train in station and the train was supposed to
come at 6:30AM but on that day train has arrived at 8:30AM

from the above example 6:30 is the expected time and 8:30 is the actual time

expected result: enter uid, swd and click on login button then inbox should display for us
actual result: when we were working on an application if we enter uid, pswd and click on
login button what exactly the application got displayed which we call it as an actual result

expected result we can get it from SRS or BRS where as actual result we can see in the
application

if expected result and actual result both were one and the same then that scenario is passed
where as if both were not equal which we call it as an failure which is a bug or defect in the
application

failure: if a defect is identified by end user who is a customer then we call it as an failure

once after testers finished their testing and that organisation delivered application to the
customer when the customer is working on something he identified an issue it means
testers were not tested that application properly in these cases simply customer will reject
the application

what is a software testing:

it is the process of verifying are we developing the right product or not and validating
whether the developed product is right or not

software testing ==> are we developing right product + developed product is right or not

software testing ==> verification(developers) + validation(testers)

verification: developers while developing the application they will cross check whether they
were developing the correct application or not by comparing with the requirements and
architecture of the application

even in the verification not only developers will play a major role even testers also and even
almost all the team members will play a role here because if BA prepared one SRS document
he will cross check it once before giving it to planning phase which we call it as verification

validation: once after the developer finished their developing and now testers will play a
major role , where they will test the application whether developer developed proper code
or not which is basically meeting the customer requirements or not

early testing: Applying software testing(Verification & Validation) as soon as possible in

SDLC which we call it as an early testing.

early testing : applying verification + validation in SDLC ASAP

why we need to conduct early testing :

example: assume that BA gathered requirements and without reviewing those requirements
remaining phases were designed like planning , designing, coding , testing and delivery and
at last in delivery customer rejected the application reason is he is looking for a+b but we
developed a*b if we observe inorder ti develop this project roughly around 3months time
was spent

below are the chances where we may get issues :

1) gathering incorrect requirements

2) wrong design

3) poor coding

4) complex application technology

So to avoid these kind of things which is application rejection from the customer we are
conducting software testing which is verification + validation in each and every stage of
SDLC which we call it as an early testing

whenever the documents comes into picture then we usually review those documents
which is verification so below is the updated SDLC chart

so once after BA gathered the requirements then another BA and client will review that
document

Testing approach's:

in-order to test a software application we have 2 different methods or approach's

1) traditional approach
2) better testing approach

example: we were supposed to move from one place to another place so we have various
options like we may either go by car, or flight or by train

how we were having these many ways to move from one place to another place the same
way we are having 2 methods to test any software application

example: developer developed code for a+b and while developing he wil check whether
addition functionality is working or not like he will give inputs as 2 and 3 and he will check
whether 5 is displaying or not

even the tester also doing the same thing means is there any chance for us to identify
defects in that application

so the tester need to test in a way like give -5, -10 and see the output

Traditional approach:

● in this we will do what system will do

example: gmail login scenario always we will enter valid userid, valid pswd and click
on login button and we always check whether application inbox page is displaying or
not
● positive testing means from above example 2,3 etc
● in this type as we were testing like the developers only there is a less chance for us
to identify the defects
● goal : to show application is always working successfully

Better testing approach:

● in this we will do what system shouldn't do

example: gmail login scenario we will test this scenario with valid inputs and invalid
inputs and we will check what exactly my application is doing or behaving when we
give invalid inputs to that
● positive and negative testing from above example -4,-10 etc
● we can find more defects in the application
● goal: to show application is having some issues

so as we know about these 2 in detailed so when we were testing the application which
method you will prefer

answer: better testing approach

it means whenever we were testing an application we usually think both positive scenario
and negative scenarios for that application
whenever we were testing any software application below are the places where we usually
identify defects in application:

1) incorrect functionality : a+b but they developed a*b

2) incorrect data edits: assume that we have date field in the application generally date field
means it needs to accept only numeric's right?? but in some applications while developing
them they forgot to add date field validations so that application will accept alphabets and
special characters in that fields

3) poor UI ( user interface) :

4) poor performance: if number of users were increasing then the application response time
will vary
software testing == verification+ validation

verification or static testing

validation or dynamic testing

verification or static testing techniques:

review: examining or cross checking project related work or tasks which we call it as an
review.

example: we drafted one mail and we were supposed to send that mail to our project
manager so before sending that mail we will cross check whether any spelling mistakes
were there in that mail or not we will check which we call it as one kind of review

walkthrough or knowledge transfer: a step by step presentation conducted by domain

experts about a subject or about a process or about a project to provide common
understanding to the team members is walkthrough
example: we joined in an organisation and we were assigned for a project we don't know
anything about that project so a team member who is having a good experience on that
project he will share some knowledge to us which we call it as KT which is knowledge
transfer sessions

reviews were broadly categorized into 5types:

1) management review: these reviews will be conducted by high level management or

middle level management which is PM or TM to identify the deviation between planned
effort and actual effort.

we were supposed to finish 5hrs till today they will check whether 5hrs were completed or
not instead of 5hrs if i took only 2hrs which we call it as an deviation

while conducting management reviews if they identify any deviations management people
will take necessary corrective actions to cover those deviations. so that we can able to finish
our task in time

with this kind of review we can finish our training by Nov 15th

slippages: if there is a deviation between planned effort and actual effort

example: i am giving some training to you guys and we were supposed to finished this
training by Nov 15th so a person from USM will track this training whether we were on track
to finish this training by the expected date or not
2) technical review: technical reviews will be conducted within the team members to decide
the best approach of implementing a task if we have any doubts while implementing

example: discussion happening within the team members about a new project on which
technology they want to develop means whether .net is best suitable for this project or java
is best suitable for this project or ruby etc they will discuss advantages and even dis
advantages

example: QTP or selenium so discussion happening within the team members to automate
our project using QTP or selenium to decide which is best suitable for our current project

3) code review: one developer/testers(in automation testing) prepare a code or software

application and another developer will cross check his code like did he implemented all the
requirements or not. This we also call it as Peer reviews

4) formal review: if a review is conducted with a pre-plan and by following systematic

procedures and proper documentation then these reviews we call them as formal reviews

example: we planned for a review on 10th Dec (pre-plan), someone will attend my session
and check whether i am teaching properly or not and whether i am preparing running notes
or not(systematic procedure) and whatever the issues they identify if they draft them in a
mail and send to me which we call it as in formal review

example: Audit and Inspections

Audit: if a formal review is conducted after completing the task

Example: once after finishing the class if they cross check all my running notes and videos
which we call it as an audit because here the class was completed

Inspection: if a formal review is conducted while performing the task or executing the task

example: we are conducting classes all of a sudden USM guys joined todays class and they
will check whether i am teaching properly or not

5)informal review: this is quite opposite to formal review

if a review is conducted without any pre-plan without following any systematic procedures
and without having any documents which we call it as informal review

objective of conducting review or why we are conducting reviews:

this answer is similar to that of why we are going for early testing

1) to find the defects in the requirements and in the designing phase

2) to identify the deviations between planned effort and actual effort

dynamic testing or validation: it is a process of validation whether the developed product is
right or not

here developers who were validating their code comes into this case it means they will cross
check their code by executing couple of times which also comes under this validation

Dynamic testing was broadly categorized into 3 types:

1) WBT: white box testing: related to developers: testing conducted on the source code by
the developers to ensure 100% code coverage means once after developing was finished
developer will check whether he written the code for all the requirements or not

we also call it as glass box testing or clear box testing

WBT=Unit testing + integration testing : the combination of unit testing and integration
testing

why we need to perform WBT???

1) Finding defects is easy as source code is visible

2) to remove as many defects as possible from the source code

3) fixing the defects that are identified by testers were time consuming to analyse the root
cause behind failure

4) to ensure 100% code coverage

Unit Testing: testing conducted on smallest se-pertable portions in the source code means
functions, methods whatever written in the source code

Function: assume you want to write code for below 3 scenario:

1) login to application , create user , logout

2) login to application, edit user, logout

3) login to application , delete user, logout

if we observe login and logout is common for all the 3 scenarios so instead of writing login
and logout 3 times write code 1 one time and call it multiple times and 1 time writing the
code and multiple times calling which we call it as an function or method

Integration Testing: once after unit testing was conducted successfully , then developer will
combine all the units into a big module and checks the interactions among these units which
we call it as an integration testing
example: assume that your application has 5 modules at 1st developer will check indivually
whether module1, module 2 , module 3 , module 4, module 5 is working successfully or not
once all these 5 works indivually then they will add or combine all these modules together
which will looks like bing.com links

2) BBT: black box testing: related to tester

3) GBT: graybox testing: related to tester

scenario: developers got a mail from manager that they have a demo with client to
demonstrate the source code prepared till now actually for that demo developers need to
finish 3 modules in the applications.. but they developed only 2 modules.. now how can they
handle demo????

integration testing was conducted I 3 different approaches:

1) Bigbang integration testing:

This approach is recommended when all the modules in the source code were
developed successfully
A+B+C
2) Topdown integration testing: if at all some module in the last portion were not yet
developed then they will use this method and the undeveloped code they will
replace with a dummy program (will execute successfully always) stub
3) Bottomup integration testing: if at all they were some undeveloped code at the
staring portion then they will replace that code with dummy
program and the name program of dummy program using in driver
Stub and drivers both were the dummy programs developed by developers in order to
perform integration testing

blackbox testing: testing conducted on the application by the testers to check does the
applications works as per the customers business requirements or not

or
testing conducted on the application by the testers to ensure 100% requirement
coverage

BBT= system testing+ user acceptance testing

Advantages of BBT or why we are going for BBT???

1) WBT was conducted by dev in technical point of view means whether that module is
working with valid inputs or not. But tester will test the application as an end user
point of view
2) A programmer will not work with an intension to find defects in the app where as a
tester will work with an intension to find defects in the application
3) To check non functional accepts of the application such as performance , load and
security etc

Exhaustive testing: testing a functionality with all valid and invalid inputs is called as an
exhaustive testing

Or

Testing everything is called an exhaustive testing or in-depth testing or in-detailed testing

But in the real time exhaustive testing is impossible…

Example: take a gmail login scenario where we need to eneter valid uid, valid pswd and
clickon sigin button

Invalid: with empty inputs, with empty uid , with empty pswd, with incorrect uid, with in
correct pswd

So to avoid this exhaustive testing and also to ensure 100% requirement coverage we
usually go for this BBT techniques

Techniques in BBT:

1) Equivalence class part-ion testing:

Once we got the application for testing 1st analyse all possible operations carried bu end
use then identify valid and invalid among them

Then divide this data into partions or groups while making a partion make sure that all
inputs belong to one group producing same o/p from the application

Example: assume that there is an webedit field or else text filed and a button in the
application which we need to test and that text field will accept all the inputs like from 0 to
9 and A-Z, a-z, all special characters null characters it means while testing the application we
need to test that field with entering 0,1,2,3…9 and then a,b…..z and A,B,,,,,Z and !,@,#,$......
roughly inroder to test that field itself it will take too many hours for us so inroder to
overcome that one we are moving to equivalance class partion testing

So here in this ECP we are diving all the inputs into groups: (0-9), (A-Z),(a-z),(!,@,#,%..) so in
this ECP from the 1st group instead of testing with 0,1,2..9 we will take one middle value
and we can perform the testing

(0-9)🡺 5middle value and we are testing the application

(A-Z)🡺 M

(a-z)🡺 m

(!@#$) 🡺 $

2) Boundary value analysis: it has observed that most of the times developers are
committing mistakes while specifying the boundary conditions (<,>,<=,>=) to find the
such kind of defects we usually go for this BVA
According to BVA indentify the portions where there are ranges then determine
outer boundary and inner boundary
Lower boundary = Lower boundary value-1
Upper boundary= upper boundary value+1
Example:
 Finance where we need to test all the price related scenarios: loan section in any
banks: assume that based on the amount we have taken the intrest rate might vary

>10rs – <1000RS 🡺 1.9 (1000)

LBV=10
LB=10-1 =9 so pass this 9 as a input to application and test how exactly it is working
UBV=1000
UB=1000+1=999
1001- 5000 🡺 2.9
5001 – 10000 🡺 5.9
With ECP instead of testing our application with all inputs from 10 to 1000 we will
take a middle value and we wil test that

3) Decision table : this is introduced to derive test conditions to check a functionality if

it is depending on multiple inputs
Example: DDT is usually prefer in order to find defects at logical conditions like
implementation of AND, OR, NOT etc(Boolean)
 A AND
A B B A or B
0 0 0 0
0 1 0 1
1 0 0 1
1 1 1 1

4) State transition : to check the entire navigation present in an application we usually

go for this STT
Every s/w application will have various stages i.e based on your action the page will
move from one page to another page

5) Use case: a use case contains a brief description of actors action and system reaction
Grey box Testing:

example: assume that we are working on banking application which contains various
credentials or various types of users like admin, bankes and customers. so whenever we
entered admin credentials application should display admin home page, if we entered
customer credentials then application should display customer home page and even if we
enter banker credentials application should display bankers home page. usually how this will
work means soon after we entered credentials the application will go to database and it will
search for this user and it will retrieve the information related to that user

it is an combination of both WBT and BBT

where we are concentrating on the how the information is retrieving from the database will
be observed here, means whether it is retrieving proper information from DB or not
we can access the tenant site using those set of credentials....

admin we are going to login into the application where in which

1) create user, edit user, delete user

2) create roles, edit roles, delete roles

3) Manage themes

4) RFQ: request for quote form: by default 3 fields :

5) manage entities/fields for RFQ form: he can create or he can delete those fields

Sample Application:

TCS: 5000$, 3months of time, 750$ for maintainace

IBM: 7000$, 2months of time, 1000$

If TCS developed the project and if they can place the application on internet then everyone can
access that, subscribe for year : 500$

2 different web sites:

1) registration part : onboard engine

2) tenant administrator: or can be accessed by all the employees within the organisation

www.cloudcomputing/com/procureASugo/TCS: unique user name and pswd will be generated

www.cloudcomputing/com/procureASugo/INFOSYS

www.cloudcomputing/com/procureASugo/IBM
 Manual Testing:

which is a testing phase once after developing was finished by the developers then this
testing phase comes into picture where a tester will play a major role here so in this testing
phase once after we got application for testing what are all the various stages involved to
perform testing which we cover in the testing phase the combination all these stages which
we call it as software testing life cycle

software testing life cycle or STLC: in which once we got application for testing what are the
various stages involved in the application to perform testing which we call it as an STLC-
the various stages were :

testing planning: PM or TM or TL will play a major role: in this phase they will decide how
they were going to test this application. In this phase test policy, test strategy, test plan will
be prepared

test policy : each and every organisation has its own policy to test an application so in this
phase they will check about their organisation policies to test the application

test strategy: a high level plan and approach for testing the application which was prepared
by PM or TM or TL we call it as test strategy

Test plan: based on the test strategy prepared by PM ,TL will prepare a detailed plan and
approach of testing software application which we call it as an test plan means how many
resources were working on this project, how many hours we were planning to finish this
testing etc

this test plan document acts like a road map for a tester

test analysis: as tester is going to test the application so he will play a major role here means
he will study the entire application the main objective of this analysis is to get 100%
understanding about the application because as we were testing the application we need to
know the flow of the application and what are the various features involved in the
application we will study all these things here and finally we will try to understand
application functionality and the main objective of the application which is why they
designed this application

The tester will study the BRS or SRS documents to under for what the application is
developed
test design: tester will play a major role, tester will prepare couple of documents which
were test scenario's and test cases documents

what is the use of preparing these documents or why a tester need to prepare these:

assume that we were testing the application and as we are not following any proper
documentation there may be a chance to skip few of the functionality in the application and
even there a chance for the customer to work on that skipped part and to find defects so
before testing any application 1st we will prepare what to test in the application and how to
test in that application we place these two things in two different documents which we call
it as test scenario and test case documents

Test scenario: what to test in an application

test case: how to test that scenario in an application

Test closer: we will prepare test closer reports

Test Plan : it is an detailed plan and approach prepared by test lead for testing a software
application

A test plan document acts like a guideline document or its acts like a road map for tester in
testing software application

As we observed that test plan document is a simple word document based on the
organisation that template will change which is customization of the template is there so
any one can change the template based on their needs but whatever the organisation might
be the below sections will be there for majority of the companies

basic template which is used by most of the organisation:

1) Objective: in this we will briefly describe about the project which is some kind of
introduction to the project
2) Scope: here we will specify from the entire application what we will test and what
we will not test
a) Inscope: features to be tested and also types of testing applicable for those
features
b) Outscope: features not to be tested and also types of testing not applicable for
those features
3) Approach:
a) Requirement analysis approach: here we will concern about the study of
requirements
b) Test design: how we are designing/writing test cases
c) Test execution : how to execute the test cases
d) Defect management: if we observed any defects in the application how we are
going to submit that defect
4) Resources: here we will specify how many resources were working and who else is
working
a) H/w resources: min hardware required
b) s/w resources: min s/w required
c) human resources: min resources and their names and some information about
them
5) entry and exit criteria for testing: it means when can we start the testing and when
can we stop the testing
a) entry criteria: if the developers successfully performed unit testing and
integration testing and if they confirmed that 100% code coverage was done
then we will start testing
b) exit criteria: once 100% requirement coverage was done and whatever defects
we raised we fixed and closed
6) risks and mitigations: possible problems which may have (-)ve impact on the work to
be continued which we call it as a risk best example :
assume that 3 resources were working on one project if 3 resources will work
continuously for 5days then only testing will be finished unfortunately one resource
have some health problem and he was on leave for next 2 days(he worked for 3days)
mitigation: predefined solutions for the risks
so the mitigation plan for the above example is a backup resource
7) schedule: it contains a detailed work schedule it means we planned for 3 days of
testing and in day 1 we will spent 8hrs(murthy,prakash) and in day 2 we will spent 9
hrs and in day 3 we wil spent 10hrs(altaf,vasem,priya)
8) test deliverables: once after the testing was completed successfully we need to
deliver few documents to the customer they were:
a) test scenarios
b) test cases
c) test data
d) RTM
e) Logged defects
f) Test summary report

Test analysis: in this phase tester will study various requirement documents like
BRS,SRS to understand what to test and how to test various requirements in project

SRS or FRS: software requirement specification or Functional requirement

specification

SRS: it contains detailed information about each and every module in the project.
Generally with this SRS we can simply write our test cases why because in SRS it
contains detailed information about the project in a simplified way

What are all the various sub sections involved in SRS???

Req id: for which requirement we(developers/BA) are preparing this SRS 001

Req description: what is that requirement description login to app

1) Overview: an brief introduction to login scenario they will make a note here
2) Prototype: this is an optional field and if we chose the SDLC model as an
prototype then we will use this section.. screenshot of the requirement will be
placed here
3) Form/page elements: what are the various elements present in the webpage
4) Input validations and error states: if at all any field is there what are the various
inputs we can pass to that field like a-z, A-z,0-9 etc
 If at all if we give any invalid data what error message it will display will also
listed here
5) Use cases or data flow diagram: simply a pictorial's representation of a module
flow…

Assume that the shared SRS was not clear for us and even we cant understand that
functionality???

We can prepare a document and the name of that document is “Requirement

Clarification Notes” : if at all testers were unable to understand any requirement
then they will prepare this document and they will share this to either BA or
developers

Test design: we usually design test scenarios and test cases

What is test scenario???

What to test in an application or an a functionality to be tested in the

application under test

Example: mobile application try to lost down the scenarios, laptop, water bottle

1) On/off functionality is working or not???

2) Battery is there or not???
3) Calling feature is working or not???
 4) Receiving calls is working or not??
5) SMS sending??
6) Receiving SMS’s???
7) Checking all the supported application/apps in the mobile

Test scenario template: I already shared that to you guys

What is a Test case???

How to test and what to test or set of pre conditions, test procedures,(steps
to be followed),input data, expected results to validate a functionality in the
application

Example: take a login to gmail application as an scenario

Test case id:TC_001

Test case description: verify whether we were able to login to application using
valid uid, pswd or not

Test case steps: 1) open the application

Enter valid uid, valid pswd and click on login button

Excepted result: inbox page should display

input data: user name , password

Types of test cases:

1) UI or GUI test cases: user interface or graphical user interface

2) Functional test cases
a) Positive test cases
b) Negative test cases
3) Load test cases
4) Security test cases

Functional test case: if we write a test case to validate the functionality in the application
which we call it as functional test cases

Positive test case: if a test case is designed to check what system is supposed to do then
it is positive test case

Example: valid uid, valid pswd for login test case

Negative test case: if we write a test case to check what the system was not supposed
to do which we call it as negative test case

Example: login test case : invalid inputs means entering ivalid uid or invalid pswd or
leaving uid, pswd as a blank

Scenario for your practise: try to prepare test scenario document for mobile
application , laptop, water bottle etc and update the traceability matrix

Tracability matrix: or requirement traceability matrix:

Ability of identifying a group of test cases or else a batch of test case related to specific
requirement or mapping between test cases and requirements which we call I as
traceability matrix

What is the use of this traceability matrix:

To identify a batch of test cases that belongs to a specific requirement

Defect life cycle: stages involved in defect life cycle:

Defect: the deviation between expected result and actual result which we call it
as a defect

So when we were performing the testing on the application if at all we identified

any defects then we report those defects to the developer using bug reporting
tool

With the help of this bug reporting we usually submit the bugs here and we will
assign those bugs to the developer, to write a detailed description about that bug
means how we identified that issues using which test data we identified that issue
and the screenshot of that bug we usually link up with the bug

Defect life cycle: soon after we identified the bug what are all the various stages
involved or carried out with that bug which we call it as defect life cycle

1) New: this new state indicates that the bug is logged(submitted) just now (a
detailed explanation about the defect, with test data , screenshot)
And once the bug is in new state means who ever submitted that bug that
bug is with their name

Then we will assign that bug to the corresponding developer..

Once we assign this bug to the developer now the bug is with developer side 1 st
he will analyse that bug

Based on his analysis he may assign any one of the below stages to that bug:

1) Rejected: so whatever the defect we have submitted is an invalid defect then

developer will change the bug state to invalid bug
2) Open: if he identified that the issue is reproducing and if he was supposed to
work on that issue then it means he accepted that issue is reproducing and he
is going to work on that issue
3) Hold: if at all the bug which was submitted by a tester was not clear to that
developer then he kept that bug in hold state
4) Duplicate: if at all we already submitted the same bug, then he change the
state to duplicate
5) Differed: if the defect is postponed then he will change that state to differed
state
Once the developer was worked on that issue and if he fixed that issue then
he will assign that bug back to the testers then from our end we need to cross
check whether that bug is closed or not, if it is working as expected then we
will close that bug else we will reopen that bug again
Different defect status handled by tester:

1) New
2) Close
3) Reopen

Different defect status handled by developer:

1) Open
2) Rejected
3) Hold
4) Differed
5) duplicate

The various bug reporting tools we have were:

1) Bugzilla
2) Teamtracker
3) Jira
4) QC

How can we submit a bug in the bug reporting tool what are the things we need to
submit a bug???
Please find below steps for the same:

1) We need to login to bug reporting tool with your credentials

2) We need to select for which project we were submitting this bug
3) If we select a project then it will display a form where we need to fill a detailed
information about that bug
4) While submitting the bug we need to give a proper title for that bug so that by
simply looking into the title developer need to understand for what we have
submitted the bug
5) We need to select who is submitting that bug means a tester/ manger/so one else
6) We need to specify whether that issue is identified in production environment or
else in test environment
7) We need to write the steps inorder to duplicate that issue and even we need to
give test data here along with expected result and what is the actual result
8) We need to specify who is submitting the issue and for whom we are submitting
that issue also we need to maintain there
9) Once we filled the form with all these fields and if I click on OK button then it will
generate a unique id for the issue we have submitted and even we will get a mail
to our mailed using that unique we usually search the bug for the stats

Reproducible: if at a defect is occurring every time in the application under test then
it is a reproducible bug

Non reproducible: sometimes we will see that issue and sometimes we won’t find
that issues

Show stopper defect: a problem which is not allowing us to continue remaining test
execution

Example: once after I opened the application instead of displaying the application
home page if it displays 404 page not found errors then we cant proceed with our
testing

Defect severity: how serious the defect in the system or the impact of the defect in
the application which we call it as defect severity

Defect priority : the order in which defects has to be fixed which we call it as defect
priority

Very high, high, medium, low

A tester is the right person to assign defect severity and where as developer is the
right for assign priority

Defect Age: the total duration between bug opening date and bug closing date

Scenarios for your practise:

1) Write test scenarios and test cases for mobile, laptop, waterbottle, watch, car
Various testing definitions:

Adhoc testing: testing a software application without following and pre plan
procedure which we call it as adhoc testing or test as you wish
It is also called as informal testing
Smoke testing: build stability : or sanity test: soon after we got the build testing
inorde to check the build stability we are going for this type of testing which we
cal it as smoke test
Exploratory testing: exploring the application by adding or modifying the existing
test cases for better testing which we call it as exploratory testing
Error guessing testing: with the prior knowledge and experience of a tester you
can guess the areas in your application where there is a chance o/f finding tricky
defects on the application
Monkey testing: or zigzag testing: testing a software application in a zigzag
manner or in an uneven way with an intension to find defects in the application
which we call it’s as money testing or zigzag testing or gorilla testing

Mutation testing: it is a process of wontedly injecting defects by developers to

confirm are the testers testing application properly or not

End to end testing : testing the overall functionalities of the system i.e validating
all core business scenarios right from beginning to till end
UI testing/GUI testing : validating whether in the application all the user
interfaces were designed professionally or not which we call it as UI
Here in this type of testing we usually check the spelling mistakes, proper
alignment of fields
MuRThy == murthy == MURTHY
it is the process of verifying the various effiency characteristics of an application
like response time, throughput,stress
Security testing: we will validate whether all the security conditions are properly
implemented in application or not
Regression testing
Retesting
Assume that while we are testing the application we indentified one issue and we
submitted one bug that for that issue… and developer fixed that issues after few
days if at all we ares testing the effected modules or effected scenarios which we
call it as retesting
Assume that your application conatains frequent releases like below
March: 1st release : 100Tc
Apr: 2nd release: new module (10Tcs) + 100Tcs
May : 3rd release: new module(10Tcs)+ 110Tcs