0% found this document useful (0 votes)
25 views38 pages

Manual Testing_Notes

Uploaded by

chennai.imanet
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
0% found this document useful (0 votes)
25 views38 pages

Manual Testing_Notes

Uploaded by

chennai.imanet
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 38

MANUAL 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:

• Functional Testing

• Non-Functional Testing

1. Functional Testing:

Checking the functionalities of the application.

• Manual Testing (Testing the functionalities by manual)

• Automation Testing (Testing the functionalities by using tools/scripts)

• Webservices 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:

1. Performance Testing:

• They add virtual number of users accessing the application simultaneously and at a same time

to check the performance of the application.

Tools Used:

• J-Meter Open-Source Tool

• Load Runner Paid Version

Load/Stress Testing:

• Process of adding load and making the application stress is called Load/Stress Testing.

2. Usability Testing:

• To check how good the application is user friendly.

3. 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 and NVDA

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 defect). It was found that 80% of

defects comes from 20% of the modules.

5. 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 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 related to).

7. Absence of error is a fallacy (Instead of telling bug free, make sure the environments are

matching with the client requirement).

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

Software Development Life Cycle:


1. Requirement gathering and analysis:

• A Contract will be signed between client and marketing team.

• Business Analyst (BA) will try to 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.
STLC Overview:

• Software Testing Life Cycle (STLC) is defined as a sequence of activities conducted to

perform Software Testing.

• Each of these stages have a definite Entry and Exit criteria;

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.

Phases of STLC:

• Requirement Analysis

• Test Planning

• Test Design

• Test execution

• Sign Off

1. Requirement Analysis:

Entry Criteria: Contracts, BR 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

• Preparation of test plan document for various types of testing

• Test tool selection

• Resource planning

Exit Criteria: Test Plan.

3. Test Design:

Entry Criteria: Test Plan

• Create test scenarios, test cases, automation script, RTM(Requiremnet Tracability Matrix)

• Create test data

• Review test cases with peer or lead

• Get Approval

Exit Criteria: Test Scenarios, Test Case, Test Data, RTM.

4. Test Execution:

Entry Criteria: Test Scenarios, Test Case, Test Data, RTM

• Execute tests as per plan

• Document test results, and log defects for failed cases

• Track the defects to closure

• Retest the Defect fixes

Exit Criteria: Execution Result, Defect Log.


5. Sign Off:

Entry Criteria: Execution Result, Defect Log

• Evaluate cycle completion

• Prepare Test closure report

• Test result analysis

Exit Criteria: Closure Document.

Types of Testing:

Test Scenario:

It is high level Testcase. It is an idea of what we are going to test.


Test Case:

It is an idea of how we are going to test, it includes test case (tc) name, test data, expected & actual

results, status, etc.

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 raises a defect to developer then it is called as bug.

Different Types of Testing:

White Box Testing:

White Box Testing is also called as Glass Box, Clear Box, and Structural Testing. It is based on

applications internal coding knowledge. It is done by developers.

Black Box Testing:

Black Box Testing is a software testing method in which testers evaluate the functionality of the software

under test 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.

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.

Regression Testing:

It is done to make sure the existing functionalities of the application is not impacted whenever any new

functionalities are 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 rigorous regression testing can’t be done to the build, sanity testing

does that part by checking main functionalities.

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.

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.

Testing Techniques:

1. Equivalence case partitioning Technique

2. Decision Table Technique

3. State Transition Technique

4. Boundary Value Analysis

5. Error Guessing Technique

6. Ad-hoc Testing
Equivalence partitioning Technique:

• In equivalence partitioning, 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.

• Here we have one valid and two invalid inputs.

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.

o Actions 1: Display home page and Execute.

• Conditions 2: Enter invalid username and valid password and Click Login.

o Actions 2: Display Error message as invalid username.


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.
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 98, 99, 101, 102 and for 1000, we take 998, 999,

1001, 1002.
Error Guessing Technique:

• Error Guessing is used to find bugs in software application based on testers prior experience.

• Here we won’t follow any specific rules.

Ad-hoc Testing:

• Ad-hoc testing is quite opposite to the formal testing.

• It is an informal testing type.

• In Ad-hoc testing, testers randomly test the application without following any documents and test

design techniques.

• This testing is primarily performed if the knowledge of testers in the application under test is very

high.

• Testers randomly test the application without any test cases or any business requirement

document.

Defect Life Cycle:

New:

When the defect is found and posted for the first time.

Assigned:

Once the defect is posted(bug), the testing team lead will assign it to Developing Team.

Open:

Once the developer opens the bug and works on to fix it.

Fixed:
When developer fix the bug with appropriate codes.

Pending Retest:

Once the developer fixes 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:

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.
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 these 4 levels of testing are completed only, we can say the application is

ready for release.

• Unit Testing

• Integration Testing

• System Testing

• Acceptance Testing

1. Unit Testing:

• 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

• Test based on Black Box Testing Techniques

o Big Bang Approach - Combing all combination of units

o Top-down Approach - Higher level combinations of units

o Bottom-up Approach - Lower level combinations 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 levels of testing are completed only, we can say system testing is completed

4. Acceptance Testing:

• Getting approval from client

• Done by client side

• Testing will be done at Development/Testing Environment

• Satisfying client requirement.


SDLC Methodologies:

• Water Fall Model

• V-Model of Testing

• Iterative Model

• Agile Model

1. Waterfall Model:

• Simple and easy to understand and use.

• Each phase has specific deliverables and review processes.

• Documentation and 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?

• 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:

1. Roles

2. Artifacts/Documents

3. 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:

User story:

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.
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.

Burnup and Burndown 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.

• Qtest - Test Management Tool

• JIRA - Defect Management Tool and Test Management Tool

Agile Ceremonies or Meetings:

1. Sprint Grooming:

• To understand the user stories.

• Product Owner will be explaining the user stories.

• Meeting Duration - 1 hour.

• Attended by - Product Owner, Scrum Master and Scrum Team.


2. Sprint Planning:

• Here the product owner will have already prioritized product backlog.

• Work is selected from the Product Backlog and pulled into the Sprint Backlog.

• Complexity of the user stories will be estimated based on Poker Card Technique.

• 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.

• 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.

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 “Try - Jira Software | Atlassian”,

• Click Try Free on Jira Software

• Create an account

• Select Scrum

• 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


o Environment: Testing Env

o URL: www.aircanada.com/dev/46768596968

o Steps to reproduce: 1.

2.

3.

o Actual results:

o Expected results:

o Priority:

o Severity:

o Screenshots:

o Assignee:

Priority and Severity:

Severity: (Testers)

Explaining how severe the defect is going to impact the application.

Priority: (Developers or PO)

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


PROJECT DOMAIN

Travel Domain:

• Car: Ola, Uber

• Bus: Redbus, Makemytrip

• Train: irctc

• Air: Air India, Air Canada

Airline Domain:

Select any airline which should not be familiar among us (eg: European and African Airlines)

Modules:

• Booking Module: Explain the complete booking flow to book a flight ticket

• Check In: It is a process that a particular airline accepts the passenger prior to travel

o It is done at airport and online airline authority to enter the passenger to board their flight

o Boarding Pass: Pass given by airline

• Flight Status: To check the status of the particular flight

• Login: Credentials given by the airline to the frequent customers and agents

o Guest

o Frequent Flyer

o Agent

• Baggage: Maintaining the passenger's luggage

o Carryon Baggage - Carry inside flights

o Checkin Baggage - Other Bags based upon weights

• Upgrade: Passenger can travel from his lower class to upper class
Booking Module:

1. Home Page:

• Trips

o Round Trip - Chennai to Madurai to Chennai

o One Way - Chennai to Madurai

o Multicity - Chennai to Madurai to Trichy to Bangalore to Mumbai

• Passenger

o Adult (16-18+)

o Youth (12-16 or 12-18)

o Child (2-11)

o Infant (0-2)

• Source and Destination

• Travel Date

• Promocode - Offer given by the airline for the particular routes or flights

2. Flight Select Result Page:

• Flight Name

• Travel Duration - Departure and Arrival Time

• Flight Details - Direct or connecting flight

• Cabin Selection

o Economy

o Premium Economy

o Business

• Fare Details
3. Passenger Information Page:

• Complete passenger details with first name, last name, gender, DOB, Mobile No, Email Address

and Frequent Flyer Program

4. Seat Selection Page:

• Available Seats

o Regular Seats - Not payable

o Preferred Seats - Payable for Extra Legroom, etc.

• Occupied Seats

5. Payment Page

• Different Types of payment to be made

o Online Banking

o Card payment

o App Payment

6. Booking Confirmation Page:

• PNR (Passenger Name Record) / Booking Reference Number

• Seat Number

• Ticket in downloadable format

7. Manage My Booking Page:

• Cancel Booking by entering Last Name and PNR

• Change Seats

• Change Flight

• Change Cabin
Ecommerce Domain:

Online Purchasing Websites

E.g.:

• Amazon

• Flipkart

• Snapdeal

Ecommerce Domain:

Select any online purchasing websites which should not be familiar among us.

Modules:

• Purchasing Module - End to End purchasing a product

• Login Module - Credentials given by the website

• Cart Module - Managing our purchasing

• Product List Module - List of products available in the website

Purchasing Module:

1. Home Page:

• Hero Image

• Search Product

o By providing product name

o By clicking on product list

o By clicking the offers available

o By clicking on our preferred products available


2. Search Result Page:

• List of searched products available

• Product Details with different brands

• Image

• Price

• Offers

• Review

• Filters

• Multiple pages available

3. Product Details Page:

• Detailed information of the selected product

• Offers available for the selected product

• Additional Images of the selected product

• Review of the selected product

• Delivery Options

• Shipping Information

• In Stock/Out of Stock

• Add to Cart

4. Shopping Cart Page:

• Selected product is added

• No of products

• Total amount with delivery charges and discounts

• Add a product
• Remove a product

• Shipping amount with different shipping options

5. Payment Page

• Different Payment Options

• Purchase by Guest or Login

• If no login, give sign up

• Storing card details

• Session timeout if signed up for a long time

• Email/SMS confirmation

6. My Orders:

• Change the order

• Cancel the order

• Track the order

• Returns
Banking Domain:

• Process involved in Banks

• Select any of the country bank which should not be familiar among us except Asia.

• In banking there several business operations like

o Core Baking system

o ATM Banking

o Internet Banking System

o Asset liability management system

Modules:

• Admin (Login)

• Personal Banking

• Corporate Banking

Personal Banking:

• Login Page

• Balance Enquiry

• Open Deposits

• Apply for Loans

• Apply Credit Card

• Pay Credit Card Bill

• Bill Payments

• Transaction Status
Insurance Domain:

• Process involved in Insurance Companies

• Select any of the country insurance which should not be familiar among us except Asia.

Modules:

• Login: Member, Employer, Doctors/Providers

• Plan Coverage

• Claims

Plan Coverage:

• Plans

• Coverage

• Find a Doctor

• Other Services

Claims:

• How to Submit a claim

• View Claims and statements


Other Important Questions:

1. Insprint in Agile:

• To develop and automate user stories in the same sprint, is called in-sprint automation.

• If there are 4 User stories in a sprint which could be automated then, We will write a skeleton

scripts for the User stories which we are going to automate it in this sprint.

• In a 2 weeks sprint, for 6 days developer will Develop the application and on 7th day the build is

delivered to Automation team.

• After that we will execute the scripts.

2. Outsprint or n-1 Sprint:

• To automate user stories for the previous sprint, is called out-sprint automation.

• Say there were 4 User stories from previous Sprint (Sprint1) which could be automated.

• I will automate it in Sprint 2, which is called as n-1 or outsprint automation.

• In my previous Sprint i.e., Sprint 1, I will be working on the framework setup.

3. Velocity:

Total Number of user story points consider in a particular sprint (We can say 40 Points)

4. Capacity:

• Total no of working days*Total no of resources*Total number of working hours(PD) = Capacity

o Capacity= 10*7*8

5. Risk Based Testing:

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

functionalities.

6. 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.

7. Bug Release:

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

8. 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

• For Example, A defect was found and reported on 17 May 2020 and it was fixed on 22 May

2020. So the defect age is 5 days.

9. HotFix:

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

10. RTM:

Requirements Traceability Matrix (RTM) is used to trace the requirements are done by the testing side by

matching the requirement with test cases.

11. Test Suite:

Test Suite is a collection of test cases.

12. Test Strategy:

• It is a high-level document which captures the approach on how we go about testing the product

and achieve the goals.

• It is developed by project manager.

• Documents like Test Plan are prepared by keeping this document as a base.
13. Test Environment:

It is the combination of hardware and software on which Test Team performs testing.
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?

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?
Others

• What is the last user story/functionality you worked on your project?

• Write 5 defects which you raised in your project?

1. What is the current sprint you are working?

2. What is the total number of sprints so far in your project?

3. How many test cases we can execute in a day?

4. How many test cases we can prepare in a day?

5. How many automation test scripts we can execute in a day?

6. How many automation test scripts we can prepare in a day?

You might also like