1) Test Strategy Vs Test Plan?

A Test Strategy is a set of instructions, guidelines or principles that determine the test design and
how the testing process will be carried out. It sets the testing process standards. Documents like test
plans derive their content from the test strategy document. It can comprise of the principles used to
detail the scope and overview of the testing process, testing methodology, specifications for testing
environment, tools used for testing, release control, risk analysis and mitigation, review and
approval of a product before its official release.

A Test Plan is a document that describes the various actions that will be carried out in the testing
process – ranging from a strategy for development to error detection criteria in detail. This
document also specifies the methods to resolve any risks detected. It defines the approach, assets,
and time schedule of the planned testing activities. It identifies the scope and objective of the
software testing process, the various features that need to be tested, tasks that need to be carried
out during testing, techniques used to design the tests, and so much more. Basically, it records the
whole process of planning tests that need to be carried out on the product.

What's the importance of a test plan? A test plan is the foundation of every testing effort. It helps
set out how the software will be checked, what specifically will be tested, and who will be
performing the test. By creating a clear test plan all team members can follow, everyone can work
together effectively.

Parameter Test Plan Test Strategy

A test plan is a document that A test strategy is a high-level document that
Definition encompasses the scope and different encompasses guidelines and principles involved in
activities involved in the testing process. carrying out the testing process.
The primary goal here is to define how to
test a product, what to test it on when to Here, the primary goal is to define the principles to be
Goal
test it, who will test, and who will verify followed during the testing process.
the results.
It is done to identify possible
inconsistencies in the final product and It is a plan of action of the testing process on a long-
Purpose
mitigate them through the testing term basis.
process.
Level It is used on a project level only. It is used on an organizational level.
It is used by one project only and is very It is used by multiple projects and can be repeated a
Repetition
rarely repeated. lot of times.
It is a dynamic document and can be
Change
changed repeatedly depending on testing It can not be changed since it is a static document.
Susceptibility
specifications.
Its components include – test plan ID,
features that need to be tested, Its components include – objectives and scope,
Components
techniques to be followed, testing tasks, documentation, test processes, etc.
pass or fail criterion, schedules, etc.
It is managed by the testing manager or
Managed by It is managed by the project manager.
testing lead.
It thoroughly defines the whole testing It only focuses on high-level test methods and
Scope
activities. strategies.

Page | 1
 Parameter Test Plan Test Strategy
It is derived with the help of
Use case documents, software It is derived from the business requirement
Derivation
requirement specification documents, specification document.
and product description documents.
Existence It is usually found to exist individually. It can be a part of test plans, in some cases.
Basis It is based on testing strategies. It is based on standards that have been pre-defined.
Analytical strategy, model-based strategy, methodical
Level-specific test plans, type-specific test
strategy, standard-compliant strategy, reactive
Types plans, and master test plans are the
strategy, consultative strategy, and regression averse
different types of test plans.
strategy are the different types of test strategies.
Influence It affects only a single project at a time. It affects many projects at a time.
It narrates the common specifications in
Narration It narrates the approaches in testing.
the testing of a particular project.

The test strategy should be prepared during the initial phase of the project. It is always advisable to
have the test strategy documented at the earliest possible stage of the project because it gives a
clear idea to test lead/manager about the project scope. However if there are any open points or
dependencies due to which it could not be frozen, better to have the other parts covered and not to
wait for all dependencies resolved to start with.

Test strategy is made before the test plan.To summarize, the Test Plan is a vision of what you want
to achieve and the Test Strategy is an action plan designed to achieve this vision!

Common Sections of Test Strategy Document

• Step #1: Scope And Overview

• Step #2: Test Approach
• Step #3: Test Environment
• Step #4: Testing Tools
• Step #5: Release Control
• Step #6: Risk Analysis
• Step #7: Review And Approvals

2)What are the good qualities in software tester?

• Strong communication skills

• Creative Mind
• Analytical Skills:
• Good Listener:
• Proactively Passionate
• Quick Learner
• Domain Knowledge
• Client-Oriented
• Ability To Organize And Prioritize
• Ability To Identify And Manage Risks
• Ability To Work In A Team

Page | 2
3)Defect Bug and Failure

A mistake in coding is called Error, error found by tester is called Defect, defect accepted by
development team then it is called Bug, build does not meet the requirements then it Is Failure

Fault:A fault is an incorrect step, process or data definition in a software product.

Defect: Defect is defined as the deviation from the actual and expected result of application or
software or in other words, defects are defined as any deviation or irregularity from the
specifications mentioned in the product functional specification document. Defect is also solved by
the developer in development phase or stage.

Reasons for Defects:

• Any deviation from the customer requirements is called as defect.

• By giving wrong input may lead to defect.
• Any error in logic code may lead to defect.
Bug : Actually bugs are faults in system or application which impact on software functionality and
performance. Usually bugs are found in unit testing by testers.

There are different types of bugs, some of them are given below.

• Functional Errors
• Compilation Errors
• Missing commands
• Run time Errors
• Logical errors
• Inappropriate error handling
Failure : Once the product is completed and it is delivered to the customers and if the customer find
any issues in product or software then it is the condition of failure of product.
In other words, if an end user finds an issue in product then that particular issue is called as failure.

4) Verification Vs Validation and where does QA fits in verification process?

Verification is done at the starting of the development process. It includes reviews and meetings,
walkthroughs, inspection, etc. to evaluate documents, plans, code, requirements and specifications.
Quality Assurance focuses on preventing defect. Quality Assurance ensures that the approaches,
techniques, methods and processes are designed for the projects are implemented correctly.

Verification: process of evaluating steps which is followed up to development phase to determine

whether they meet the specified requirements for that stage.
Validation: process of evaluating product during or at the end of the development process to
determine whether product meets specified requirements.
Difference between Verification and Validation:
- Verification is Static Testing where as Validations is Dynamic Testing.
- Verification takes place before validation.
- Verification evaluates plans, documents, requirements and specifications, where as
Validation evaluates product.
- Verification inputs are checklist, issues list, walkthroughs and inspection, where as in
Validation testing of actual product.
- Verification output is set of documents, plans, specifications and requirement documents
where as in Validation actual product is output.

Page | 3
5)In SDLC model where does STLC fits in?

As we have seen, testing is a vital phase in SDLC, and STLC is just a framework for defining the tasks
performed during testing, so STLC is a subset of SDLC.
During project development, the team may decide to follow different models. These can vary from
waterfall, iterative, or Agile, but whatever the model, development and testing activity begin in
parallel. Therefore, SDLC and STLC run in parallel.

SDLC life cycle is a process of developing software through a phased manner in the following order

1. Requirements Gathering
2. Design the software
3. Build the Software
4. Test
5. Deployment
6. Maintenance.

Each stage has a definite entry and exit criteria along with deliverables.

STLC is part of SDLC. It can be said that STLC is a subset of the SDLC set. STLC is limited to the testing
phase where quality of software or product ensures. SDLC has vast and vital role in complete
development of a software or product.

6) 5 reasons why Agile is better than Waterfall ?

1.Less prone to error
Waterfall relies heavily on initial requirements. However, if these requirements aren’t documented
precisely, or there was a misunderstanding around the detail of what the customer wanted, it makes
things very difficult. Not so with Agile – requirements are checked and confirmed throughout the
project.
2. More flexible
Once a step has been completed in Waterfall, it’s difficult to go back and make changes. In contrast,
Agile builds a working version of the whole project (an MVP) so the customer can shape how it’s
built. Seeing a working version early on in the project allows the customer to say ‘I like this, but I
don’t like that’, and so shape the product according to their requirements. This is harder to do with
Waterfall because the customer has to outline all their preferences upfront, without seeing a
working version.
3. More predictable end product
With Waterfall, the product is mainly tested at the end of the project. If the customer’s needs
weren’t captured well initially or they have changed since the start of the project, testing may come
too late in the cycle to make big adjustments. The customer then has to find extra budget to get the
product they now need. With Agile, testing happens regularly through the whole process, so the
customer periodically checks that the product is what they envisioned. This also makes it more likely
that the project will finish on time, and on budget.

4. More open to changes/additions

Waterfall isn’t geared to take into account a customer’s evolving needs. If business processes change
during the project Waterfall isn’t set up to adapt to this. Often a client feels locked into a project
that no longer meets the current business need. In contrast, Agile not only has the ability to adapt to
changing needs, but it expects them and plans for them.

Page | 4
5. More customer involvement
Agile sees the customer as part of the implementation team and includes them at each part of the
process. In contrast, Waterfall tends to spend a lot of time with the customer at the start, trying to
document all the perceived requirements. But once this has happened, the implementation team
usually take over.

7) Truncate, Delete and Drop

TRUNCATE Command is a Data Definition Language operation. It is used to remove all the records
from a table. It deletes all the records from an existing table but not the table itself. The structure or
schema of the table is preserved.
Truncate statement is equivalent to DELETE operation without a WHERE clause. The truncate
command removes the records from a table without scanning it. This is why it is faster than the
DELETE statement.
DELETE
The DELETE statement in SQL is a Data Manipulation Language(DML) Command. It is used to delete
existing records from an existing table. We can delete a single record or multiple records depending
on the condition specified in the query. TRUNCATE TABLE Employees;
The conditions are specified in the WHERE clause of the DELETE statement. If we omit the WHERE
clause then all of the records will be deleted and the table will be empty.
The DELETE statement scans every row before deleting it. Thus it is slower as compared to
TRUNCATE command. If we want to delete all the records of a table, it is preferable to use
TRUNCATE in place of DELETE as the former is faster than the latter.
DELETE is a DML Command so it can be rolled back.
The DELETE command returns the number of records that were deleted by its execution.
DROP
DROP statement is a Data Definition Language(DDL) Command which is used to delete existing
database objects. It can be used to delete databases, tables, views, triggers, etc.
A DROP statement in SQL removes a component from a relational database management system
(RDBMS).
DROP is a DDL Command. Objects deleted using DROP are permanently lost and it cannot be rolled
back. DELETE FROM Employees;
Unlike TRUNCATE which only deletes the data of the tables, the DROP command deletes the data of
the table as well as removes the entire schema/structure of the table from the database.
DROP TABLE Employees;
This query will remove the whole table Employees from the database.
DROP DATABASE Company;
This query will delete the database Company.
DROP Command removes the table definition and all the data, indexes, triggers, constraints and
permission specifications for that table.
8) Joins in SQL?

→INNER JOIN

SELECT columns
FROM table1
INNER JOIN table2
ON table1.column = table2.column;

Page | 5
 customer_id last_name first_name favorite_website

4000 Jackson Joe techonthenet.com

5000 Smith Jane digminecraft.com

6000 Ferguson Samantha bigactivities.com
7000 Reynolds Allen checkyourmath.com
8000 Anderson Paige NULL
9000 Johnson Derek techonthenet.com
And a table called orders with the following data:

order_id customer_id order_date

1 7000 2016/04/18
2 5000 2016/04/18
3 8000 2016/04/19
4 4000 2016/04/20
5 NULL 2016/05/01
SELECT customers.customer_id, orders.order_id, orders.order_date
FROM customers
INNER JOIN orders
ON customers.customer_id = orders.customer_id
ORDER BY customers.customer_id;
There will be 4 records selected. These are the results that you should see:

customer_id order_id order_date

4000 4 2016/04/20
5000 2 2016/04/18
7000 1 2016/04/18
8000 3 2016/04/19

This example would return all rows from the customers and orders tables where there is a
matching customer_id value in both the customers and orders tables.
The rows where customer_id is equal to 6000 and 9000 in the customers table would be omitted,
since they do not exist in both tables. The row where the order_id is 5 from the orders table would
be omitted, since the customer_id of NULL does not exist in the customers table.

OLD Syntax for Inner Join:

SELECT customers.customer_id, orders.order_id, orders.order_date

FROM customers, orders
WHERE customers.customer_id = orders.customer_id
ORDER BY customers.customer_id

Page | 6
→SQL LEFT OUTER JOIN

SELECT columns
FROM table1
LEFT [OUTER] JOIN table2
ON table1.column = table2.column;

customer_id last_name first_name favorite_website

4000 Jackson Joe techonthenet.com
5000 Smith Jane digminecraft.com
6000 Ferguson Samantha bigactivities.com
7000 Reynolds Allen checkyourmath.com
8000 Anderson Paige NULL
9000 Johnson Derek techonthenet.com
And the orders table with the following data:
order_id customer_id order_date
1 7000 2016/04/18
2 5000 2016/04/18
3 8000 2016/04/19
4 4000 2016/04/20
5 NULL 2016/05/01
SELECT customers.customer_id, orders.order_id, orders.order_date
FROM customers
LEFT OUTER JOIN orders
ON customers.customer_id = orders.customer_id
ORDER BY customers.customer_id;
There will be 6 records selected. These are the results that you should see:
customer_id order_id order_date
4000 4 2016/04/20
5000 2 2016/04/18
6000 NULL NULL
7000 1 2016/04/18
8000 3 2016/04/19
9000 NULL NULL

→SQL RIGHT OUTER JOIN

SELECT columns
FROM table1
RIGHT [OUTER] JOIN table2
ON table1.column = table2.column;

Page | 7
 customer_id last_name first_name favorite_website
4000 Jackson Joe techonthenet.com
5000 Smith Jane digminecraft.com
6000 Ferguson Samantha bigactivities.com
7000 Reynolds Allen checkyourmath.com
8000 Anderson Paige NULL
9000 Johnson Derek techonthenet.com
And the orders table with the following data:
order_id customer_id order_date
1 7000 2016/04/18
2 5000 2016/04/18
3 8000 2016/04/19
4 4000 2016/04/20
5 NULL 2016/05/01
SELECT customers.customer_id, orders.order_id, orders.order_date
FROM customers
RIGHT OUTER JOIN orders
ON customers.customer_id = orders.customer_id
ORDER BY customers.customer_id;
There will be 5 records selected. These are the results that you should see:

customer_id order_id order_date

NULL 5 2016/05/01
4000 4 2016/04/20
5000 2 2016/04/18
7000 1 2016/04/18
8000 3 2016/04/19

→SQL FULL OUTER JOIN

SELECT columns
FROM table1
FULL [OUTER] JOIN table2
ON table1.column = table2.column;
customer_id last_name first_name favorite_website
4000 Jackson Joe techonthenet.com
5000 Smith Jane digminecraft.com
6000 Ferguson Samantha bigactivities.com
7000 Reynolds Allen checkyourmath.com

Page | 8
 customer_id last_name first_name favorite_website
8000 Anderson Paige NULL
9000 Johnson Derek techonthenet.com
And the orders table with the following data:
order_id customer_id order_date
1 7000 2016/04/18
2 5000 2016/04/18
3 8000 2016/04/19
4 4000 2016/04/20
5 NULL 2016/05/01

SELECT customers.customer_id, orders.order_id, orders.order_date

FROM customers
FULL OUTER JOIN orders
ON customers.customer_id = orders.customer_id
ORDER BY customers.customer_id;
There will be 7 records selected. These are the results that you should see:
customer_id order_id order_date
NULL 5 2016/05/01
4000 4 2016/04/20
5000 2 2016/04/18
6000 NULL NULL
7000 1 2016/04/18
8000 3 2016/04/19
9000 NULL NULL

9) What do you think of test leads writing test cases?

Ans. The right answer is to say that you feel that the test lead should write test cases like any other
member of the team.

10) How do you set your team’s objectives?

Ans. If you prefer to set individual objectives for each member of the team, mention that you set
them according to the knowledge and experience levels. This is how we can handle the project more
efficiently as a team.

11) What are the ways you ensure that the team members receive proper training?
Ans. Get feedback from all the team members on their strengths and weaknesses to make a note of
what type of training is necessary for the team. Also, new members who join the team should be
trained on time so as to be inducted as quickly as possible.

12) What will be your criteria for hiring team members? Ans. The criteria for hiring team members
are 1) his/her technical strength is as per project requirements, 2) his/her attitude towards the
profile he will be hiring for, and 3) will he/she be a good fit with the rest of the team members?

Page | 9
13) Name the different types of Test Plans?
Ans. There are three types of Test Plans: 1) Master Test Plan, 2) Testing Level Specific Test Plan and
3) Testing Type Specific Test Plan.

14) What are the good practices that you follow?

Ans. Some of the good practices for a successful project are proper documentation process, high
standards of reviewing, recognition of outstanding performers, focusing on team building, and
making sure there is a continuous scope of learning.

15) What are your key achievements in your current organization?

Ans. Have you completed a project well before the deadline or have you managed a difficult project
with great efficiency? Mention all your achievements no matter how insignificant you think it is.

16) Agile Vs Scrum?

Agile methodology is a practice that helps continuous iteration of development and testing in the
SDLC process. Agile breaks the product into smaller builds.
In this methodology, development and testing activities are concurrent, unlike other software
development methodologies. It also encourages teamwork and face-to-face communication.
Business, stakeholders, and developers and clients must work together to develop a product.
Agile is an approach or philosophy to project management that aims to achieve a goal in small
increments. So instead of having one large reveal or launch, an Agile project comprises smaller
chunks of tasks that can be delivered in shorter time frames continuously. This makes it easier for
project teams to adapt to changing priorities, respond to problems that arise, and cut down on cost,
time, and inefficiencies.

There are four values that drive the Agile philosophy of project management:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

When you should use Agile

Agile is well-suited for ongoing projects and projects where certain details aren’t clear from the
start. This makes Agile good for industries that deal with constant or unpredictable change, or teams
creating a new product. More traditional project management styles such as Waterfall might work
better for projects that have strict constraints—like a firm time or fixed budget—such as event
planning.

Scrum is an Agile methodology that is designed to develop products in an environment susceptible

to change. Scrum in Agile is a process that allows software development teams to focus on
delivering business values in shortest time by rapidly and repeatedly inspecting actual working
software. It focuses on accountability, teamwork and iterative progress towards well-defined goals.
Scrum Framework usually deals with fact that requirements are likely to change or mostly not known
at the beginning of project.

Scrum is built on three pillars:

• Transparency: All players involved have complete access to information, including progress
and goals.

Page | 10
 • Adaptation: The project and work can change to mirror new priorities.
• Inspection: The team strives to continuously improve the product and the process.

And five values:

• Courage
• Focus
• Commitment
• Respect
• Openness

KEY DIFFERENCE
• Agile is a continuous iteration of development and testing in the software development
process whereas Scrum is an Agile process to focus on delivering the business value in the
shortest time.
• Agile methodology delivers the software on a regular basis for feedback while Scrum delivers
the software after each sprint.
• In the Agile process, leadership plays a vital role; on the other hand, Scrum fosters a self-
organizing, cross-functional team.
• Agile involves collaborations and face-to-face interactions between the members of various
cross-functional teams whereas Scrum collaboration is achieved in daily stand up meetings.
• In Agile process design and execution should be kept simple whereas in Scrum process
design and execution can be innovative and experimental.

17) What are the key challenges of software testing?

Ans. This is one of the commonly asked Test Lead interview questions. Some of the key challenges
of software testing are:
Testing the entire application: It is difficult to test the entire application as there are many test
combinations. It will lead to a delay in shipping the product if you test all the combinations.
Communication with developers: Developers or testers may not always agree with each other on
some points.
Regression testing: Managing the changes in current functionality and previous working
functionality checks could be difficult.
Time constraint: You may have multiple tasks related to quality that need to be completed within a
specified time.
Priority: With time constraints, it sometimes becomes difficult for the testers to decide which test to
execute first.
Some other challenges include deciding on the right process and identifying the non-testable
requirements.

18) What steps are followed to create a test script?

Ans. Below are the steps to create a test script:
Understand the Application under test by reading the requirements related documents other
references, such as the previous version of the application.
Make a list of the areas to test for the AUT. In this step, you will identify ‘What’ to test.
Determine ‘How’ to test them. Write various steps on how to test a particular feature, determine
the data that will be entered, and the expected outcome.

19) What is PDCA Cycle?

Ans. This is one of the frequently asked test lead interview questions. PDCA stands for Plan Do
Check Act. The PDCA Cycle is a 4-stage problem-solving technique for conducting a quality check. It
focuses on the continuous improvement of processes and products. In simple terms, it is a

Page | 11
continuous loop of planning, doing, checking, and acting that is useful for testing improvement
measures.

20) What are the key elements in a Bug Report?

Ans. A good bug report must be concise and specific and should have:
• Title
• Unique and clearly specified bug number/name
• Steps to reproduce the bug
• A summary describing the defect and the observed failure
• A description that explains the steps to follow to reproduce the defect and the expected
outcome.
• Date and time when the defect occurred or reported
• Bug Priority / Severity
• Platform & Version
• Attachment/evidence of the failure to help the reviewer to understand the defect better

21) What is Exploratory Testing?

Ans. Often described as simultaneous learning, test design, and test execution, Exploratory Testing is
an approach that involves testing software without any specific plans or schedules. It is carried out
when there an early iteration is needed. It requires minimum planning and maximum test execution.
During software testing, the tester discovers and learns novel things that when combined with
experience and creativity produce new good tests to run.

22) What are the severity and priority of a defect?

Ans. Defect Severity means how adversely the defect has impacted the functionality of an
application.
Defect Priority refers to the order in which the defects will be fixed. It is the urgency of the defect
from the business point of view. If the impact of the bug will be higher on the business, then a higher
priority will be assigned to it. Bugs could be under different priority and severity combinations
High Priority and High Severity
High Priority and Low Severity
Low Priority and Low Severity
Low Priority and High Severity

23) How would you choose a Testing tool for your project?
Ans. The steps to select the right testing tool for a project are:
Identify and understand the requirement for the project
Evaluate the tools and vendors that meet the requirements
Consider budget and estimate cost and benefit
Make the final decision

24) What do you think is the best approach to start QA in a project?

Ans. The best approach to start QA is from the beginning of the project. This will help the team to do
proper planning of the processes that need to be followed. It will ensure that the end product meets
the customer’s quality expectations. QA also helps in starting communication between different
teams.

25) What are some of the software quality assurance best practices?
Ans. Below are some of the software quality assurance best practices:
• Continuous Improvement
• Two-Tier Test Automation Approach

Page | 12
 • Metrics
• Shared responsibilities
• Teamwork
• Run a regression cycle

26) What soft/people skills should a Test Lead/QA Manager have?

Ans. Besides technical expertise, Test Leads and QA managers must work on their ability to create
and work with a creative test team where each member is equally valuable for the organization. This
would require them to have the following soft skills:
• Effective communication skills
• Ability to solve problems effectively
• Adaptable and influential
• Strong negotiation and conflict resolution skills
• Ability to motivate team members
• Team Player

27) What are the different ways to manage or mitigate risks in a Test Project?
Ans. The following are the four ways to manage or mitigate the risk:
Avoidance: avoid the risk factor that is involved
Acceptance & Sharing: Accept the risk and develop a planned budget for the risks involved and
collaborate with others to share responsibility
Reduction: Develop a mitigation plan to decrease the impact of risks
Risk transfer: Transfer the risk to another resource or party

28) How can you determine the quality of the test execution?
Ans. You can determine the quality of test execution by:
Defect rejection ratio: (No. of defects rejected/ total no. of defects raised) X 100
Defect leakage ratio: (No. of defect missed/total defects of software) X 100
A smaller value of DRR and DLR indicates a better quality of test execution.

29) What are the best practices for test estimation?

Ans. This is one of the frequently asked Test Lead interview questions.
The following are some of the best practices for test estimation:
• Add reasonable buffer time: It can help you to deal with a delay caused due to unexpected
reasons.
• Account resource planning in estimation: Make a realistic estimation after considering the
important factors, like the absence of a human resource.
• Use the past experience reference: It will help you to prepare good estimates and avoid all
the possible obstacles that are most likely to happen.
• Stick to your estimate: Your estimation may go wrong also. Therefore, you should re-check
and make modifications when needed.

30) What is the difference between Assert and Verify commands in test automation?
Ans. Both Assert and Verify commands are used to check if the code conditions are true. The
difference is what happens next. There are some differences between Assert and Verify:
If the Assert condition is true then the program control will execute the next test step. If the
command fails, the execution will stop and further test steps will not be executed. There are two
types of assets, namely Hard and Soft Asserts.
When a Verify command fails, the test will continue executing the rest of the code and logging the
failure. The Verify command is used to check non-critical things.

Page | 13
31) What is the difference between Beta and Pilot Testing?
Ans. The differences between Beta and Pilot testing are:
Beta Testing
Beta testing is done when the project is about to release. The application is given to the end-users to
check whether the application meets the user’s requirements or not. It is done before the final
release when the development and testing are essentially completed. The Beta version is released to
a limited number of end-users to obtain feedback on the product quality. The purpose of Beta
testing is to identify defects and improve the quality of the application.
Pilot Testing
It is the real-world testing that is performed by a group of end-users before an application’s full
deployment. A group of users uses the application in totality before the final launch. The purpose of
Pilot testing is to evaluate the feasibility, time, cost, risk, and performance of the project.

32) What is Bug triage?

Ans. Bug triage refers to the process of prioritizing each bug based on its severity, frequency, and
risk. The QA team validates the severities of the bug, makes the required changes, finalizes the
resolution of the bugs, and assigns resources.
Defect/Bug Triage Process:
• Defect Review
• Assessment
• Assignment

33) What is the difference between Verification and Validation?

Ans. Verification involves checking if the software achieves its goal without any bugs. On the other
hand, Validation checks if the software product is up to the mark. Below are some of the major
differences between Verification and Validation.

Verification Validation
Verification evaluates the steps during the development Validation evaluates the product after the development
phase and determines if they meet the user requirements. process to determine if it meets the specified
requirements.
Verification is performed before validation. Validation is performed after verification.
It includes checking documents, design, code, and It tests and validates the actual product
program.
Verification does not involve executing the code. Validation involves executing the code.
Verification used methods, such as reviews, walkthroughs, Validation includes methods such as black-box testing,
inspections, and desk checking. white box testing, and non-functional testing.
It finds the bugs before the development cycle. It finds the bugs after the development cycle – the bugs
that the verification process could not detect.
Verification conforms to the requirements specified in the Validation checks whether it meets the specified
SRS document. requirements or not.
Its focus is on – Are we building the product right? Its focus is on – Are we building the right product?

34) Defect Density Formula?

Defect Density is the number of defects confirmed in software/module during a specific period
of operation or development divided by the size of the software/module. It enables one to decide if
a piece of software is ready to be released.

Page | 14
Defect density is counted per thousand lines of code also known as KLOC.

How to calculate Defect Density

A formula to measure Defect Density:

Defect Density = Defect count/size of the release

Size of release can be measured in terms of a line of code (LoC).

Factors that affect the defect density metrics

• Code complexity
• The type of defects taken into account for the calculation
• Time duration which is considered for Defect density calculation
• Developer or Tester skills

Advantages of defect density

• It helps to measure the testing effectiveness

• It helps to differentiate defects in components/software modules
• It is useful in identifying the areas for correction or improvement
• It is useful in pointing towards high-risk components
• It helps in identifying the training needs to various resources
• It can be helpful in estimating the testing and rework due to bugs
• It can estimate the remaining defects in the software
• Before the release, we can determine whether our testing is sufficient
• We can ensure a database with a standard defect density

35) Rules for Method overriding?

• Only inherited methods can be overridden.

• Final and static methods cannot be overridden.
• The overriding method must have same argument list.
• The overriding method must have same return type (or subtype).
• The overriding method must not have more restrictive access modifier.
• Use the super keyword to invoke the overridden method from a subclass.
•
• If the overridden method is has default access, then the overriding one must be
default, protected or public.
• If the overridden method is protected, then the overriding one must be protected or public.
• If the overridden method is public, then the overriding one must be only public.

36) What will happen if we use both implicit wait and explicit wait?

As per the official Selenium documentation, it is suggested not to mix both Implicit waits and Explicit
Waits. Mixing both of them can cause unpredictable wait times.

Implicit wait is defined only once in the code. It will remain same throughout the driver object
instance.

Page | 15
Explicit wait is defined whenever it is necessary in the code. This wait will call at the time of
execution. It is a conditional wait.
Explicit wait will override the implicit wait wherever explicit wait is applied. So, Explicit Wait gets first
preference then Implicit Wait.

37) Automatically Re-Running Failed Scenarios in Cucumber- Junit ?

Step 1: In Runner File inside plugin we need to write “rerun:rerun/failed_scenarios.txt”. Cucumber

will write the failed scenario and line number in the generated failed_scenarios.txt file.

import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
features = {"C:\\Users\\ankur.jain\\eclipse-workspace\\Cucumber_Test\\src\\main\\java\\
com\\qa\\FeatuerFile\\Login.feature",
}, //the path of the feature files
//format= {"html:target/site/cucumber-pretty;json:target/cucumber.json&quot"},

glue={"com.qa.StepDefinition"}, //the path of the step definition files

plugin= {"pretty","html:target/site/cucmber-pretty", "json:target/cucumber/cucumber.json",
"rerun:rerun/failed_scenarios.txt"}, //to generate different types of reporting
monochrome = true, //display the console output in a proper readable format
strict = true, //it will check if any step is not defined in step definition file
dryRun = false//to check the mapping is proper between feature file and step def file

//tags = {"@all"}
)

public class TestRunner

{

}
Step 2: We Need to Create another Runner File. Let’s Name it as ReRunRunner.Java and inside
feature we need to provide the name of this failed_scenario.txt file along with @.

features = {"@rerun/failed_scenarios.txt",

},

Now once any of our scenarios will get failed this failed_scenarios.txt the file will be generated inside
the rerun folder with failed feature file name and using the ReRunner.Java file created in Step 2 we
can easily rerun our failed scenario in Cucumber-Junit.

Page | 16
Dry-run is used to compile feature files and step definitions in cucumber. It is specially used in the
stage when you will have to see if there are any compilation errors, to check that you can use dry-
run. Dry-run options can either set as true or false. If it is set to true, it will mean that Cucumber
checks every Step mentioned in the Feature File have corresponding code written in Step Definition
file or not. So, if in any case any of the functions are missed in the Step Definition for any Step in
Feature File, it will give us the message.

38 ) Cucumber Tags?

Let's say you have got many different feature files that cover all the different functionality of the
application. Now there can be a certain situation in the project where you like to execute just
a SmokeTests or End2EndTests or may be RegressionTests. One approach is that you start creating
new feature files with the name of the type like SmokeTests.features or End2EndTests.feature and
copy-paste your existing tests in the same. But this would make the project filthy and would require
more maintenance in future. So how to manage execution in such cases?

For this, Cucumber has already provided a way to organize your scenario execution by using tags in
feature file. We can define each scenario with a useful tag. Later, in the runner file, we can decide
which specific tag (and so as the scenario(s)) we want Cucumber to execute. Tag starts with “@”.
After “@” you can have any relevant text to define your tag like @SmokeTests just above the
scenarios you like to mark. Then to target these tagged scenarios just specify the tags names in
the CucumberOptions as tags = {"@SmokeTests"}.

Tagging not just specifically works with Scenarios, it also works with Features. Means you can also
tag your features files. Any tag that exists on a Feature will be inherited by Scenario, Scenario
Outline or Examples.

Things to Note:

• Few scenarios are part of the Smoke Test, Regression Test, and End2End Test.

Page | 17
 • Few scenarios are part of two or more Test Types. For example, the first test is considered as
Smoke as well as Regression.
• Few scenarios are not at all tagged
• The last scenario of Payment Declined, it is a single scenario but has five different test data.
So this will be considered as five different scenarios.

Running single Cucumber Feature file or single Cucumber Tag

Execute all tests tagged as @SmokeTests

Note: In the excel sheet and in the feature file paste above if you count the scenarios which are
tagged as @SmokeTests, you will find the count is 6 and the same count is also displayed under Junit
tab.

Logically ANDing and ORing Tags

Requirements are complicated, it will not always simple like executing a single tag. It can be
complicated like executing scenarios that are tagged either as @SmokeTest or @RegressionTest. It
can also be like executing scenarios that are tagged both as @SmokeTest and @RegressionTest.
Cucumber tagging gives us the capability to choose what we want with the help
of ANDing and ORing.

Execute all tests tagged as @SmokeTest OR @RegressionTest

Tags that are comma-separated are ORed.

Note: OR means scenarios that are tagged either as @SmokeTest OR @RegressionTest.

Execute all tests tagged as @SmokeTest AND @RegressionTest
Tags which are passed in separate quotes are ANDed

Page | 18
How to Ignore Cucumber Tests
This is again a good feature of Cucumber Tags that you can even skip tests in the group execution.
Special Character ~ is used to skip the tags. This also works both for Scenarios and Features. And this
can also works in conjunction with AND or OR.

Execute all tests of the feature tagged as @FunctionalTests but skip scenarios tagged as
@SmokeTest

Note: This is AND condition, which means all the scenarios tagged as @FunctionalTest but not
@SmokeTest. So total tests are 15 and smoke tests are 6, so it ran just 9 tests.

Execute all tests which are not at all tagged in all the Features

Page | 19
39) Invocation count is used when you want to run the same tests multiple times. Below example
illustrates how to use invocation count in TestNG. In below example, test1 will be executed 5 times.
We have also used threadPoolSize parameter with value as 2. It means that 2 threads will be created
to run the test in parallel.

40) Parallel execution using Cucumber?

Cucumber supports parallelism with both JUnit and TestNG. There is a difference between them and
its a major one.
JUnit
In JUnit, only the feature files run in parallel rather than the scenarios themself. So basically, all the
scenarios in a single feature file will be executed by the same single thread. As a test runner, we can
either use Maven Surefire or Failsafe plugin. Add Surefire plugin configuration to the build section
of the POM.
TestNG
Execution of cucumber scenarios and the rows in scenario outlines is absolutely possible
with TestNG. This can be achieved by setting up the dataprovider parallel option as true and
extending the runner class with AbstractTestNGCucumberTests from io.cucumber.testng

TEST Lead Questions?

Q1. What does a test lead do?
Ans. A Test Lead leads a team of testers to meet the product goals to achieve the organizational
goals. A Test Lead must show good leadership qualities along with proficiency in the technical areas
of work.
Q2. What does a Quality Manager do?
Ans. A Quality Manager ensures that the quality of products, services, or processes of an
organization are properly maintained and meet the customer’s requirements.
Q3. What soft skills should a Test Lead or a QA Manager have?
Ans. In addition to technical expertise, Test Leads and QA managers should have the following soft
skills: Effective communication skills, Problem-solving skills, Adaptability, Strong negotiation and
conflict resolution skills, Ability to motivate team members, and Team Player.
Q4. What are the responsibilities of a Test Lead?
Ans. The responsibilities of a Test Lead are: Defining the testing activities, Test planning,
Determining if the team has all the necessary resources, Preparing the status report and progress
report of testing activities, Communicating with customers, Providing testing guidance to product
teams, Following up on all pending testing.
Q5. What makes a good Test Lead or QA Manager?
Ans. Test Leads and QA managers must work on their ability to build and work with a creative test
team where each member is equally valuable for the organization. Therefore, in addition to
technical expertise, they must also have people skills, such as effective communication skills,
adaptability, listening skills, and negotiation skills.

Page | 20
Page | 21
Page | 22