Manual Testing

0)Why did you choose Software Testing as a Carrier?

1. I love helping others. 🙂 I proudly say that as a Software Tester, I do help in releasing a
quality product to the market.
2. I can help in finding bugs that are hidden in the software. Even though Developers do
their best to release a good product, there will be some mistakes.
3. I love to interact with people. As a Software Tester, I could get a lot of opportunities to
interact with people (not only peers, I could discuss with Stakeholder). Testers need to
know all parts of the application which they are going to test. So, we need to discuss
with clients too, to get more information on domain knowledge. This way we could
meet many people to share knowledge.
4. I love to write code too. Yeah, I am an Automation Tester. Who said one who can’t code
can choose a career in software testing? As an Automation Tester, I write code to find
the bugs in the system and involving in deliver of quality product.
5. FINAL WORD: My work helps Stakeholder better sleep.

1)What is Software Testing?

Testing the application whether it is working according to the client requirements or not.
2)What are principles of S/W Testing?
1. Start testing the application at the earliest.
2. We test the application to find the defects.
3. It is impossible to give 100% bug free product to the customer.
4. Pesticide paradox (If we are executing same set of test cases again and again there is no
scope for finding the new bugs in the system. To overcome this problem the set of test
cases needs to be regularly reviewed and revised.)
5. Defects Clustering (Small number of features caused the majority of the issues in the
application)
3)What is Manual Testing and Its advantages and disadvantages?
Testing the application manually without using any tool.
Advantages:
1. Application must be tested manually before automate.
2. Newly designed test cases should be executed Manually
Disadvantages:
1. It’s a time-consuming process while performing Regression Testing.
2. It is less reliable compare to automation because it is done by human.
4)What is Quality, QA and QC?
 1. Quality: Make sure that all the requirements are working according to the client
requirements by this we can maintain quality of software.
2. Quality Analysis: It’s a prevention activity, what standards we are following while
preparing the BRS document based on his requirements and these requirements are
well understood by Dev and Testers.
3. Quality Control: It’s done by the Real Testers to find the defects (Detection Activity).

5)What is the difference between Project and Product?

 Project: If the software is developed based on particular client requirements.
 Product: If the software is developed based on market requirements. (MS Office-
Microsoft, Gmail-google)

6)What is Verification and Validation?

Verification comes under static testing to test project documents in the form of reviews,
walkthrough and inspections before actual testing begins
Review: Conduct on documents to ensure correctness and completeness
 lead review
 peer review
eg: Test case review
 Test plan review
 code review.
Walkthrough: It is a formal review and we can discuss/raise at peer level
Inspections: It is a formal approach to the requirement schedules mainly 3 people involved in it
1-Reader,2-writer,3-moderator (manages team and act like coordinator among reader, writer,
team).
Validation: It comes under Dynamic testing to test the application by providing input and
observing results (Real testing on application)

7)SDLC (Software Development Life Cycle):

It’s the methodology to be followed by any company to give the quality of product/Project to
the client.

1. Waterfall model
2. V-Model
3. Spiral Model
4. Agile Model

Waterfall model: When do we go for Waterfall Model: When projects are small and
where the requirements are freeze(fixed).
1. It follows Top-Bottom approach.
2. One should move to next phase if and only if previous phase is completed.
3. It is recommended for small projects, where requirements are well understood
and stable.

Advantages
1. Quality of the product will be good.
2. Since the Requirements are not allowed often It is advantage for developer.

Disadvantages.
1. Not recommended for frequent changes if there any changes again we need to
start from beginning.
2. We cannot move to next phases until previous phase is completed.
3. If the requirements are unstable, time and budget will be very high.

V-Model: Verification and Validation: When customer is expecting high quality of

product within stipulated time because every stage is tested and
both Dev and Testers working parallel.

Advantage
1. Both Testers and Dev work parallel hence there is no scope for waste of time.
2. Testing team involves every stage of the product development hence it gives
quality of product.

Disadvantage
1. Initial investment is more because testers involve at the earlier stages.

Spiral Model: When Modules are interdependent.

Advantages
a. It allows requirement changes.
b. Suitable for large and complicated projects.

Disadvantages:
 a) Not suitable for small projects.

Prototype Model:
1. It is useful when the client is new to the IT market, we give him a KT on dummy
version based on his inputs if he satisfies with this dummy version
2. We make the software if not we will modify that dummy version based on his
requirements.

Agile Model (ITERATIVE & INCREMENTAL):

It is one of the methodologies to be followed to develop the software

Principles of Agile Model/Advantages:

1. Requirement changes always allows at any stage.
2. A piece of software will be delivered to customer within short period of
time.
3. Customer satisfaction is the must.
4. A good communication among Developers, Testers and Client.

Disadvantages:
1. Less focus on Documentation
2. It’s difficult to handle long term projects.

8)Testing Methodologies:
1. White box Testing
2. Black box Testing
3. Grey box Testing

White box Testing: It is done by the Developers, to check the internal code logic of an
application.
1. Unit testing: Testing the each and every component of an application
2. Integration testing: It is the combination of all unit test cases
Black box Testing: It is done by the real testers to test the application whether it is
according to the requirement or not.
1. Functional Testing: Testing the application by providing input and verifying
output whether it is meeting client requirements or not.
2. Non-Functional Testing: To Test the performance of the application by using
JMETER or any other performance tools.
 Load Testing: Gradual Increment of resources is called Load (Example suppose
User working with 10 resources then he increases the resources
with 20 then 30 to test the performance of an application)

Stress Testing: In this testing we can test the performance of the application by
putting beyond limit of resources

Grey box Testing: White box + Black box

9)Types of Testing
1. Functional Testing (Smoke, Component, Integration, System(E2E), Sanity and
User acceptance Testing)
2. Non-Functional Testing (Performance, Security and Reliability Testing)

10) Levels of Testing

1. Unit Testing
2. Integration Testing
3. System Testing
4. UAT Testing

PROJECT:
========================================================================
Description: HR Desk is a Human Resource Management System which comprises Admin
and Employee self-service modules. An HRMS Admin module has employee Personnel
Information Management (PIM), payroll management, leave approval, directory
information, attendance tracking, performance reviews, and the overall maintenance of
employee information within an organization. An HR Desk Employee self service module
has certain clerical tasks pertaining to the input of his/her personal information like
Contact details, Emergency contact details, Qualification details, Migration details, Skills
details which puts time back in the hands of HR professionals.

Domain: Human Resource

Client: Persistent systems.
Technologies: Java, MySQL, Jira Tool
Team:2
Roles and Responsibilities:
1. Understanding the requirements properly
2. Start developing the test scenarios and test cases
3. Written test cases get it reviewed by the lead/manager
4. Start executing the test cases if I found any bug report to the developer
5. Log the defect to JIRA as bug tracking tool.

SDLC (Software Development Life Cycle)

Phase-1: Requirement gathering: Customer will give his requirements to BA, based on
that BA will prepare BRS (Business Requirement spec) document.

BRS Document is not understand by the Developers and Testing team hence they
prepare FRS (Functional Requirement spec) it talks about each and every component of
an Application in detail.

Phase-2: Feasibility Study: In this phase Technical team from Dev side, Testing side and
project manager will sit together and discuss about the Requirement of Customer like
do we have scope to continue this project or not.

Phase-3: Designing: Based on the requirements understanding the Architect will prepare
design documents which are going to use for the developing the GUI part of the
application along with the application flow. High level doc: Which talks about overall
system design like architecture of an application. Low level doc: It is the detailing of HLD
and discuss logic for every component.

Phase-4: Coding: Based on the Requirement understanding, The Developers will start
coding for the application.

Phase-5: Testing:
STLC

Requirement understanding: Understand the requirements from FRS Document

Test Planning: It is a document which consists all the info about how testing process
going to be handled throughout the project, like how many recourses should
be needed and what are the entry exit criteria for diff testings’ and if we have
automation for the project which framework we need to follow.
Test Designing: Based on Requirement understanding we write the Test scenarios, Test
cases, RTM and Test design techniques

Test scenarios: It talks about what to be tested.

Test cases: It talks about step-by-step procedure how to be tested
RTM (Requirement Traceability Matrix): We should check all the requirements are
mapped with at least one test cases or not.
Test Design Techniques: While writing test cases for better test coverage we should
follow these techniques.

BVA (Boundary value analysis): By using this technique each field gets 6 test cases.

min-1
min
min+1
max-1
max
max+1

I applied BVA at Username

Requirement: Username should accept 3-20 characters only.

Username | Valid | Invalid

| min, min+1, max-1, max | min-1, max+1
| 3,4,19,20 | 2,21
| |
| |

ECP (Equal class partitioning): Divide the partition into two sections-->Valid and Invalid.

I applied ECP for password field in my project

Requirement: Password should contain combination of alphabets, numbers and special

symbols

Password: | Valid | Invalid

| rajkumar569@ | rajkumar/56987/@#$%^&
| |
| |
| |

Error Guessing: Generally tested by the team managers/leads because with help of their
experience and understanding level they can guess the error
Decision Table: Which talks about what are all interrelations between all the modules in
our application handled by Managers.

Test Execution: Smoke Testing-->Component Testing-->Integration Testing--

>System(E2E) Testing-->Sanity Testing-->Regression Testing.
---------------
****Smoke/Build Verification/Dry Run/Positive/Skim/Health check Testing?
It is the earlier testing to check whether the build is stable or not along with the core
functionalities of an application to be tested.

****Component Testing: Testing the each and every object/component of an

application.
****Integration Testing: It is the combination of all the components to be tested.
****System(E2E) Testing: Where we can test all the functionalities or features of an
application working according to the client req or not
****Sanity Testing: Once we raise defects then developers will fix and give new build we
should check performing well to accept or not, New functionalities to be tested if
designed any and any bug fixes have been tested.

What is Defect, Bug and Failure?

If the expected and actual results are not same then can say its defect.
If the defect is accepted by the developer, then we can say it is a bug.
If the bug is reached end user, then we can say it’s a failure.

****Regression Testing: Make sure that bug fixes should not affect the existing
functionalities in the application. After retesting we have to do the regression testing.

Defect Reporting (JIRA): Once we raise defect we need to report to the Developer.
-----------------------
Bug/Defect life cycle:
As a tester Ill raise the defect and assign to the developer
Developer opens the bug and start working on it
Once he fixes the defect, he reassigns back to the tester
I need to check whether the bug is fixed or not properly
If it is fixed close the bug. If it is not fixed Reopen the bug then the developer may
reject/accept/deferred.

Deferred bug: Due to lock of time any bug is not fixed in current release and will be
fixing in future releases then dev team will give it as deferred bug.

JIRA FLOW to raise the defect:

click on issue and select type as a bug and provide.
 1. Summary: Basic info about bug
2. Description: We should give details about bug and Expected and Actual Results
Steps to reproduce if possible, like (go to URL www.sample.com and click on next
button etc.)
3. Priority: Based on the functionality we can give: Highest, high, medium and low
4. Environment: Provide the details on which environment you found the bug line
(windows7/10 or Linux or Unix versions)
5. Attachments: Attach the screenshot of the bug for better fixing
6. Assignee: I can Assign to the relevant developer/development lead then log a
defect that’s it.

Difference between Severity and Priority

Severity severe the defect is affecting the functionality whereas Priority means how fast
it has to be fixed.

Severity types:
Blocker (You are unable to do the testing because something is stopping you to test the
application further)
Critical (Basic Functionalities are not working)
Major ()
Minor (Spelling mistakes, Alignment issues, Look and Feel problem etc.)

Priority Types:
p1(It should be fixed at the earliest)
p2(It should be fixed with in the same build but not at the earliest)
p3(It may be fixed in the upcoming builds)

UAT Testing: Once all the requirements are working according to the requirement then
we need to check once whether build is movable to production or not.

Retrospective Meeting/Postmortem Meeting:(What went well/What went wrong/What

are the areas we should improve)

What is Entry and Exit Criteria for Testing?

Entry Criteria:
1. Availability of Partially or complete build.
2. Approved requirements.
3. Required test data needed.
4. Test cases should be ready to execute.
5. Setting up the environment with all necessary resources like tools and devices.
Exit Criteria:
1. All critical test cases are passed.
2. All high priority bugs should be fixed.
3. Fixing all show toppers or blockers defects.
4. Achieve complete functional coverage.

Maintenance: There is a Service level agreement b/w Client and Service given company.
If the client faces any issues on software that we deliver we need to give our support to
him.

PROJECT RELATED AND REAL TIME SCENARIO QUESTIONS

====================================================================
1) How many Test cases have you written in your project?
Approximately I have written 190 test cases for my project.

2)How many test cases will you write every day?

For complex scenarios I used to write 3-4 test cases per day and for moderate
scenarios 12-15 test cases per day.

3) How many defects you reported in your project?

Approx. 55-60defects.

------few of the defects-------

Defect: If the file is more than 1 MB It should not allow user to upload a file but it does
Severity: Major, Priority=p2

Defect: After User logins it displayed Dash Board Page but expected My info page
Severity: Critical, Priority=p1

Defect: Login functionality is not working even though I provided valid username and
password
Severity: blocker, Priority=p1

Defect: Company logo is not visible clearly

Severity: minor, Priority=p2

4)How will you confirm application is meeting all the requirements?

If all the test cases are passed and no open bugs are there then we can confirm
application met all the requirements.
 5)When you stop testing?
As per the RTM (Requirement Traceability Matrix) all the test cases are covered and
passed and there are no open bugs then we can stop testing.

6)How will identify related functionalities in regression testing?

By using Decision table (Prepared by lead) we can identify what are the interrelated
functionalities, when bug is fixed. We will refer Decision table and execute test cases
accordingly in the part of regression testing.

7)What are diff test metrics you followed in your project?

How many valid and Invalid defects we raised, defect reject ratio, defect leakage ratio.

8) Suppose you find a bug in production. How do you make sure that same bug is not
introduced again?
Make sure that, the bug should cover in next regression suite (through testing) so that
the same bug will not be introduced.

9) What do you do when your developer denies that what you filed is a BUG?
In that scenario provide business documentation reference to support why the existing
function is not as per design. Involve Product owner/business analyst into that
discussion.

10) What has been one of your greatest challenges while doing regression testing?
Test Data Issue: Because the data once used will be used again for signup and for
other details.

11) Enlist some of the key challenges that are faced while performing software testing?
1. i)Test Data Issue: Because the data once used will be used again for signup and
for other details.
2. ii)Environment Available: The Availability of an environment is one of the
challenges that I faced while I was testing because they were 1 system available,
we need to work on 3 diff user stories.
12) Static Testing: Dynamic Testing
1. This testing comes under Verification part | This testing comes under Validation
part.
2. Its deals with Review code, FRS Doc, | It deals with executing our test cases.
3. It is done before build deploy | It is done after the build is deployed
4. It’s used to prevent the defects | Its used to find and fix the defects.
 13) Smoke Testing Sanity Testing
1. This is the earlier testing to test build is stable | This testing is done to check new
or not functionality and bugs have fixed
2 It is done by both developers and testers | It is done by only Tester
3 Smoke testing is subset of Acceptance testing | Sanity is the subset of Regression

14) Reliability Testing: Testing the functionalities of the application continuously for a
particular period of time.

15) Recovery Testing: If the application gets any crashes while using and how fast it is
recovering from it.
16) Usability Testing: Testing the User friendly of an Application. How friendly is to use.
17)What is Impact Analysis Meeting in Testing?
For following reasons, we will do impact analysis meeting.
 Whenever developer trying to add new feature.
 Whenever developer trying to remove existing feature
 Whenever developer do any modification to the existing functionalities
 Whenever developer trying to fix the bug

Developer, Tester and Product owner are included in the meeting.

18)Defect Masking: If we have 4 modules and those modules have defects in it but we are
Unable to test those defects because of a blocker.
Example: There are defects present in the employee self-module but I am unable to test
Those defects because login itself blocking me to test (In Lehman terms: One defects
Is hiding another defect)

19) Error Seeding: Developers wontedly pushing the bugs to the application to test the
Tester’s testing.

20)What are Defect Metrics:

Generally, it is performed by the team lead/manager Suppose out of 84 defects we
reported, only 64 are actual defects. It means 20 defects we reported are wrong. It is
mistake in our testing.

Defect Rejection Ratio=No of defects Rejected/Total no of defects*100

= 20/64*100=31.8%
Suppose the software has 50 defects and but our testing team defects only 20 defects
that means they missed 30 defects.
Defect Leakage Ratio=no of leakage ratio/total no of defects*10
=30/50*100=60%(Leakage)

21)What is defect triage?

Defect triage helps where large number of defects and limited testers to verify them.
More system consider only priority is the main criteria to assess the defect but defect
triage covers severity as well.
Defect triage process involves.

Defect Review=What are the defects we raised and what are the defects we fixed.
Defect Assessment=Defects resolved yet to verify
Defect Assignment=These defects assign to the other testers.

22) What is Database Testing?

Testing the DML (Insert, update, delete) called DB Testing
When we enter the details on GUI Application, we need to check whether these values
are stored into the database or not properly.
Simple terms Front end Application and Database are in synch or not.

23)What is Beta-Testing?
It is the testing will be done before Application is moved to the Production level by the
Test Manager to check the Application behavior and functionalities randomly.

24)What happens if we don’t write Test cases?

While writing test cases we think in analytical way. I come up with creative scenarios to
break the system its one-time job next time I don’t need think about
so much scenarios this is advantage of Test cases writing

25)What are all the Common mistakes that will be done by the Testers?
If they didn’t understand the requirements thoroughly, they tend to raise wrong
defects.

26)How to differentiate Functional and Non-Functional Requirements?

Functional requirement says "What system should do?
Non-Functional says "How system will work and respond in particular scenarios?

27)What is the reason we face bug leakage?

 There may be a chance Tester could not understand the requirements properly.
 There may be a chance Developer implemented the wrong code.
 There may be a chance Test cases not reviewed properly.
28)What are Software Staging Environments?
Development Environment: Where Developers write their code.
QA Environment: Where Testers executes their test scripts.
Stage/Beta Environment: Its similar like production Environment where build will be
tested before move to the Production Environment so that Client may not get much
failures.
Production Environment or Go-Live: Where actual software takes place.

29)If you find bug in the production what do you do/How to do a root cause analysis for
a bug?
First of all, try to assist to resolve the bug as early as possible. Then find ROOT CAUSE OF
THAT BUG

There will be 2 cases for that.

1. If the bug is because of our testing mistake like test coverage is not enough look
for, when did we execute that bug first try to find out the screenshots and any
email reports for it then try to explain why the bug escape to production.

2. If that is a new bug try to assist developer to fix it sometimes bugs come
different of Test env and Production env.

30)Difference between Test Strategy and Test plan?

Test Strategy
=============
1. It’s a high-level document (static document) prepared by the Project
Manager.
2. It defines the approach on how we go about testing the product and
achieve the goals and it is derived from BRS Document
3. It works as a base for Test Plan.

Test Plan
=========
1. It is prepared by the Test Manager or Test Lead.
2. It is a document which consists all the info about how testing process
going to be handled throughout the project, like how many recourses
should be needed and what to test and what not to test and whom to
test and if we have automation for the project which framework we need
to follow.
31. What are comes under UI Checklist Testing?
 Spelling mistake on UI
 Any grammar mistakes on UI
 Check whether the text is readable
 Check right alignment of text
 Check text is not overlapping with any other element
 Mandatory (*) fields should work according to its requirement

32.What is acceptance criteria in testing?

Acceptance criteria are the conditions that a software product must satisfy to be accepted by
user

Based on the acceptance criteria a tester can perform testing.

Example: An acceptance criterion for USER STORY

Login functionality

Acceptance criteria 1

As A user I am on login page

And I provide username and password
And click on login in button
Then I am successfully log in to application

Acceptance criteria 2

As A user I am on login page

And I provide invalid username and password
And click on login in button
Then it should provide message like “please provide valid username/password”.

31) Testing Pyramid:

 E2E Testing
|
Integration Testing
|
Unit Testing

1. Unit Tests

Unit Tests focus on the smallest unit of code, like functions or classes.

They are short and don’t have any external dependencies. If they have an external
dependency, you use mocks instead.

If a unit test fails, finding the issue is typically a simple process. They also have a reduced
testing scope which makes them simple to write, fast to run, and easy to maintain.

2. Integration Tests

Integration Tests focus on the interaction between two distinct entities. They are typically
slower to run because more things need to be set up.

If integration tests fail, finding the issue is a bit more challenging because the failure range is
bigger.

They are also harder to write and maintain, mostly because they need more advanced
mocking and increased testing scope.

3. End-To-End tests

Lastly, E2E tests focus on flows, from the simplest up to the most complex. They can be
viewed as a multi-step integration test.

These tests are the slowest to run because they involve building, deploying, firing up a
browser, and performing actions around the application.

If E2E tests fail, finding the issue is often difficult because now the failure range is expanded
to the entire application. Basically, along the path, anything could have broken.

They are by far the hardest type of tests to write and maintain (from the three types
considered here) because of the huge test scope and because they involve the entire
application.