MANUAL

TESTING
 INDEX

S. No. Content Page No

Basic Concepts and Principles of
1 2
Software Testing

2 SDLC 3

3 STLC 4

4 Levels of Testing 6

5 Types of Testing 7

6 Testing Techniques 9

7 Agile Methodology 11

8 Defect Life Cycle 14

9 Priority and Severity 15

10 JIRA 15

11 GIT 16

12 Other Important Questions 19

Page 1 of 22
 1. Basic Concepts and Principles of Software Testing
Why we go for Manual Testing?
1. Human eye captures more defects.
2. Everything cannot be automated like Captcha, Image, Animation, Video, etc.
3. Report prepared by the manual testers will be always detailed because manual
testers are strong in Domain knowledge while automation testers are strong in
technical knowledge.

Software Testing:
1. Functional Testing
2. Non Functional Testing

1. Functional Testing:
 Checking the functionalities of the application.
 Front End:
 Manual Testing (Testing the functionalities by manual)
 Automation Testing (Testing the functionalities by using tools/scripts)

 Back End:
 Web services Testing (Validating request and response) - API Testing

 Automation Tools:
 Selenium - Web Based Applications
 Appium - Mobile Applications
 QTP(Quick Test Professional)/UFT(Unified Functional Testing) - Desktop
Related Applications [Ex: MS Office Applications, Web Browsers, etc.,]
 Test Complete - Both Web Based and Desktop Based Applications

2. Non-Functional Testing:
 Checking the non-functional aspects of the application.
Types of Non-Functional Testing:
 Performance Testing:
 Response Time
 Adding virtual number of users accessing the application
simultaneously to check the performance of the application.

 Load/Stress
 Process of adding load and making the application stress is
called Load/Stress Testing.
 Tools Used
 J-Meter - Open Source Tool

Page 2 of 22
  Load Runner - Paid Version
 Usability Testing:
 To check how good the application is user friendly.
 Accessibility Testing:
 To check how good the application is accessible to different users.
[Note: This testing mainly focus on physically challenged peoples]
 Tools Used: JAWS (Job Access With Speech) and NVDA(Non-Visual
Desktop Access)
 Security Testing:
 To test how secure the application is.

Principles of Software Testing:

1. Testing shows the presence of defect not their absence.
2. Exhaustive testing is not possible. (Testing all the combinations of valid or
invalid data is impossible)
3. Early testing saves time and money.
4. Defects cluster together (Concentrating the module even it is small which has
more defects and testing it thoroughly will raise of more
3. defect, It was found that 80% of defects comes from 20% of the modules)
4. Beware of pesticide paradox (Aware of which module the testing is required,
Don't Spend time in testing the module which doesn't have any
5. defects)
6. Testing is context dependent (Whatever the application we are going to test, we
have to act based on the context as what the application
7. related to)
8. Absence of error is a fallacy (Instead of telling bug free, make sure the
environments are matching with the client requirement)

2. SDLC
SDLC Overview:
 Software Development Life Cycle (SDLC) is a process used by the software
industry to design, develop and test high quality software.

Phases of SDLC:
1. Requirement gathering and analysis
2. Design
3. Development
4. Testing---->>STLC
5. Deployment
6. Operation and Maintenance

Page 3 of 22
Software Development Life Cycle:
1. Requirement gathering and analysis:
 A Contract will be signed between client and marketing team.
 Business Analyst(BA) will get the requirement from the client and
prepare a document called Business Requirement Document(BRD) or
Software Requirements Specification (SRS) Document

2. Design:
 Then a document will be prepared called Design Specification Document,
which will give details about how the front and back end could interact.

3. Development: (Dev Environment)

 Then Developers will develop the software by the use of any coding
language and they will do a test called Unit Testing.

4. Testing: (QA or Testing Environment)

 Once developer coded for the functionality of the software then they will
move their code or build into testing environment called Testing and once
developer moved the code into testing stage, tester will test the
applications as per the flow STLC.

5. Deployment:(Live Environment)
 Once a program has passed the testing phase, it is ready for deployment.
 Deploy the application in the live environment.
 Typically it happens at Non-Peak Hours.

6. Operation and Maintenance:

 Maintenance of software can include software upgrades, repairs, and fixes
of the software if it breaks.

3. STLC
STLC Overview:
 Software Testing Life Cycle (STLC) is defined as a sequence of activities
conducted to perform Software Testing.

Phases of STLC:
1. Requirement Analysis
2. Test Planning
3. Test Design
4. Test execution
5. Sign Off

 Each of these phases have a definite Entry and Exit criteria

Page 4 of 22
  Entry Criteria:
 Entry Criteria gives the prerequisite items that must be completed before
testing can begin.

 Exit Criteria:
 Exit Criteria defines the items that must be completed before testing can
be concluded.

Software Testing Life Cycle:

1. Requirement Analysis:
 Entry Criteria: BR Document and Design Specification Document
 Understanding the requirements
 Clarification of doubts in query logs through walkthrough session
 Identify types of tests to be performed
 Get application access
 Exit Criteria: Finalized scope.

2. Test Planning:
 Entry Criteria: Finalized scope
 Done by testing team lead
 Preparation of test plan document for various types of testing
 Inscope and Outscope
 Test tool selection
 Date Calculation
 Resource planning
 Exit Criteria: Test Plan Document.

3. Test Design:
 Entry Criteria: Test Plan Document
 Create test case document with test scenario, test case and test data
 Review test cases with peer or lead
 Get Approval from BA
 Automation testers will do skeleton script
 RTM (Requirement Traceability Matrix) will be done by Testing Team Lead
 Exit Criteria: Test Case Document, RTM.

4. Test Execution:
 Entry Criteria: Test Case Document, RTM
 Execute tests as per plan
 Raise defects and Track the defects to closure
 Document test results, and log defects for failed cases
 Exit Criteria: Execution Result, Defect Log.
5. Sign Off:
 Entry Criteria: Execution Result, Defect Log
 Will be done by Testing Team Manager

Page 5 of 22
  Test result analysis
 Evaluate cycle completion
 Prepare Test closure report
 Exit Criteria: Closure Document.

4. Levels of Testing
Test Scenario:
 It is an idea of what we are going to test.

Test Case:
 It is an idea of how we are going to test.

Test Data:
 The actual input which we are going to use in the application for testing.

Defect:
 When the expected and actual is not matching, then it is a defect.
 In other words, when the application does not conform to the requirement
specification.

Bug:
 When the tester raise a defect to developer then it is called as bug

Levels of Testing:
 The testing done at various levels and by whom it is done is called Levels of
Testing.
 There are 4 levels of testing. If theses 4 levels of testing is completed only, we can
say the application is ready for release.

1. Unit Testing - Developers

2. Integration Testing - Testers with help of developers
3. System Testing - Testers
4. Acceptance Testing – Client

1. Unit Testing:

Page 6 of 22
  Testing an individual module in an application
 Done by Developers
 Test based on White Box Testing Technique.
2. Integration Testing:
 Combining or merging two modules
 Done by Testers with the help of developers
 Test based on Black Box Testing Techniques
 Top-down Approach - Higher level combinations of units
 Bottom-up Approach - Lower level combinations of units
 Big Bang Approach - Combining all combination of units

3. System Testing:
 Complete Application Testing
 Done by Testers
 Test based on Black Box Testing Technique
 Types of System Testing:
 Functional Testing - To test the functionalities of the application
 Usability Testing - To test whether the application is user friendly and it
is easily understandable
 Performance Testing - To test whether the application is not getting
crashed or down when there is load/stress
 Security Testing - To test whether the application is secure or not
 If theses 4 types of testing is completed only, we can say system testing is
completed.

4. Acceptance Testing:
 Satisfying client requirement
 Done by client side
 Getting approval from client
 Testing will be done at Development/Testing Environment

5. Types of Testing
Different Types of Testing:
White Box Testing:
 It is based on applications internal coding knowledge. It is done by developers.
 White Box Testing is also called as Glass Box, Clear Box, and Structural Testing.

Black Box Testing:

Page 7 of 22
  Testers evaluate the functionality of the software without looking at the internal
coding knowledge.
 It is done by testers.

Positive Testing:
 It is to determine what system supposed to do. It helps to check whether the
application is justifying the requirements or not.

Negative Testing:
 It is to determine what system not supposed to do. It helps to find the defects
from the software.

Formal Testing:
 It is a process where the testers test the application by having pre-planned
procedures and proper documentation.

Informal Testing:
 It is a process where the testers test the application without having any pre-
planned procedures and proper documentation.

Monkey Testing:
 Perform abnormal action on the application deliberately in order to verify the
stability of the application.

Retesting:
 Once the developer fix the bug and we need to test again whether the bug is fixed
or not.

Smoke Testing:
 Smoke Testing is done to make sure if the build we received from the
development team is testable or not.
 It is also called as “Day 0” check. It is done at the “build level”.
 It helps not to waste the testing time to simply testing the whole application
when the key features don’t work.

Page 8 of 22
Regression Testing:
 It is done to make sure the existing functionalities of the application is not
impacted whenever any new functionalities is added to the application.

Sanity Testing:
 Sanity Testing is done during the release phase to check for the main
functionalities of the application without going deeper.
 It is also called as a subset of Regression testing. It is done at the “release level”.
 At times due to release time constraints regression testing can’t be done to the
build, sanity testing does that part by checking main functionalities.

Beta Testing:
 Beta testing is done by a limited number of end users before delivery. Usually, it
is done in the client place.

Live Environment Testing:

 It is nothing but testing the application in live environment (i.e) After Release.

6. Testing Techniques
Testing Techniques:
1. Equivalence case partitioning Technique
2. Decision Table Technique
3. State Transition Technique
4. Boundary Value Analysis
5. Error Guessing Technique
6. Adhoc Testing

1. Equivalence case partitioning Technique:

 In equivalence case partitioning technique, the test cases are equally divided
based upon positive and negative inputs.
 Example:
 Consider that we have to select an age between 18-56,
 Here the Valid inputs are 18-56 and the invalid inputs are <=17
and =>57.

Page 9 of 22
  Here we have one valid and two invalid test cases.

2. Decision Table Technique:

 In Decision table technique, we deal with combinations of inputs.
 To identify the test cases with decision table, we consider conditions and actions.
 We take conditions as inputs and actions as outputs.
 Example:
 Login validation - Allow user to login only when both the
username and password is correct.
 Conditions 1: Enter valid username and valid password
and Click Login.
 Actions 1: Display home page and Execute.
 Conditions 2: Enter invalid username and valid
password and Click Login.
 Actions 2: Display Error message as invalid username.

3. State Transition Technique:

 Using state transition testing, we pick test cases from an application where we
need to test different system transitions.
 We can apply this when an application gives a different output for the same
input, depending on what has happened in the earlier state.
 Example:
 Login with invalid username and password three times keeps the
account page blocked until change password.

4. Boundary Value Analysis:

 Boundary value analysis is based on testing the boundary values of valid and
invalid partitions.
 Every partition has its maximum and minimum values and these maximum and
minimum values are the boundary values of a partition.
 Example:
 If we want to enter an amount between 100 to 1000.
 Here we check based on boundaries for 100, we take 99,101 and
for 1000, we take 999, 1001.

5. Error Guessing Technique:

 Error Guessing is used to find bugs in software application based on tester’s
prior experience.
 Here we won't follow any specific rules.

6. Adhoc Testing:
Page 10 of 22
  Ad-hoc testing is an informal testing type.
 This testing is primarily performed if the knowledge of testers in the application
under test is very high.

7. Agile Methodology
SDLC Methodologies:
1. Waterfall Model
2. V-Model of Testing
3. Iterative Model
4. Agile Model

1. Waterfall Model:
 Simple and easy to understand and use.
 Each phase has specific deliverables and review processes.
 Documentation or artifacts maintained properly.
 Suitable for projects where requirements are well understood.
Disadvantages:
 Not suitable for projects where requirements are at a risk of changing.
 Cost of fixing defects is very high when detected at a later stage.
 Not a good model for complex and long projects.

2. V-Model:
 The V-model is an SDLC model where execution of processes happens in a
sequential manner in a V-shape.
 It is also known as Verification and Validation model.

3. Iterative Model:
 We are going to iterate each functionality in to each part and design, develop and
test and deploy.

4. Agile Model:
 AGILE methodology is a practice that promotes continuous iteration of
development and testing throughout the software development lifecycle of the
project. Here both development and testing activities are concurrent unlike the
Waterfall model.

Why we go for Agile?

Page 11 of 22
  More Control
 Better Productivity
 Better Quality
 Higher Customer Satisfaction
 Higher return on investment

Agile Manifesto (Principles):

 Individual and team interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
[Note: Framework we are following in Agile is Scrum.]

Agile:
 Roles
 Artifacts/Documents
 Ceremonies/Meeting

Members/Role Players in Agile:

 Product Owner:
 Product Owner defines features of the product and decides release date.
 Product Owner prioritize the features according to the market value and
profitability of the product.
 Product Owner can accept or reject work item result.
 Scrum Master:
 Scrum Master manages the team and look after the team's productivity.
 Scrum Master is responsible for setting up the team, scrum meeting invite
and removes obstacles to progress.
 Scrum Team/Dev Team:
 The team is usually about 5-9 members.
 The whole team involved in development and testing.
 Team manages its own work and organizes the work to complete the
sprint or cycle.
 And attend the scrum meetings

Different Artifacts used in Agile:

 Userstory:
 They are short explanation of functionalities of the system under test.
 Acceptance Criteria:
 They are detailed explanation of functionalities of the system under test
which is going to shows what we have to do.

Page 12 of 22
  Product Backlog:
 It is a collection of user stories captured for a scrum product.
 The product owner prepares and maintains the product backlog. It is
prioritized by product owner.

 Sprint:
 It is a set period of time to complete the user stories, decided by product
owner, usually 2-3 weeks of time.
 Sprint Backlog:
 It's a set of user stories to be completed in a sprint from the product
backlog.
 Burn-Up and Burn-Down Chart:
 The burn-up chart illustrates the amount of completed work in a project
whereas the burn-down chart depicts the amount of work remained to
complete a project. Thus, the burn-up and burn-down charts are used to
trace the progress of a project.

Agile Ceremonies or Meetings:

1. Sprint Grooming:
 Here the product owner will have already prioritized product backlog.
 Product Owner will be explaining the user stories.
 To understand the user stories.
 Meeting Duration - 1 hour.
 Attended by - Product Owner, Scrum Master and Scrum Team.
2. Sprint Planning:
 Userstory points will be given by developers.
 Complexity of the user stories will be estimated based on Poker Card
Technique.
 Work is selected from the Product Backlog and pulled into the Sprint
Backlog.
 Meeting Duration - 1 to 3 hours.
 Attended by - Scrum Master and Scrum Team.
-----------------------------------------------|Before Sprint|--------------------------------------------
3. Daily Scrum Meeting (or) Daily Stand up calls:
 Stand-up is designed to quickly inform everyone of what's going on across
the team.
 It's not a detailed status meeting. Following will be discussed in that
meeting
 What did I complete yesterday?
 What will I work on today?
 Am I blocked by anything?
 Meeting Duration - 15 minutes.

Page 13 of 22
  Attended by - Scrum Master and Scrum Team.
------------------------------------------------|After Sprint|---------------------------------------------
4. Sprint Review Meeting:
 After completion of every sprint, Team will give the showcase to the
product owner.
 Scrum team will show the demo of app with current sprint's completed
stories.
 Meeting Duration - 1 hour.
 Attended by - Product Owner, Scrum Master and Scrum Team.
5. Sprint Retrospective Meeting:
 Retrospectives help the team to understand what worked well–and what
didn't.
 Team will rate the sprint out of 10 and discuss the below
 What went right?
 What went wrong?
 What can be done better for next sprint?
 Meeting Duration - 1 hour.
 Attended by - Scrum Master and Scrum Team.

8. Defect Life Cycle

Defect Life Cycle:
 New:
 When the defect is found and posted for the first time.
 Assigned:
 Once the defect is posted (bug), it can be assigned to developers or testing
team lead, who will assign it to Developer.
 Open:
 Once the developer opens the bug and check whether it is valid or invalid.
 Fixed:
 When developer fix the bug with appropriate codes.
 Pending Retest:
 Once the developer fix the bug, it will be moved to testing team.
 Retest:
 When the tester retesting whether the bug raised was fixed or not.
 Verified:
 If the tester confirms that the bug is fixed.
 Reopen:
 If the tester confirms that the bug is not yet fixed and found the same defect.
 Again it will be moved to Assigned Stage and the flow continuous.
 Closed:
Page 14 of 22
  Once the tester verified that the bug is fixed, then the defect raised will be
closed.
 Duplicate:
 If the bug is already raised by someone, and if it is raised again means it is
duplicate.
 Rejected/Not a Bug:
 When the developer feels that the bug is not genuine.
 Deferred:
 The bug which developer feels that it can be fixed later on the upcoming
sprints/releases.

9. Priority and Severity

Priority and Severity:
 Severity:(Testers) - High, Medium and Low
 Explaining how severe the defect is going to impact the application.
 Priority:(Developers) - High, Medium and Low
 How soon the defect is going to be fixed

 High Severity, High Priority - Login, Search, Payment, etc.,

 High Severity, Low Priority - Links, websites, etc.,
 Low Severity, Low Priority - Content validation
 Low Severity, High Priority - Logo, colors

 In real time, due to conflicts in priority and severity, severity concepts will not be
there, only priority will be there, that priority will be given by testers itself.

10. JIRA

Defect Management Tool/Test Management Tool: JIRA

 JIRA is a tool developed by Australian Company Atlassian.
 It is used for bug tracking, issue tracking, and project management.

How to open an account in JIRA:

 Type "JIRA account create" in Google,
 Click on "Free - Jira Software | Atlassian",

Page 15 of 22
  Click Next
 Create an account - sign up with email
 Verify with email
 Give site name
 Select Scrum and click use template
 Select Project type as Company managed
 Enter Project Name

How to Create a Bug:

 Click Create or + Button
 Select Bug in Issue Type
 Give Summary - Defect Name
 Give detailed explanation of the defect in Description
 Environment:
 Platform:
 Build Number:
 Steps to reproduce:
 Actual results:
 Expected results:
 Priority:
 Screenshots:
 Link with userstory
 Assignee:
 Sprint:

11. GIT
GIT: (Source code management Tool or Version control Tool)
 To push our code from Local to Repository and pull the code from repository to
Local
 GITHub - Repository
 GITBash - Tool used to push and pull by using GIT commands

Open GITHUB Account:

 Google GITHUB SignUP --> Join GITHUB
 Create a repository
 Download GIT BASH

How to Push your code from Local to Repository?

1. Right click on your project

Page 16 of 22
 2. Click show in --> system explorer
3. Go inside the project
4. Right click and give GITBash here
5. Configure GIT(only one time process)
 git config --global user.email emailaddress
 git config --global user.name GITHUB username
6. Initialize our project (one time for one project)
 git init
7. Check the status of the code
 git status
8. Add the files
 git add .
9. Commit the files:
 git commit -m "message"
10. Add the repository path (First time push)
 git remote add origin url
11. Push your code
 git push -u origin master

How to clone the project from GIT?

1. Create an empty folder
2. Right click and give git bash
3. git clone url
4. Go to eclipse and click file --> import
5. Import the project to eclipse

How to create your own branch?

 Create a branch from master
 Checkout to own branch --> git checkout -b branchname

How to give access to other users?

 In repository, go to settings --> Collaborators

Main Branch:
 master --> main branch
1st Branch:
 Push code to own branch and give pull request and merge to master
2nd Branch:
 Take the latest pull from master and then only I can give pull request
 git pull origin master

Page 17 of 22
  If we are not taking the latest clone from master and try to give pull request
conflicts will occur in GITHUB, which will create Issues. SO what we should do
means we need to take latest pull from master and then remove header and tail
and then push or codes.

Example:
1st person:
 Login in GITHUB
 Create a new repository
 Local-->Select any project--> Right click--> open with system explorer
 Go inside the project and give gitbash
 Configure your GIT - First and only one time
 git config --global user.email merin@gmail.com
 git config --global user.name Merin
 Initialize your project - First and only one time
 git init
 git status --> to check what are the files you changed
 git add . --> to add all your changed files
 git commit -m "message" --> commit your local with repository
 git remote add origin repository url - only one time --> declare the url where
you need to push
 git push -u origin master --> push your code to repository
 give access to others

2nd person:
 Create a new folder in local
 Give git bash
 Configure your GIT - First and only one time
 git config --global user.email john@gmail.com
 git config --global user.name John
 git clone repository url
 Create a new branch john
 Import the project you cloned
 Select the project--> Right click--> open with system explorer
 Go inside the project and give gitbash
 git checkout -b branchname
 Scripting - method4, method5, method6
 Select the project--> Right click--> open with system explorer
 Go inside the project and give gitbash
 Initialize your project - First and only one time
 git init
 git status --> to check what are the files you changed
 git add . --> to add all your changed files

Page 18 of 22
  git commit -m "message" --> commit your local with repository
 git push -u origin branchname --> push your code to your branch
 give pull request
 1st person/Lead will review and merge

3rd person:
 Create a new folder in local
 Give git bash
 Configure your GIT - First and only one time
 git config --global user.email john@gmail.com
 git config --global user.name John
 git clone repository url
 Create a new branch kathir
 Import the project you cloned
 Select the project--> Right click--> open with system explorer
 Go inside the project and give gitbash
 git checkout -b branchname
 Scripting - method7, method8, method9
 Select the project--> Right click--> open with system explorer
 Go inside the project and give gitbash
 Initialize your project - First and only one time
 git init
 git status --> to check what are the files you changed
 git add . --> to add all your changed files
 git commit -m "message" --> commit your local with repository
 git pull origin master --> to get the update code from the master
 Conflicts will occur in form of header and tailer
 Resolve conflicts
 git status --> to check what are the files you changed
 git add . --> to add all your changed files
 git commit -m "message" --> commit your local with repository
 git push -u origin branchname --> push your code to your branch
 give pull request
 1st person/Lead will review and merge

12. Other Important Questions

1. Outsprint or n-1 Sprint:
 To automate user stories for the previous sprint, is called out-sprint automation.
 Consider there were few User stories from previous Sprint which could be
automated.

Page 19 of 22
 We will automate it in current sprint, which is called as n-1 or outsprint
automation.

2. Insprint in Agile:
 To develop and automate user stories in the same sprint, is called in-sprint
automation.
 Consider there were few user stories in a sprint which could be automated then,
we will be writing skeleton scripts until the developer develop the application.
 Once the build is delivered to testing team, after that we will execute the scripts.

3. Velocity:
 Total Number of user story points consider in a particular sprint (We can say 40
Points)

4. Risk Based Testing:

 Identifying the functionalities which seems to cause failures to the application
and then testing those functionalities.

5. Bug Leakage:
 Bug which is missed by the testing team while testing and if it is found by the end
user or customer in Live Environment.

6. Bug Release:
 Releasing the application to the Live Environment with the known bugs then we
call it as Bug Release.

7. Defect Age:
 It is the time interval between date of defect detection and date of defect closure.
 Defect Age = Date of defect closure – Date of defect detection.

8. HotFix:
 A bug which needs to handle as more than high priority bug and needs to be fix it
immediately.

9. RTM:

Page 20 of 22
  Requirements Traceability Matrix (RTM) is used to trace the requirements are
done by the testing side by matching the requirement with test cases.

10. Test Suite:

 Test Suite is a collection of test cases.

11. Test Environment:

 It is the combination of hardware and software on which Test Team performs
testing.

12. Test Strategy:

 Documents like Test Plan are prepared by keeping this document as a base.
 It is done by project manager.
 It is a high-level document which captures the approach on how we go about
testing the product and achieve the goals.

13. Exploratory Testing:

 Usually, this process will be carried out by domain experts.
 They perform testing just by exploring the functionalities of the application
without having the knowledge of the requirements.

Important Questions:
1. 7 principles of software testing?
2. Draw and explain SDLC?
3. Draw and explain STLC?
4. What is the difference between severity and priority?
5. What you mean by test plan, test scenario, test case?
6. What you mean by RTM?
7. Draw and explain defect life cycle?
8. What is difference between functional and non-functional testing?
9. What you mean by usability testing?
10. What is mean by accessibility testing?
11. What are the different automation tools we have in market?
12. What is defect management tool used in your project?
13. Draw and explain water fall model?
14. Difference between regression and re testing?
15. Difference between black box and white box testing?
16. Explain equivalence case partitioning techniques with an example?

Page 21 of 22
17. Explain Decision table with an example?
18. Explain state transition technique with an example?
19. Explain boundary value analysis with an example?
20. Explain error guessing?
21. Difference between formal and informal testing?
22. Explain Ad-hoc testing?
23. What is positive and negative testing?
24. What is test strategy?
25. What is test suite?
26. What is test environment?
27. What is test data?
28. What is test closure (or) sign off?
29. What is unit testing?
30. What is integration testing?
31. What is system testing?
32. What is beta testing?
33. What is smoke testing?
34. What is sanity testing?
35. What is monkey testing?
36. What is security testing?
37. What is performance testing?
38. What is walk- through?
39. What is bug leakage?
40. What is bug release?
41. What is Defect Age?
42. Give an example all the four categories of priority and severity?
43. What is the last userstory/functionality you worked on your project?
44. Write 5 defects which you raised in your project?
45. What is the current sprint you are working?
46. What is the total number of sprints so far in your project?
47. How many test cases manually we can prepare in a day?
48. How many test cases manually we can execute in a day?
49. How many automation test scripts we can prepare in a day?
50. How many automation test scripts we can execute in a day?

Page 22 of 22