1. SOFTWARETESTING /
functional testing
R & D
Bharath Anche
(PassionateTester )
abharathc9999@gmail.com

2. What is software testing ?
• Testing is process of executing the software intentionally
to find the bugs in it.
( or )
• To differentiate the customer requirements and actual
function of the software or application .

3. What is quality in software testing?
• Quality is a process where the it meets the customer or
user requirements
They are two types to ensure the quality of software :-
A) Quality Assurance
B) Quality Control

4. What is Quality assurance
• Quality Assurance is a process of finding the bugs in the
initial stage of software development .
• This Quality Assurance includes process ,procedure ,
requirements and verification of standards in developed
software
• It is subset of software life cycle.
• It focuses on processes and procedures .

5. Examples Of quality Assurance ?
• Verification of software
• ISO
• IEEE

6. What is quality control?
• Quality Control is a process which validate the software
after developed and before giving it to the customer.
• Quality Control focuses on finding a bug after the
software is developed and before giving it to the
customer
• It is a subset of quality Assurance

7. What is verification ?
• Verification is a step by step process which includes the
• Documentation
• Review the document and perform test report
• Design
• Review the design and perform test report
• Built review
• Review the code and perform test report

8. Advantages of verification ?
• It is performed at the initial stage of the project .
• This process is effective in reducing the errors or finding
the errors at the starting stage of the software
development
• This lower the damage of the software development .

9. What is validation ?
• Validation is done after the software is developed and to
find the defects before it goes to customer hands .
• It focuses on the Defects that enter in to the system
• Validation can be performed after UAT availability.

10. Advantages of validation ?
• We can find the defects before delivering the product .
• Include better products and services which gives good
reputation for a company and higher revenue from
having more satisfied customers.

11. Disadvantages of validation ?
• Include more man power or operations to maintain
quality control .
• adding more time to the initial process.

12. Principles ofTesting (Session 4)
• The tester have to follow the certain principles in this
corporate world :-
• Principle 1:Testing shows presence of defect
Yes ,Testing will reduces the effect of bugs or error in the
software ,But no software in world is 100% bug free.
• Principle 2 : Exhausting testing is impossible
While testing the software we will see the important areas or
delicate areas but we cannot do the test on all combinations .

13. • Principle 3 :- Early testing
This is so important that we have to start the test at
beginning of the software development stage .This will
reduces the bugs or defects in the software .
• Principle 4: defect clustering
Tester should not be lazy while testing he have to test
each and every Conner of the software to find bugs .

14. • Principle 5 : pesticide paradox
IT is kind of disease repeating the activity number of time , In
testing we have to be patience while repeating the test on
same software and we have to see that we are using different
types of testing methods to find the new bugs in the software.
• Principle 6 :Testing is context dependent
We have to perform different types of tests based on software
requirement it may be e- commerce software or safety critical
software or banking software .

15. • Principle 7 :- absence of errors fallacy
Tester should come out from a mind set on testing and finding
the bugs in the software is done , but this not encouraged in
the corporate world , tester should test the software keeping in
the mind requirements of client and user end .
• Principle 8 : Pro activeness
Tester should be very active and should always try to know
coming features which may include in between the software
development and also adopt the new testing techniques .

16. Session 5 :-What is application
• Application is a program or a group of program designed
for the end user
• Lets discuss about 3 type’s of applications :-
a) web applicatiomn
b) desktop application
c) mobile application

17. Web application
• Web application is a program that is stored on the server
and on the request of user it is delivered through browser
.
Technologies used for delivering web application:-
a) Java
b) .net
c) PHP
d) Google toolkit

18. Desktop Application
• The application which runs as stand alone in laptop or
desktop which contrast with web applicationThat needs
web browser to run.
Technologies used for runningThis application:
a) c
b) C++
d)Visual studios

19. Mobile Application
• Mobile application is programThat designed to run on
smart phones , tablet pc , wireless computing devices .
Technology that supports this application is :
a) HTML 5
b) objective –c
c) Apache cordova

20. What is a architecture
• An architecture is a primary qualities of a system quality
which includes modifiability, security and performance .
• It show which components are involved in the design and
what is the role of each component
• It also tells how these components will communicate with
each other.

21. Types of architecture
• 2-tier architecture
3-tier architecture
n-tier architecture
MVC architecture

22. Day 6 special class on SDLC
• SDLC standards for software development life cycle .
• To implement a successful software or project we have
follow certain phases in software development life cycle
• There are different phases in SDLC

23. phases of SDLC
• Planning
• Analysis
• Design
• Built
• Test
• Deployment

24. Planing phase of sdlc
• The motive of this phase is to understand the
requirements of the project .
• Business architect and project manager will have a
discussion in this phase and list out the requirements in a
chart called “ Requirement charter”
• Out come of this phase is “Project Charter”

25. analyis phase
• In this phase the analysis on the requirements is done by
the business analyst .
• Business analyst will document the requirements
according to the end user
• Out come of this phase is “ BRD” (business requirement
document )

26. Design phase
• In this design phase the business architect will design the
software with different types of tools .
• Out come of this phase is
a) high level Design

27. Built phase
• In this phase the different types of developers ex: web
developers , app developers are involved to built .
• Out come of this phase is : low level document

28. Test phase
• In this phase the test engineer will execute the software
or product using tools to find the bugs in it .
• Out come : Defect report

29. Deployment phase
• In this phase there is a team called “ environment
management “ this team will deploy or install the
software in live environment .
• Out come : deployment software

30. Types of approaches to be followed in
product development
• Sequential approach
• Incremental approach
• Iterative approach
• Prototype approach

31. Sequential approch
• If a project runs in a SDLC phases in correct order it is
called sequential approch.
• Example of sequential model is water fall model and v-
model
• This approach is suitable for stable technology and
application architecture
• Well understood stable requirements

32. Incremental approach
• In incremental approach the software system is broken down in to
sub systems .
• Incremental approach is suitable for
• Project requirements are know but there is no stable requirement

33. Prototype approch
• This approach is built and thrown which is suitable for the
small projects were requirements are not mentioned .

34. Iterative approch
• This kind of approach we use in long term projects ,
where changes takes place in requirements rapidly.
• Here we don't require 100% requirements
• Agile methodology is the best example for this approach .

35. Waterfall model
• Waterfall model is a sequential design process used in
software development process.
• In this model the requirements should be stable
• It requires good planning

36. Flow chart of water fall model
• review Review
• 100% 100%
• Review
• 100%
• Review
• 100%
planing
analysis
design
built
Test

37. Working in waterfall model
• The requirements should be stable while working on
waterfall model
• If the first phase(planning) is 100% correct than we have
to move on to second phase(Analysis phase)
• To implement the project in waterfall model we require
good planning .

38. Advantages of water fall model
• Stable process
• All the phases are done 100%
• This model is simple and easy to understand and use.
• This model works well with small projects were the
requirements are very well understood .

39. Disadvantages of waterfall model
• No early conversation with all the team involved in
development of product.
• No early testing
• It will not allow any business changes .
• No early software
• No early customer feedback

40. How to handle requirement
changes in water fall model
• Step1 :- client will request requirement changes notice
(RCN)
• Step 2:- We will create requirement change notice
• Step 3:- our project manager will distribute the
requirements to all the team members in project
• Step 4 : analysis report will be generated regarding the
impact on project .

41. • Step 5 : we will send requirement changes to client
• Step 6 :On the approval of client we will handle
requirement change .

42. What if requirements changes
rapidly in waterfall model
• We will request the client to change the approach from
sequel to iterative approach .
• We can also handle the production defects in the 1month
of free service .

43. Iterative development model
• Dividing the project in to number of releases
• If the requirements are rapidly changing we can request
the customer to move on this model .
• We can get the early feedback from the customer for
each release

44. Advantages of iterative approch
• Early software
• Early feedback
• We can reduce the risk to maximum level
• Less costly to change the scope and requirements
• Agile is the present methodology based on this iterative
approach

45. Agile method
• Agile software development is a software development model based
on iterative approach where the requirements and solutions revolve
around the self- organized cross functional team .
• In this Agile the team having the 5-9 members developers , testers ,
designers , analyst,Were these people will be doing cross functional
activities .
• No naming is encouraged like senior , junior ,leader
• Everything is transparent
• No documentation , more interactions will happen to save the time
and to improve quality of work .

46. Principles of agile
• Agile is also called as quick moving
• Agile will break the task in small increments
• In agile we will breakdown the software in to number of releases .
• While working in agile we have to deliver the software within 2-4
weeks of time .
• Each team should involve in complete SDLC .
• Main goal of agile is to delivering the working software .
• In agile more Interactions should happen rather than
documentation .

47. Advantages of agile
• Customer satisfaction
• Late changes in the requirements are welcomed
• Going with more interactions between business people
and developers .
• Agile is against to prepare document .

48. Difference between agile and water
fall model
• Agile is individual and -> water fall process and
Interactive model. Tools.
• Delivering the working -> documentation is required
software . -> we cannot contact with
• Customer collaboration other team members .
• Responding to late cha -> No changes are encourage
nges in the requirement -> It is sequential approach.
• Less documentation
and more Interactions with
business people and
developers .
• It is a iterative approach .

49. Testing classifications
• Testing is classified in to twoStatic testing Dynamic testing

50. Static testing
• Static testing is done before the compilation of the
software .
• Static testing is done at the initial stage of software
testing life cycle.
• Requirement review
• Design review
• Code review

51. Dynamic testing
• Dynamic testing is done after the compilation of software .
• In dynamic testing software is executed intentionally to find
the defects .
• Examples of dynamic testing
• White box
• Black box
• Grey box

52. • Unit testing :- testing testing the each unit and each
modules of the code, It involves testing of source code by
developers.
• Integration testing :- Each module is grouped and tested
by the developer . He ensures whether each module is
working according to the requirement .
.

53. White box testing
• White box testing is based on requirements and also considering the
internal knowledge of the code.
• In this white box testing missing requirements cannot be handled .
• Statement coverage :execution of each statement
• Conditional coverage: if / else execution testing
• Branch coverage : all parts of the program
• Loop testing : for loop/do/while testing in code
• Memory leakage : checking for unnecessary variables
• Tool used in white box : J unit tool

54. Example of white box testing
• Print first ten natural numbers
• Code for the above program
#include<stdio.h>
int main()
• {
• int i = 1;
• for (i = 1; i <= 10; i--)
• {
• printf("%d", i);
}
• return (0);
• }

55. Test case for the above code
• Enter the natural number 1 and execute
out put : 0
• Enter the natural number 2 and execute
out put : 1
• Enter the natural number 9 and execute
• Out put : 8
• Enter the natural number 10 and execute
out put : 9

56. Bug we found in above code
• From the above test case we can conclude that there is some defect in the code .
• #include<stdio.h>
int main()
• {
• int i = 1;
• for (i = 1; i <= 10; i--) we given that i-- instead of
• { i++ .
• printf("%d", i);
}
• return (0);
• }
i--)

57. Black box testing
• Black box testing is done by considering requirements but not
using internal code knowledge.
• Black box testing is a strategy where testing is based on
requirements and functionalities .
• Challenges in black box testing
• Exhaustive testing
• Accidental coincidence
• Sometimes we may get right output for wrong reason.

58. • Exhaustive testing : testing the requirements with all
combinations is impossible ,
• Accidental coincidence :- sometime we may get correct
out for wrong input .
• Acceptance testing
• System testing : testing the whole system to see whether
requirements are meeting with the customer .

59. Black box testing whitebox
testing
1) Black box testing requires requirements 1) White box testing requires requiremen
and not internal structure of the code . Ts and internal structural code.
2)mainly appalicable to higher levels 2) Mainly applicable to low level testing
of testing like acceptance testing unit testing and integration testing.
system testing 3) generally software developers are
3)Generally independent software responsible in this white box testing
testers are responsible in this Black –
box testing .
4) programming knowledge and 4) programming knowledge and
implementation knowledge implementation knowledge required.
not required .
5)we will write test cases based 5) we have to write detailed test cases
on requirements. Design .

60. Grey box testing
• Grey Box testing is combination of both white box and
black box testing .
• While testing u need to have a partial understanding of
internal structure and also the requirements .
• For designing the test cases you need to now the code /
internal structure and conduct testing like black box.

61. What is functional testing
• Functional testing is testing the system based on
the client requirements whether it is working or
how well it is performing .
• For example if we take web application
field level validation : checking whether all fields
like(user name ,password )are working
business level validation: checking the rules of
each field is working or not .
• End to end flow : checking whether whole
application is working as per the requirement .

62. What is non – functional testing ?
• Checking whether how well the system is responding.
• Some of the sub types in no functional testing are :-
• Usability
• Compatibility
• Security
• performance

63. • A) Usability: checking whether the application is easy to use .
• Easy navigations
• Unnecessary content
• Time taken to accomplish the task .
• B) compatibility or installation : checking whether the application is
supporting the various browser versions and os versions or not .
• C) performance : checking the speed of the application by applying
certain tests like stress ,load indurance , spike

64. Example for non functional testing
• lets test the ball pen
• Whether the pen is writing well not
• Whether the pen is writing on wet surface, rough
surface,.
• Bend the refill in all the directions and now we start
writing this is called stress testing .
• Apply force and try to write this is called load testing .

65. Function and non functional
• Here the testers test how well the system
is performing.
• Functional testing is based on client
requirements .
• Testing the application against business
requirements .
• It is a part of system testing
• Functional testing means validating the
behavior of a application.
• this testing covers integrating testing,
sanity testing, smoke testing, regression
testing,
• Here tester tests how well the system is
responding.
• Non- functional testing is based on
clients expectations .
• Testing the application against
performance requirements.
• It is also a part of system testing
• Non – functional testing means validating
the performance of the application.
• This testing covers
performance,load,stress,security,instillati
on,compatibilityand usability.

66. Performance testing
• Performance testing is use to check the speed of the
application .and this application goes to various stages of
testing under this performance testing .
A) usability testing
b) load testing
c) stress testing
d) spike testing
e) Endurance testing

67. Spike testing
• Spike testing is testing the application or system by
applying max load on and they also checks by unloading
it.
• For example : if we take the jntu results are declared and
on the same day all the users have logged in and the
server is crashed due to over load and they also test this
jntu site behavior by unloading it.

68. Load test
• By applying load and they calculate the load it can take
and at what load it is going to crash .
• For example a bank domain server will accept 1000
requests and not more than that , if the applications are
still coming at some point the bank application crashes .

69. Endurance test
• Endurance means capacity / fitness , testing the system
how much a system can handle the load for continuous
period of time .
• Best example is bank application , on closing days of
banks we continuous load on that days so we test the
load by keeping in the mind endurance testing , we test
on these days how the system or application sustain the
continuous load on the application or system.

70. Security (non functional testing)
• Checking the credentials and secure login process of an
system / application .
For example :
• In a bank application or in atm machine the authorized
person with his atm card should insert the card and get
the amount and after the transcation is completed it
exists the window and go to home page , but if it fails in
going to home page there is a security issue in the
application.

71. Principles in security
• Confidentiality :The information sent by person a to
Person B the information should be viewed by only B.
• Integrity : Getting an information from the correct
person.
• Authentication : conforming the identity of a person and
giving access to him .
• Authorization : Giving access to required features for
authenticated person .

72. • Availability : availability of information to authenticated
authorized person .

73. Security testing techniques
• Access to application
• Password cracking
• Data protection
• Sql injection
• Cross file crypting
• Phishing

74. Retesting and regression
• Retesting is a process of testing the tested software or
product once again to find if there is a bug .
• Regression testing is a process of testing the retested
software to see whether the fixed changes which are
done in retesting will not have any impact on other
functionalities .

75. When we can go for retesting ?
• Retesting is performed when we find a bug or we think
that there will be a bug at that point of place we need to
go for re-testing , we have to test the application again
and again .

76. When we can go for regression
• When we found a bug in retesting and when it is been
solved .
• The application once again goes for complete testing
called regression testing to find the defect if any and also
to check whether the fixed bug doesn’t shows inpact on
other functionalities .

77. Is it possible to do entire
regression?
• Regression testing should ideally happen on every single
code commit (and if you've got a good build pipeline, this
means doing testing on every single build).This ensures
that if a bug has been introduced in the latest commit,
that it found as quickly as possible. If you only have to go
back one commit to fix a problem, that's super easy to fix
and troubleshoot.

78. Convetional testing
• Testing with process, need have preplanned approach ,
scripted approach.
• Business analyst will give the requirements
• Business architect will design based on requirements .
• Tester will develop test design based on requirements.
• Developer will create the build
• Tester will execute the application .

79. Characteristics of conventional
testing
• Preplanned approach
• Organized approach
• Pre defined set of test cases
• Process oriented

80. AdhocTesting
• Testing without any process , procedures,organised approach, is called Adhoc
testing.
Characteristics of Adhoc testing :-
• Pre-planning is not required in this Adhoc.
• No need to follow the process.
• Pre-planned set of test cases are not required .
• Simuntanesouly thinking design and execution.
• This type of testing is completely based on testers creativity and memory of past
events.
• Testers with good experience and knowledge

81. Disadvantages of adhoc testing
• There will be no control over test coverage .
• This test may not cover 100%
• Requirement coverage may not be covered .

82. Principles to perform adhoc
• Exploratory testing will be under supervisor control.
• Supervisor will allocate charter to testers.
• Charter means a functionality will be tested .
• Supervisor will identify sessions to test charter
• Session is a time period to test a functionality
• At the ending of the adhoc testing they go for debrief
meeting to discuss the obervations .

83. When testing team will go for
adhoc or explonatory testing ?
• When there is no requirements of the product or
software.
• When there is a lack of time .

84. What is adhoc regression testing ?
• Testing the previously working or retested functionality
without writing test cases is called adhoc regression
testing .

85. What is alpha testing ?
• Testing conducted by the end-user at developer location
to check the acceptance criteria .
• This test is performed based on requirements but not
based on functional and non functional requirements .
• Business requirement : what customer is expecting .
• Functional requirement : how to implement feature .

86. What is beta testing?
• Testing the product by end – user at end – user location is
called beta testing .
• End user , business architect (BA) , client will perform .
• This testing is performed based on business requirements
only .
• This test is always performed by customers at their own
site .

87. Alpha and beta
• It is always performed by the developers at the software
development site.
• Sometimes it is also performed by Independent Testing
Team.
• Alpha Testing is not open to the market and public
• It is conducted for the software application and project.
• It is always performed in Virtual Environment.
• It is always performed within the organization.
• It is the form of Acceptance Testing.
• Alpha Testing is definitely performed and carried out at the
developing organizations location with the involvement of
developers.
• It comes under the category of both White Box Testing and
Black Box Testing.
• It is considered as the User Acceptance Testing (UAT) which is
done at developer’s area.
• It is always performed by the customers at their own site.
• It is not performed by Independent Testing Team.
• Beta Testing is always open to the market and public.
• It is usually conducted for software product.
• It is performed in Real Time Environment.
• It is always performed outside the organization.
• It is also the form of Acceptance Testing.
• Beta Testing (field testing) is performed and carried out by
users or you can say people at their own locations and site
using customer data.
• It is only a kind of Black Box Testing.
• .
• It is also considered as the User Acceptance Testing (UAT)
which is done at customers or users area.

88. Smoke test
• Smoke test is a kind of test that revels the major failures
of the application .
• Smoke test is a type of testing that revels or shows
whether the application is ready for testing or not .

89. Steps performing smoke test
• Business analyst will give the requirement
• Developers will build the design.
• Team of testers perform smoke test on this build to
ensure to send this build to next level of testing or not .
• Group of testers will test the application which is passed
in smoke test .
• Environment team will deploy the software.

90. Smoke test characteristics
• This smoke test should be a quick test should be
completed in 3-4 hours but not entire day .
• End to end test
• Testing the main functionalities of the software
• Scripted approach

91. Example of smoke test
• Smoke test of a pen :
a – pen is writing or not
b- color of the ink
c - gripper is present or not
d- fixing the cap of the pen.

92. Example 2 for smoke test
• Mobile
a- check incoming and out going calls
b- check display
c- check incoming and out going sms
d- check charge of the battery
e- check signal symbol is showing or not

93. Sanity testing
• Sanity testing is testing the application completely after
the application is qualified in smoke test .
• Sanity testing is detailed test when compare to smoke
test .
• Sanity testing is performed after the smoke test.
• Testing the application at customer environment to check
whether the already tested application is responding in
customer environment .

94. Steps when sanity testing is
performed
• Business analyst will give the requirements
• Developer will build the design.
• Testers will perform smoke test
• If the application is qualified in smoke test it is passed to next level of testing
• The team of testers will perform detailed test and generate test cases .
• The defects are sent to the developer
• Developer will solve the defects and pass again to testers .
• Testers will retest the changes done on application
• Now testers will start regression
• Testers found defect they will pass it to developer
• Developer corrects the defects
• At regression we stated application is working fine
• Then at the last 2 to 3 hrs will go for sanity testing .

95. Sanity smoke
• It is more in-depth
• In Sanity testing we need not
follow previous test cases .
• It is not end to end test
• It is not in depth just testing the
major functionalities of the
software .
• In smoke testing we need to
follow scripted approach
• It is end to end test .

96. Installation testing
• Testing the installations procedures and configurations
for the software to deploy .
• This installation testing is performed by deployment
team.

97. Localization testing
• Testing the applications with different type of languages .
• But the tester must now the language before he performs
test .

98. Mutation testing
• Mutation testing means intentionally the developer will
inject the defects in to the application to test the testers
performance on testing the application .

99. Levels of testing
• Testing is performed at different levels
1) unit testing
2) Integration testing
3) system testing
4) system integration level testing
5) user acceptance testing
6) Incremental integration testing

100. Unit testing
• Unit testing is a level of testing where developers will
execute the build intentionally to find the defects .
• In this unit level testing each module or each component
is tested in the system or software .
• This is a white box testing
• This is done by developers
• It is functional and non functional

101. Example of unit testing
• Let us take the mother board of system and we start unit
test on each component whether it is working or not .
• Testing the each key of a key board

102. Integration testing / assembly level
testing
• Integration or assembly level testing is a process where
we test the interconnectivity between the different
components in a system .
• This testing is performed by developers .
• This testing done only after the system is successfully
completed unit test .

103. Example of integration testing
• Testing the system when keyboard and mouse are
connected together
• Testing all the components grouped in mother board of a
system.

104. System testing
• System testing is a process of validating the entire
system .
• This system testing performed by test engineers.
• This test is done only when the system is passed in
integration level testing .
• Tester will perform this test to check the functionality and
non- functionality through black box methodology .

105. System integration level testing
• SIT (system integration level testing ) is a process of
testing the whole system in different modules .
• In this SIT level different type of test engineers from
different projects are involved to perform this test .
• To perform this test first the system has to undergo
system level testing .
• This test is performed through black box methodology .

106. UAT (user Acceptance testing )
• User acceptance test is done by BA, END userAND client
these people will perform test in acceptance criteria .
• BA will test according to the requirements .
• This test is done through black box testing methodology .
• Alpha testing and Beta testing comes under this testing .
• After the UAT testing the permission is given to the
environment management team to deploy the product in
live environment .

107. Incremental integration testing
• Testing the each component in the system which is
successfully completed the unit level testing .
• This testing consists of two techniques
a) top down approach
b) bottom up approach
• Top down approach : In this approach highest level modules
are tested first and lowest level modules are tested after that .
• Bottom up approach :This testing begins with unit testing
followed by higher level combinations of units or modules and
testing them .

108. What is stub and drivers in
Integration testing
• Stubs are called top down integration testing
For example :
• If we have Modules X,Y and Z. X module is ready and we
need to test it, but it calls functions from y and z (which
are not yet ready).To test at such a module, we write a
small dummy piece a code which SimulatesY and Z and
which will return values for X.This piece of dummy code
is called Stub in aTop down IntegrationTesting.

109. Drivers
• Drivers are called bottom up integration test .
For example :-
• We have modules forY and Z and X module is not ready
we need to testY and Z module , so develop a piece of
dummy code for x which return the value forY and Z
which piece of dummy code is called drivers .

110. What is scrum ?
• Scrum is a iterative and incremental agile software
development methodology for developing a product .
• Scrum is a part of agile .
• People involved in scrum are :-
a) product owner
b) scrum master
c) scrum team members

111. Responsibilities of product owner?
• Product owner will define the features of the product .
• Product owner will decide the release date of the
product.
• Product owner should be a single person and he is
responsible for product backlog .
• Product owner can accept or reject the work results .
• Product owner will represents the customer requests .

112. Responsibilities of scrum master ?
• Scrum master will take care of entire team members in
scrum .
• Scrum master will train the scrum team on scrum .
• He is responsible for enacting scrum values and practices
.
• Frequent inspection by scrum master .

113. Responsibilities of scrum team
• In this scrum team there will be 5-10 members of cross
functional typical team .
• This is a full time work .
• These scrum team members are self-organised and cross
functional ,They wont have any titles or tags .

114. Working in scrum
• Sprint : sprint is a fixed time frame for delivering the working product to
the customer in weeks but not months .
• Epic / requirements : In a scrum frame work the business requirement
development in a project is divided in to epics .
• Story card : epic is divided in to story card.
• Product backlog : overall story cards assigned to a project .
• Sprint backlog : story cards which are assigned to particular sprint to
deliver a working software to the customer .
• Based on the client pirority we will deliver sprint backlog .
• Sprint planning meeting : how many sprints can be delivered at a time .

115. Scrum framework
• Scrum event / ceremonies
• Scrum roles
• Scrum artifacts
• Scrum event :
a) goal of the sprint
b) sprint estimation
c) how many story cards have to be delvered to the
customer.

116. Scrum roles
• The group of people involved in scrum project
a) product owner
b) scrum team
c) scrum master

117. Scrum artifacts
• Product backlog : overall story cards assigned to a project
.
• Sprint backlog : story cards which are assigned to a
particular sprint to deliver a working software .
• Burndown chart : estimating the x-axis and y-axis or
tracking the total work remaining and present the likely
wood of remained goal .

118. Different types of meetings in
scrum
• Daily scrum meeting
• sprint review meeting
• Sprint retrospective
• Print planning meeting

119. Diagrammatic representation of
scrum

120. What is kanban ?
• kanBan is a new technique for processing a software
development in highly efficient way .
• Kanban tells us what to do , when to do ,what is pending ,
what is completed , what is to be delivered to customer .

121. Features in kan ban
• Visualize your work
• Collaboration in real time
• Subtasks
• Built for speed
• Time tracking with pomodoro support
• Document and time attachment
• Analysis (cumulative flow and lead cycle )

122. Visualize your work

123. • This kanban gives you a excellent overview of your current
suitation .
• It shows you on dashboard “task to do “ “task assigned to me
today “ “task in pending “ “task completed “”task ready to
delivere to customer “
• When working in a team of people you can instantly see what
other people are working on right now, what has been done
and what is coming up.
• Kanban can also be used as a “lean project management tool.”

124. Collaboration in real time

125. • When your working in a team when a one of your team
member makes the changes in the kanban board rest all
members in the team can view what changes are made .
• For example if you add or remove any task on t he screen
the sam e appears on rest of the members screen

126. Sub tasks in KanBan

127. • By dividing your task in to sub tasks you can track how
much progress you have made on a specific task .
• When you complete the sub task you can check the boxes
and the changes will automatically done without your
action .

128. Kan ban is Built for speed

129. • The things are done very quickly in this Kanban process .
• Add , remove, or record will quicly done without
frustrating you with loading .

130. Time tracking with
pomodorosupport

131. • You can track the time of your working progress by using
a trimer technique called “pomodoro timer”.
• You can set a timer for 25 min with fully focused worked
before taking a break . And followed by another 25 min
with another break .

132. Document and file attachment in
kan ban

133. • In kanban you can attach files, presentations,documents
and other files to your tasks .
• You can also attach the files present in orthobox,google
drive and if you have any files on computer you can just
drag and drop in drop file field area it will upload .
• This feature is available in premium version.

134. Analyze (cumulative flow ,leadtime
and cycle)

135. • In kanban by using cumulative flow ,lead time and cycle
charts we can find the bottlenecks in our workflow and
we can add or remove the coloums or we can change the
WIP limits (work in progress).
• After we made changes in the project we have to check
the statstics after a few days if you reached the intended
effect .
• This feature is available in premium version .

136. Software test life cycle
• Software test life cycle is process were the product
undergo different type of testing phases.
• It shows us the entire starting and ending of testing a
software.
• The starting is “requirement analysis and ending phase is
deployment phase “ .

137. Phases in STLC
• Requirement analysis
• Test plan preparation
• Test cases preparation
• Rtm
• Test Environment readiness
• Test execution
• Defect tracking and management
• Test execution report and signoff report

138. Requirement analysis
• In this phase tester will go through the requirements and
understands the expectations of the customer
• This phase helps to identify the scope of testing
• If any requirement is not understood the tester can ask
the business analyst .
• The tester will derive the scenarios from this phase
• Outcome of this phase is “testable requirements”

139. Test plan preparation
• Test plan preparation which describes the intended scope
, approach ,and schedule of the test activities .
• Test plan preparation is prepared by the test lead .
• Test lead will manage , organize and schedule the testing
activities.

140. Test plan document consists of
• Objectives
• Scope of testing
• Testing deliverabales
• Roles and resposibilites
• Assumption and risks
• Contigency approch
• Effect estimation
• Schedule
• Testing methodologies
• Defect tracking
• Entry exit criteria
• Test automation
• templates

141. Test plan flow chart
Requirement analysis
Preparation of test scenarios
Test case
review
Fix the test
case reviews
before
approval
Preparation
of test cases
based on
scenarios
approval

142. What is test scenario
• Test case scenario is a high level test condition which is
derived from requirement analysis and it explains us what
need to be tested .
• When Business analyst will pass the requirements .Test
engineer will prepare the test scenarios based on the
requirements .

143. Why we need test scenarios ?
• Test scenarios are important because these scenarios
makes us understand the complex functionalities in the
project .
• Test engineer can easily understand the highly level
conditions in the system .
• Test engineers are responsible for test scenarios .

144. What is test case ?
• The test case is a detailed specific condition which
explains what need to be tested and how it need to be
tested .
• Test cases are derived from test scenarios
• Test scenarios are derived from requirements
• Test engineer will prepare test scenarios .

145. Why we need test cases ?
• Test case is helpful in documenting the test condition in
an organized approach.
• These test case are reusable while we are testing the
defects .
• Test case design helps in saving execution time.
• Test case clearly describe what we are testing how we are
testing.

146. What are the qualities of good test
cases?
• Test case should be ease to understand .
• Maintaining consistency
• Test case should be reusable while finding defects .

147. Why test cases are important?
• Test cases are designed from test scenarios
• Test cases helps in planning what we are testing .
• Test cases are reusable while finding defects.
• Test cases makes testers easy to test .
• Verification or prevention of defects in the project

148. Can we test an application without
preparing test cases ?
• Yes , this type of testing is called AD-HOC testing where
testers will not follow any procedures or process , and
they donot need any test cases .

149. What is testing technique?
• With minimum inputs we provide maximum coverage .
• Q) why we are applying test design?
To provide maximum test coverage with minimum time.

150. Different type of test designing
techniques ?
• Equivalence partitioning
• Boundary valance analysis
• Decision table testing
• Error guessing

151. Equivalance partitioning
• Identify similar behavior elements which produces same
output.
• Test atleast with one value for each class .
Q) why do we need equivalence partitioning ?
• To cover entire application with minimum effort
• Each test case must have single focus.

152. Boundary value analysis
• Boundary value is analysis is derived from equivalence
partitioning
• It focus on the boundary
The steps using boundary value :
• Identify equivalance class
• Test equivalence of each class

153. Example for boundary value
analysis
• In web application password field must contain min 3
characters and max 14 characters .
• Testing using boundary value analysis
- test using a value between 3 – 14
- test using a value less than 3
- test using a value more than 14

154. Decision table and error guessing
• Decision table will help to capture the complex
requirements of the project .
• Error guessing : exploring the error messages associated
with the system .
• Use case integration : - a graphical representation
between a actor and a action .

155. RTM(requirement tracebility
matrix)
• In our project we Rtm which is located in Bitrix tool
• RTM is a connectivity between requirement and associate test
case
• RTM is used to trace the orphan requirement in the project
• Orphan requirement means the requirement which is not
linked with any one single requirement .
• RTM is used to trace the reusable test cases.
• Reusable test case means which is linked with multiple
requirements .

156. Test environment readiness
• Infrastructure management
• Server configuration
• Application Installation
• Access permission
• Test data loading

157. Steps to deploy ment
• Kill the existing file in the system server
• Copy the new file in the developer server
• Restart system server

158. • Who will deploy in your project ?
:- In my project developer will do deployment .
Q)Where you will maintain environment downtime tracker
?
:- In bitrix tool

159. what will happen if application is
not available to testing team ?
• If we face a environment issue in our project we will go for
following procedure in my project :-
• We will create a critical severity defect
• Will send a mail high imp mail to the developer team and
environment management team .
• We will update this information in environment
downtime tracker which we are maintaining in bitrix tool .

160. Test execution plan
• In our project we divide the execution in cycles
cycle 1: we will test the entire test cases
cycle 2: we will perform re-testing of the test cases
cycle 3: we will perform regression testing