 WBS

Tell me about yourself :

I am _Narmadha , I have more than 15 years of experience in various industry , but in testing I have
more than 12 & yrs of exp.,. Baiscally I have started my career as Support Executive then I have moved
on to software testing. In testing industry. I am currently working as a Module Lead in Mphasis for
more than 11 yrs. I have recently joined into new project , so I will explain the roles of my previous
project . I was working in security complainace domain. My roles & responsibilities are as a TL , i

I managed 5 members of team.

As a test lead I inovled from Req gathering till the closure of the [Link] KT on req to team, &
gather the queries raised by team & get it clarified by client. If needed will prepare Analysis
presentation document with prototype.

I involved in test plan , test strategy , test estimation , test case design , test case execution , defect
reporting , defect analyzing , test summary report ,release notification, metrics report ,daily , weekly
& monthly report.

Involved in review activites like test case review, defect review. Involved in release activities .

I have a very good strong relationship with client.

Training the new team members . Involved in scrum meeting &discuss about the user stories &
estimate time to finish the user stories.

I involved in COB meetings

Professional Interview Introduction (Strong & Balanced Version)

“Hi, I’m Narmadha Shankaran. I have over 15 years of experience in Quality

Assurance. In my 15 years of exp I worked in various doamins like Life
Sciences, Insurance, HR,Retail and Energy domains. For the last few years,
I’ve been working as a QA Lead at SAAMA Technologies, where I handled
regulatory clinical platforms aligned with 21 CFR Part 11, GxP, and CSV
standards.

My role involved defining test strategies, managing offshore QA teams,

ensuring compliance documentation, driving CAPA and RCA processes, and
supporting audit readiness. I’ve worked closely with clients like Pfizer, and I
was recognized as a Quality Champion for program delivery.

I am a Software Tester with experience in Computer System Validation (CSV) and validation testing in
healthcare and GxP systems.
In my current project, I am working on validating applications by preparing documents like User
Requirement Specification (URS), test cases, and Traceability Matrix (RTM). I ensure that all
requirements are covered and tested properly.

I perform validation activities such as Installation Qualification (IQ), Operational Qualification (OQ),
and Performance Qualification (PQ) to make sure the system is installed correctly, works as expected,
and performs well in real-time scenarios.

I follow guidelines from GAMP 5 for risk-based testing, where I focus more on high-risk areas like
patient data, audit trails, and security. I also ensure compliance with FDA 21 CFR Part 11 by validating
audit trails, electronic signatures, and data integrity. Additionally, I maintain proper documentation as
per ISO 13485.

Overall, I see myself as a quality-focused leader who combines governance,

process discipline, and evolving automation skills to deliver reliable and
compliant releases.” Personal break.

Technically, I have strong hands-on experience in functional testing,

regression, UAT, and database validation using SQL. Currently, I’m
expanding my expertise in automation by working with Python and
Playwright, and I also have foundational exposure to Selenium and
JavaScript. My goal is to integrate automation into compliance-driven QA
practices and improve efficiency while maintaining regulatory standards.

RTM:

The Traceability Matrix (RTM) is very important in testing and

compliance, especially in regulated domains like life sciences.

RTM links requirements → test cases → defects So you can make sure
nothing is missed

RTM ensures that all requirements are properly tested, tracked, and
validated, providing complete coverage and supporting audit compliance.

ENV:

“I prefer a collaborative and structured work environment where communication is clear and
expectations are well defined.
I like working in a team where QA, developers, and business stakeholders work closely
together, so issues can be identified and resolved early.

I also value an environment that follows proper processes and compliance standards,
especially in regulated domains, to ensure high-quality delivery.

Also of course I expect the env which encourage ownership , learning & dev

Agile Methodology:

Agile testing can begin at start of the project with continuous integration b/w dev & testing.

In Agile testing , we divide the release into sprints. Every sprints has a timeline of 2 weeks or
[Link] time line gernerly agreed by scrum team during sprint plang meeting .

A user story is an informal, general explanation of a software feature written from the
perspective of the end user or customer.

There are 3 roles :

Product owner : who sits with client and gather the req., & create epic . epic is whole feature of the
product or large stories. He act as spoc from client side. Product backlog is a prioritized list of work for
the team that is deriver from req

Scrum master :

Who act as facilitator for scrm team. Who conducts daily meetings & coordinate to the team members.

Scrum team : all the people who works on particular sprint.

Sprint backlog : which contains list of tasks identified by the team to be completed . It contains user
stories & tasks prepared by scrm master.

3 meetings :

Stand up meeting , sprint planning (stories move to current sprint from backlog ) & estimate the
stories .& retrospective meeting .

Burn-up charts represent how much work has been completed in a

project whereas Burn-down chart represents the remaining work left in
a project.
TEST PLAN :
A document that gives a detailed plan for the testing process. Test Plan is a document it describes
overall testing activity for that Project. This document prepared by TestLead or [Link]

Total number of features to be tested , Testing strategies / approaches to be followed

The testing methodologies ,Resources required for the whole testing process – Environment

Test Schedule , The testing tools that are to be used

Reference to test cases Defect Tracking System

Requirements tracability User Acceptance Plan Entry-Exit criteria

Test Strategy is part of test plan A Test Strategy is a formal description of how a software product will be
tested. Test stategy explains what are all the kind of testings that should be done.

Test Strategy describes the general approach and objectives of the test activities.

o Name of the project Brief description of the project

o Type of the project(Fresh development/Produce) Type of software

o Levels of testing o Critical Success factors(Delivery on time, Reasonable response time)

o Risk factors(May not work in 95,Developers are new)---Impact the time line

o Trade-Off(Delivery on time)

Metrics
Software Testing Metrics are the quantitative measures used to estimate the
progress, quality, productivity and health of the software testing process. The goal
of software testing metrics is to improve the efficiency and effectiveness in the
software testing process and to help make better decisions for further testing
process by providing reliable data about the testing process
API :
It is an interface which enables the communication & data exchange between two
separate s/w systems.

✅ What is Postman?

Answer:
Postman is a tool used to test API
s. We can send requests (GET, POST, etc.) and check the response without
using UI.

✅ What is Rest Assured?

Answer:
Rest Assured is a Java library used to automate API testing. It helps us write
code to test APIs.

✅ Difference between Postman and Rest Assured?

Answer:

 Postman → Manual + basic automation (easy to use)

 Rest Assured → Full automation using Java (used in frameworks)

✅ What is API?

Answer:
API is a way for two systems to communicate with each other.

✅ What are HTTP methods?

Answer:

 GET → Get data

 POST → Create data

 PUT → Update data

  DELETE → Delete data

🔹 2. Postman Questions with Answers

✅ What is Collection?

Answer:
Collection is a group of API requests stored together.

✅ What is Environment?

Answer:
Environment is used to store variables like URL, token for different setups
(Dev, QA, Prod).

✅ Types of variables in Postman?

Answer:

 Global → used everywhere

 Environment → used per environment

 Collection → used inside collection

✅ What is Pre-request script?

Answer:
Code that runs before sending request (example: generate token).

✅ What is Test script?

Answer:
Code that runs after response to validate results.
✅ How to check status code?

Answer:

[Link](200);

✅ How to store and reuse value?

Answer:

[Link]("token", [Link]().token);

✅ What is Newman?

Answer:
Newman is a command-line tool to run Postman collections. It is used in
CI/CD pipelines.

CI/CD:

4️⃣ What is the role of a tester in CI/CD?

Answer:

 Design and maintain automated test scripts

 Integrate tests into the CI/CD pipeline

 Analyze test failures

 Ensure quality before release

5️⃣ Why is automation important in CI/CD?

Answer:
Automation provides fast feedback, reduces manual effort, and ensures
consistent testing for every build.
6️⃣ What types of tests should be included in a CI/CD pipeline?

Answer:

 Smoke tests
 Regression tests

 API tests
(UI tests should be minimal as they are slower)

🔹 Practical Questions

7️⃣ What will you do if a build fails?

Answer:

 Check logs and error messages

 Identify whether it is a code issue or test issue

 Coordinate with developers to fix it

8️⃣ How do you analyze test failures?

Answer:

 Review logs, screenshots, and reports

 Check if it is a script issue or application bug

 Re-run tests if needed to confirm

9️⃣ What are the common stages in a CI/CD pipeline?

Answer:

 Build
 Test

 Deploy
 🔹 Tools-Based Questions

🔟 Which CI/CD tools are you familiar with?

Answer:

 Jenkins
 GitHub Actions

 GitLab CI

1️⃣1️⃣ Which automation tools have you used?

Answer:

 UI Testing: Playwright / Selenium

 API Testing: Postman / RestAssured

🔹 Scenario-Based Questions

1️⃣2️⃣ What will you do if a bug is found in production?

Answer:

 Perform root cause analysis

 Identify missing test coverage

 Add test cases to prevent future issues

 Update the CI/CD pipeline

1️⃣3️⃣ How will you handle slow pipelines?

Answer:

 Optimize test cases

 Run tests in parallel
  Remove unnecessary tests

1️⃣4️⃣ What are flaky tests and how do you handle them?

Answer:
Flaky tests are tests that give inconsistent results.
They can be handled by improving test stability, using proper waits, and
fixing timing issues.

🔹 Advanced Questions (QA Lead Level)

1️⃣5️⃣ How do you ensure quality in a CI/CD pipeline?

Answer:

 Strong automation framework

 Good test coverage

 Proper test strategy

 Continuous monitoring and feedback

1️⃣6️⃣ What is Shift Left Testing?

Answer:
Shift Left Testing means starting testing early in the development lifecycle,
even from the requirement phase.

🌟 Final Interview Tip

If you want to impress:

👉 Say this clearly:

“I focus on integrating automation into CI/CD pipelines and ensuring quick

feedback on every build.”
85. Quality Control:

It is the process the product is compared with the requirements and identifies the defects. Goal of QC is
to find the errors. he main purpose of the quality control process is ensuring that the
software product meets the actual requirements by testing and reviewing its
functional and non-functional requirements.
86. Quality Assurance:

The set of activities to provide confidence that product is as per the specified requirement and meet
user [Link] prevent the errors in the program.

Software QA involves the entire software development PROCESS - monitoring and improving the
process, making sure that any agreed-upon standards and procedures are followed, and ensuring that
problems are found and dealt with. It is oriented to 'prevention'

QA & QC
Quality Assurance Quality Control

 QC aims to identify and fix defects

 QA aims to prevent the defect

An activity that establishes and evaluates the processes to An activity which verifies if the product meets pre-
produce the products. defined standards.

 It’s a Corrective technique

 It’s a Preventive technique

Verifies if specific attribute(s) are in a specific product or
Sets up measurements programs to evaluate processes.
service

Identifies defects for the primary purpose of correcting

Identifies weaknesses in processes and improves them.
defects.

QA is the responsibility of the entire team. QC is the responsibility of the tester.

Prevents the introduction of issues or defects Detects, reports and corrects defects

QA evaluates whether or not quality control is working for the QC evaluates if the application is working for the primary
primary purpose of determining whether or not there is a purpose of determining if there is a flaw / defect in the
weakness in the process. functionalities.

QA improves the process that is applied to multiple products

QC improves the development of a specific product or service.
that will ever be produced by a process.

QA personnel should not perform quality control unless doing QC personnel may perform quality assurance tasks if and
it to validate quality control is working. when required.
4. Ad hoc Testing:

Testing an application without following any rules or test cases.

For ad hoc testing one should have strong knowledge about the application.

Ad hoc Testing is an informal or unstructured software testing type that aims to

break the testing process in order to find possible defects or errors at an early
possible stage. Ad hoc testing is done randomly and it is usually an unplanned
activity which does not follow any documentation and test design techniques to
create test cases.

5. UAT-User Acceptance Testing:

It s done by the end user/customer to check whether the software met their requirements

8. Sanity Testing & Smoke Testing:

Sanity Testing:
Sanity testing is used to test in initial checkup is made on the build after receiving from developer.

Smoke Testing

In this we test that application is able for the further testing or not. We just check the capability of the
application for testing.

Sanity testing is a kind of Software Testing performed after receiving a software

build, with minor changes in code, or functionality, to ascertain that the bugs have
been fixed and no further issues are introduced due to these changes
Following is the difference between Sanity and Smoke testing:

Smoke Testing Sanity Testing

Sanity Testing is done to check the new functionality/bugs

Smoke Testing is performed to ascertain that the
critical functionalities of the program is working fine have been fixed

The objective of this testing is to verify the “stability” The objective of the testing is to verify the “rationality” of
of the system in order to proceed with more rigorous
testing the system in order to proceed with more rigorous testing

This testing is performed by the developers or testers Sanity testing in software testing is usually performed by testers

Smoke testing is usually documented or scripted Sanity testing is usually not documented and is unscripted
Smoke testing is a subset of Acceptance testing Sanity testing is a subset of Regression Testing

Smoke testing exercises the entire system from end to Sanity testing exercises only the particular component
end of the entire system

Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up

9. . Unit Testing:

Unit testing is done to check whether the individual modules of the source code are working properly.
Ie:- Testing each & every unit of the application separately by the developers in developers
environment.

10. Interface Testing:

Interface Testing is done to check whether the individual modules are communicating properly one
among other as per the specifications.

It is mostly used in testing the user interface of GUI applications.

14. Test Bed:

In software, the hardware and software requirements are known as the test bed. This is also known as
the test environment

15. Test Environment:

It is the s/w & h/w environment where the testing is going to be done.

16. Walkthrough & Inspections:

Walkthrough is an informal meeting....it helps to analyzing the coding techniques & if the code meets
the coding standards
Inspection is formal analysis of the program source code to find defects as defined by* meeting
design spec

22. What is Trigger? How to check a trigger is fired or not, while doing database testing?

Triggers are special kind of stored procedures that get executed automatically
When an INSERT, UPDATE or DELETE operation takes place on a table.

It can be verified by querying the common audit log where we can able to see the triggers fired.
24. Joins:

Data collected from one or more tables.

Tables in a database are often related to each other with keys.

A primary key is a column (or a combination of columns) with a unique value for each row. Each primary
key value must be unique within the table. The purpose is to bind data together, across tables, without
repeating all of the data in every table.

Types of joins:
z`
1. Inner join /natural join/equi – join
2. Outer join
a. Left join or Left outer join
b. Right join or Right outer join
c. Full join or Full outer join
3. Cross join
4. Self join

1. Inner join /natural join/equi – join:

Return rows when there is at least one match in both tables.

SELECT column _name(s)

FROM table_name1
INNER JOIN table_name2
ON table_name1.column_name=table_name2.column_name

Equi-join-Using = symbol in syntax

2. Outer Join:
a. LEFT JOIN: Return all rows from the left table, even if there are no matches in the right table

Ex: SELECT column_name(s)

FROM table_name1
LEFT JOIN table_name2
ON table_name1.column_name=table_name2.column_name

b. RIGHT JOIN: Return all rows from the right table, even if there are no matches in the left
table

Ex: SELECT column_name(s)

FROM table_name1
RIGHT JOIN table_name2
ON table_name1.column_name=table_name2.column_name
 FULL JOIN: Return rows when there is a match in one of the tables

Ex: SELECT column_name(s)

FROM table_name1
FULL JOIN table_name2
ON table_name1.column_name=table_name2.column_name

3. Cross join:

Cross joins return all rows from the left table; each row from the left table is combined with all
rows from the right table. Cross joins are also called Cartesian products.

4. Self Join:

A table can be joined to itself in a self – join.

Select [Link] from Empmaster A, Empmaster B where [Link]=[Link]

25. Primary Key:

The PRIMARY KEY constraint uniquely identifies each record in a database table. Primary keys must
contain unique values. A primary key column cannot contain NULL values. Each table should have a
primary key, and each table can have only one primary key.

26. Foreign Key:

FOREIGN KEY in one table points to a PRIMARY KEY in another table.

27. Union:

The SQL UNION operator combines two or more SELECT statements.

28. Difference between Trigger and Stored Procedure?

Trigger will get execute automatically when an UPDATE, INSERT, or

DELETE statement is issued against a table or view.
We have to call stored procedure manually, or it can execute automatic when the SQL Server starts

30. Difference b/w Test Case & Test scenario:

Test Scenario is nothing but the scenario which you are

going to test.
Test case is derived from Test Scenario only. For Requirements you write
test scenario and ultimately for test scenario you write Test cases.
For ex.
Requirement
1. create login page for web application
Scenario
1. check valid user id and invalid password
2. check invalid userid and valid passowrd

Test cases
1. Enter "ABC' as user ID
2. Enter "something" as password

31. Test Summary report:

Test summary report gives the status of Testing

1. Total number of test cases

2. Total number of bugs found
3. Number of bugs resolved (fixed)
4. Number of Bugs rejected
5. Total number of bugs deffered......etc
32. Static & Dynamic Testing:

Static Testing means Testing the application without executing the code...like GUI Testing-Verification
activity

Dynamic means Testing the application after executing the code-like application testing—Validation
activity

[Link] Complexity:

It's used to measure the complexcity of the software

process.

It's used to measure the [Link] test cases are used

to test the app in all posible ways.

35. Exploratory Testing , Ad hoc Testing:

Exploratory testing is informal testing tht is not based on any formal Testplans,Testcases.

Basically exploratory testing is testing the application with having proper requirement.
 Ad hoc is informal testing tht is not based on any formal Testplans,[Link] can learn the
application & test it.

Adhoc Testing is a type of testing in which the Test Engineer will perform the testing on the
application in his own style after understanding the requirements...

Exploratory testing – often taken to mean a creative , informal software test that is not based on
formal test plans or test cases ; testers may be learning the software as they test it . ad-hoc testing –
similar to exploratory testing , but often taken to meant that the testers have significant
understanding of the software before testing it.

36. Testing Process:

TestPlan,

TestCase,

TestExecution-(Smoke Test, Integration Testing, System Testing, Regression [Link]

Testing),

TestReports-(TestExecutionreport),

Test Analysis(Bug Analysis report

38. CMMI:

CMMI- Capability Maturity Model

It is a process improvement maturity model for the development of products and services.

CMMI provides a structural view of process improvement across an organization provide guidance for
quality process.

39. Smoke Testing:

It is done to test the major functionality and to check whether the testing can be continued without any
major showstopper

40. Test Case:

Test case is a document that describes a Condition, Test Steps and its expected result in order to
determine if a feature of an appln is working correctly.
A Test Case is a document that describes step-by-step process how to test the application

It contains:

 Test case id
 Test case condition
 Test Steps
 Expected Results
 Actual Results
 Test Results

41. Deferred Bug:

Deferred Bug is nothing but a bug found by the tester but the developer is agreed to fix in the next
release but not in the current release.

Testing Types

42. Testing Techniques:

A. White Box Testing

B. Black Box Testing

White Box Testing:

Testing the coding [Link] on knowledge of internal logic of an application code.

Tests are based on coverage of code statements, branches, paths and conditions.

Black Box Testing:

Based on requirements functionality. Not based on any knowledge of any coding part.

3 Techniques:

a. Equivalence Partitioning:

Testing the program within a given particular range.

For ex:

Range is (10,000 to 15,000):

Less than 10,000
B/w 10,000 To 15,000
Greater than 15,000
 b. Boundary Value Analysis:

it is a technique to find whether the application is accepting the expected range of values and rejecting
the values which falls out of range

Low Boundary plus or minus one

9999 and 10,001

On the boundary

10,000and 15,000

Upper boundary plus or minus one

14,999 and 15,001

c. Error Guessing:

Error guessing based in experience of the Test engineer.

Ex: Feb 29, 2009

43. Regression Testing:

Testing whether the issue is fixed and also test whether the fix does not create any problem in the
existing functionalities or in the application.

Retesting:

Retesting means to check whether the bug is fixed or not.

Regression testing types:

Unit Regression:

Testing of a single program after a change has been made.

Regional Regression:

Testing the modules connected to the program after the changes has been made.

Full Regression:

Testing the entire application after a change has been made.

44. Integration Testing:

Testing of combined modules of an application to determine if they function together correctly.

a. Bottom Up Integration:

All the modules are added or combined from lower level hierarchy to higher level hierarchy.

The lower model is tested first, and then the next sets of higher level modules are tested.

b. Top down Integration:

45. System Testing:

Testing of an entire application. Purpose of system testing is to validate an application’s

accuracy and completeness in performing the functions as designed.

It covers:
1. Recovery Testing
2. Security Testing
3. Stress Testing
4. Performance Testing

46. Recovery Testing:

Testing how well a system recovers from crashes, h/w failures, any back-up, restoration and restart
capabilities are also tested

47. Security Testing:

Testing how well the system protects against unauthorized internal or external access.

48. Stress Testing:

To check the performance of an application based on increasing number of resources.

Testing conduct when Heavy repetition of certain actions, large complex queries, Input of large
numerical value.

49. Performance Testing:

To check whether our application is giving response within expected time or not.

Testing of the application for the performance at stipulated times and stipulated number of users.
The performance of the system is determined by using Load / Stress / Volume Testing.
Ensure that the product response time meet the user expectations, response time will be tested under
heavy stress / volume.

50. Load Testing:

Testing an application under heavy loads to determine at what point system response time will degrade
or fail. Maximum number of users a system can support.

51. Comparison Testing:

Comparing software weakness and strengths to competing products.

52. Compatibility Testing:

Testing how well software performs in a particular h/w, s/w, o/s, browsernw etc…environment

53. Alpha Testing:

Testing of an application when development is nearing completion.

Testing of a s/w product or system conducted at the developer’s site by the customer.

54. Beta Testing:

Beta testing is the testing in which the development is complete except for the small issues and is done
in the clients place.

Testing conducted by the client.

 Alpha Testing – It is a type of software testing performed to identify

bugs before releasing the product to real users or to the public. Alpha
Testing is a type of user acceptance testing.
 Beta Testing – It is performed by real users of the software
application in a real environment. Beta Testing is also a type of user
acceptance testing.

55. Verification:

The Verification process is to check whether the s/w is per the specifications.

Built the system right

It contains:

Requirements review, Design Review, Walkthrough, Inspection

56. Validation:

Validation process is to check whether the customer is satisfied with the product.

Built the right system

It involves:

Unit Testing, Integration Testing, System Testing, Performance Testing, Alpha testing, Beta Testing, UAT
and Installation Testing.

57. Severity:

The degree to which it affects the application. How serious it is?

Serious of bugs.

Levels:

S1- Critical – Functionality block. Application is not able to proceed further.

S2- High- The application is not working as desired. There are variations in the functionality.

S3 – Medium - There is no failure reported due to the defect, but certainly needs to be rectified.

S4- Low/ Cosmetic- Defects in the User Interface or Navigation

S5- Suggestion- Feature which can be added for betterment.

Priority:

Importance of the defect whether the defect has to be repaired immediately or whether the repair can
be postponed.

Importance of the bugs

Levels:

P1 –Critical Immediate-Resolve the defect with immediate effect.

P2- Major At the earliest- Resolve the defect on the second priority level

P3- Minor Normal- Resolve the defect

P4-Cosmetic Later-Could be resolved at the later stages.

Low severity & Low priority – Spelling mistake

High severity & high priority – functionality block

High severity & low priority – any url which shows at bottom of the page

Low severity & high priority – company logo error

58. Installation Testing:

Testing of the computer system during the installation at the userplace.

59. Usability Testing:

Testing whether the product is user friendly or not.

60. Test Schedule:

It is a schedule of all test activities and resource requirements.

61. Test Log:

Pass or fail results is entered in Test log.

62. When do you do Acceptance Testing?

After system testing

63. Testing Levels:

1. Unit Testing

2. Integration Testing

3. System Testing

4. Acceptance Testing

66. Build:

The coding done based on requirements when release for Testing.

67. Penetration Testing:

Penetration testing is a method evaluating the security of the system or n/w

Ex: URL copy

68. Defect Leakage:

A bug or defect that is overlooked by the tester while testing a particular release.

69. TFS- Team foundation Server:

3 tier architecture:

1. Application server
2. Web server
3. Database server

70. Functionality Testing:

Testing the functionality of the application and to check whether the application is as per the
requirements.

73. Defect Tracking Process:

a. Execute the test case and compare the actual results to the documented expected results.

If any discrepancy exists, assign the discrepancy with status as “Open”

Assign the defect and send it to developer for correction.

[Link] the defect is corrected, the developer will usually enter a description and update the defect
status to “Fixed” and send it to the test team for retesting.

Regression Testing is performed as needed based on the severity and impact of the fix applied.

c. If the retest results match the expected results, the defect status is updated to “closed”
d. If any discrepancy exist against the status is changed to “Reopen” and sent back to the
developer.
e. This process should be repeated until the problem is resolved.

76. End- to – End Testing:

Similar to system testing, end-to-end testing involves testing of a complete application in an

environment such as interaction with a database using n/w communications, or interacting with other
n/w

77. Debugging:

Debugging is the method of finding and rectifying the cause of s/w failures.

80. Structural Testing:

It is a “White-Box” Testing and based on the algorithm or code.

82. Entry Criteria /Exit Criteria:

Entry Criteria:
 These are predefined requirements that are required to be met before starting the testing. A set
of decision-making guidelines used to determine whether a system under test is ready to move
into, or enter into a particular phase of testing.

Exit Criteria:

These are predefined requirements that are required to be met before testing is finished. A set
of decision-making guidelines used to determine whether a system under test is ready to exit a
particular phase of testing.

83. SDLC:

SDLC: (Software Development Life Cycle)

The various activities which areundertaken when developing software are commonly modeled
as a Software development life cycle.

SDLC Includes

 Requirements analysis
 Design
 Coding
 Testing
 Installation
 Maintenance
87. What is the difference b/w Product Testing and Application Testing:

A product is developed software which is generic to all; the changes in the software will be made when
the new requests/change requests raised by the client. Testing this type of product is known as product
testing.

A project is particularly or specifically related to one and only one client. Testing this application is
known as project testing.

88. Test Strategy & Test Plan:

A document that gives a detailed plan for the testing process. Test Plan is a document it describes
overall testing activity for that Project. This document prepared by TestLead or [Link]

It describes:

 Total number of features to be tested

 Testing strategies / approaches to be followed

 The testing methodologies

 Resources required for the whole testing process – Environment

 Test Schedule

 The testing tools that are to be used

 Reference to test cases

* Defect Tracking System

* Requirements tracability

* User Acceptance Plan

* Entry-Exit criteria

Test Strategy is part of test plan A Test Strategy is a formal description of how a software product will be
tested. Test stategy explains what are all the kind of testings that should be done. A Test Strategy is
developed for all levels of testing as required. This document prepared by PM.

Test Strategy describes the general approach and objectives of the test activities.

o Name of the project

o Brief description of the project

o Type of the project(Fresh development/Produce)

o Type of software

o Levels of testing

o Critical Success factors(Delivery on time, Reasonable response time)

o Risk factors(May not work in 95,Developers are new)---Impact the time line

o Trade-Off(Delivery on time)

89. STLC – Software Testing Life Cycle:

STLC means it starts from the preparation of test plan,

test case and ends with product release. Meanwhile we'l b
involved in some other types of testing. Major tasks will b
done in STLC are as follows,
Testing Life Cycle
 Test Plan Preparation

Test case Design

Test Execution & Test

Log Preparation

Defect Tracking

Test Report Preparation

Testing Process:

TestPlan,

TestCase,

TestExecution-(Smoke Test, Integration Testing, System Testing, Regression [Link]

Testing)

Defect Tracking System

TestReports-(TestExecutionreport),

90. Configuration Management:

Standards & procedures for managing changes in an evolving s/w product in our organization. TFS is
configuration tool.

TFS – Configuration Tool.

Manage the configurable items.

codechurn,CM [Link] audit documents we prepared to manage .

Proper access rights to be provided for the respected user.

QR is responsible to doing the activities. But the mgr is the answerable person

Proper naming conventions to be followed.

Code Churn- Change set details, file name, who changed the file, time

in CM audit,....QR verify the PDSP,baseline documents & audit those records

PDSP-Project defined s/w process

The QR will conduct the Configuration Audit to verify the compliance to configuration management
activities defined in this plan. The frequency of Configuration Audits will be once a month at the end of
the month. All non-conformances will be reported using Audit tracker template.
91. Metrics:

To determine how much variation is inherent in the process.

When defects are found it as to be documented to generate various statistics.

The defect found in various stages like SRS review, HLD review, LLD review, code review, test case
review etc. When defects are found the cause for the defect is analyzed.
The important ones are

Defect Leakage - When a particular defect is not detected and it is detected in subsequent stages,rework
will take more time.

Defect Age - Is the duration between the phase when the defect is introduced and when the defect
isidentified and rectified (we must minimize the DA).

Defect Distribution - The percentage of number of defects found out in a particular phase to the
total number of defects found out in the development.

Defect Density - The total number of defects per kilo line of code (KLOC) (Lower the number higheris the
efficiency usually 1 bug per million line of code).

94. Traceability Matrix:

Mapping b/w the Test Case document, design document and SRS document. We can trace the lifecycle
activities. It is used to identify the missed out testcases.

with bdt we can test the change request if any for dev they can easily do the required changes in the
coding and testers can write the test case against these changes. so it helps in mapping req, desing and
test cases

uni-directional is used to check whether the testcases covered all the reqs or not. But in bidirection after
getting the defect we can see the defect is related to which test case as well as which requirement

97. Baseline Document:

 The review and approved document is called as baseline document (i.e)Test plan,
SRS.
[Link] is Test Server?
Test Server is nothing but the place where the developers put their development modules, which are
accessed by the testers to test the functionality

99. Give an example of high priority and low severity, low priority and high severity?

In user interface bugs we are giving low severity

Ex: 1) Improper right alignments (low priority)
2) Spelling mistakes (high priority)
In calculation bug we are giving high severity
Ex: 1) final output is wrong (low priority)
2) Dependent outputs are wrong (high priority)

[Link] is Test Data Collection?

Test data is the collection of input data taken for testing the application. Various types and size of input
data will be taken for testing the applications. Sometimes in critical application the test data collection
will be given by the client also.

[Link]:

Testing is a process of executing the program with the intent of finding errors.
Testing the application against satisfied the user requirements or not.

106. What is Gorilla Testing?

Testing one particular module, functionality heavily.
107. What is Monkey Testing?
Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an
application does not
crash out.

110. What can be done if requirements are changing continuously?

A common problem and a major headache.
- Work with the project's stakeholders early on to understand how requirements might change so that
alternate test plans and
strategies can be worked out in advance, if possible.
- It's helpful if the application's initial design allows for some adaptability so that later changes do not
require redoing theapplication from scratch.
- If the code is well-commented and well-documented this makes changes easier for the developers.
- Use rapid prototyping whenever possible to help customers feel sure of their requirements and
minimize changes.
- The project's initial schedule should allow for some extra time commensurate with the possibility of
changes.
- Try to move new requirements to a 'Phase 2' version of an application, while using the original
requirements for the 'Phase1' version.
- Negotiate to allow only easily-implemented new requirements into the project, while moving more
difficult new requirementsinto future versions of the application.
- Be sure that customers and management understand the scheduling impacts, inherent risks, and costs
of significantrequirements changes. Then let management or the customers (not the developers or
testers) decide if the changes are
warranted - after all, that's their job.
- Balance the effort put into setting up automated testing with the expected effort required to re-do
them to deal with changes.
- Try to design some flexibility into automated test scripts.
- Focus initial automated testing on application aspects that are most likely to remain unchanged.
- Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
- Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the
detail in the test cases,or set up only higher-level generic-type test plans)
- Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of
the added risk thatthis entails).

111. What is memory leaks and buffer overflows ?

Memory leaks means incomplete deal location - are bugs that happen very often. Buffer overflow means
data sent as input tothe server that overflows the boundaries of the input area, thus causing the server
to misbehave. Buffer overflows can beused

Memory Leak is a bug in a program that prevents it from freeing up memory that it no longer needs.
As a result, the program grabs more and more memory until it finally crashes because there
is no more memory left.

112. Types of Bugs:

UI bugs: (Low severity)
Spelling mistake: High Priority
Wrong alignment: Low Priority
Input Domain bugs: (Medium severity)
Object not taking Expected values: High Priority
Object taking Unexpected values: Low Priority
Error Handling bugs: (Medium severity)
Error message is not coming: High Priority
Error message is coming but not understandable: Low Priority
Calculation bugs: (High severity)
Intermediate Results Failure: High Priority
Final outputs are Wrong: Low Priority
Service Levels bugs: (High severity)
Deadlock: High Priority
Improper order of Services: Low Priority
Load condition bugs: (High severity)
Memory leakage under load: High Priority
Doesn't allow customer expected load: Low Priority
Hardware bugs: (High severity)
Printer not connecting: High Priority
Invalid printout: Low Priority
Id control bugs: (Medium severity) Wrong version no, Logo
Version Control bugs: (Medium severity)
Source bugs: (Medium severity) Mismatch in help documents

113. Test Closure:

After completion of all possible testcase execution and their defect reporting and
tracking, test lead conduct test execution closure review along with test engineers.

114. Basis Path Testing:

During this test the programmers concentrate on the execution of
Programs without any runtime errors.

116. If developer is not agree with your bug then what is your response?
If the developer is not agree with the bug that posted by a
tester, we should convenience them to approve the bug by
conducting the meeting or we have to take a screen shot of
the bug occurred in the application and to be posted or
shown to the development team

117. What is Bottle Neck testing?

If there is no suffecient time to do all planed testing
activities. then we can do testing on major functionality
of the product. this could be achieved by AD-HOC testing
this is said to be bottle neck testing

118. What is a show stopper?

Show stopper is a bug which does not let you to carry out
the testing process any further.

119. Tell me some of the Possible test cases on ATM Machine?

TC 1:- successful card insertion.
TC 2:- unsuccessful operation due to wrong angle card insertion.
TC 3:- unsuccessful operation due to invalid account card.
TC 4:- successful entry of pin number.
TC 5:- unsuccessful operation due to wrong pin number
entered 3 times.
TC 6:- successful selection of language.
TC 7:- successful selection of account type.
TC 9:- successful selection of withdrawal option.
TC 10 :- successful selection of amount.
TC 11:- unsuccessful operation due to wrong denominations.
TC 12:- successful withdrawal operation.
Tc13 :- unsuccessful withdrawal operation due to amount
greater than possible balance.
TC 14 :- unsuccessful due to lack of amount in ATM.
TC 15 :- unsuccessful due to amount greater than the day limit.
TC 16 :- unsuccessful due to server down.
TC 17 :- unsuccessful due to click cancel after insert card.
TC 18:- unsuccessful due to click cancel after insert card
and pin no.
TC 19:- unsuccessful due to click cancel after language
selection,account type selection,withdrawal selection, enter
amount

120. Fault,Failure,Error,Defect,Bug:

Fault:

Fault is a condition that causes the s/w to fail to perform its required function.

Failure:

In ability of a system to perform the functionality according to its requirements

Error:
Mistake made incoding or mistake made by a [Link] may be program error or syntax error.

Defect:

Variance b/w expected and actual result

While executing the test case if u found any mismatch, the u will report
it to the development team, that is called defect.

Bug: Once the developer accepts your defect, then it is called as a bug.

Bug is an error during execution of the pgm. 2 types of bugs:

1. Syntax
2. Logical

122. What is the difference b/w Product Testing and Application Testing?

A product is developed software which is generic to all; the changes in the software will be made when
the new requests/change requests raised by the client. Testing this type of product is known as product
testing.

A project is particularly or specifically related to one and only one client. Testing this application is
known as project testing.
123. Test Deliverables:

1. Test Case
2. Defect reports – (Bug analysis report)
 3. Status report- (weekly,monthly)
4. Metric reports
5. Release note

124. Test Script:

Test script is the script which is generated by an automation tool while recording aapplication features.

125. Compatibility testing:

Testing how well software performs in a particularhardware/software/operating/system/network/etc
environment

126. Test Data:

Test data means the input data (valid, invalid data) giving to check the featureof an application is
working correctly.

127. Stub & Driver:

Stub means a Dummy model of a particular module. Suppose we have to test the interface between 2
modules A and B and we have developed only module A while Module B is yet in development stage.

So in such case we cannot test module B but, if we prepare a dummy module, having similar features
like B then using that we can test module A.

Our main aim in this is to test Module A & not Module B so that we can save time otherwise we have to
wait till the module B is actually developed.

Hence this dummy module B is called as Stub.

Stubs are “Called functions” used in Top-Down Integration Testing

Now module B cannot send/receive data from module A directly/automatically so, in such case we have
to transfer data from one module to another module by some external features. This external feature
used is called Driver.

Drivers are “Calling functions” used in Bottom-Up Integration Testing

138. What is Software reliability?

It is the probability that software will work without failure for a specified period of time in a specified
[Link] of software is measured in terms of Mean Time Between Failure (MTBF).
For eg if MTBF = 10000 hours for an average software, then it should not fail for 10000 hours of
continous operation.
 139. What are th e differenent types of reviews you know?

* Peer Review or Code Review

* Document Review-->for SRS,SDC,TestPlan,TestCase,Traceability Matrix

Walkthrogh, Inspection

140. what are 2 things that u know based on whicnthe test case design is
created?

There are two things that may be looked on while designing test cases

1. Pesticide Parodoxing - When same amount of test cases is used for the
appilication of the similar functiolality the application would be immune
to defect identification since the same set of test cases is used across
the application of similar functionalities.

the same tests are repeated over and over again, eventually the same set of test cases will no longer
find any new defects. To overcome this “pesticide paradox”, the test cases need to be regularly
reviewed and revised, and new and different tests need to be written to exercise different parts of
the software or system to potentially find more defects.

2. Defect Clustering-

Defect Clustering is a case while test desingn. The test case that was
designed finds numerous defects in one module . This situation is called as
defect clustering

A small number of modules contain most of the defects discovered during pre-release testing, or
are responsible for the most operational failures.

Identifying the density of bugs in a particular module is termed as defect clustering.

for example
An application has four modules to be [Link] the tester finds the percentage of failure in particular
module is more ,then a test engineer reports that a defect clustering has occured in particular module.
Once the cluster is identified,there is no use of continuing the test [Link] the build is given
back for fixing.

141. What if there isn't enough time for thorough testing?

Use risk analysis to determine where testing should be focused.

Since it's rarely possible to test every possible aspect of an application, every possible combination of
events, every
dependency, or everything that could go wrong, risk analysis is appropriate to most software
development projects. This
requires judgment skills, common sense, and experience. (If warranted, formal methods are also
available.) Considerations
can include:
- Which functionality is most important to the project's intended purpose?
- Which functionality is most visible to the user?
- Which functionality has the largest safety impact?
- Which functionality has the largest financial impact on users?
- Which aspects of the application are most important to the customer?
- Which aspects of the application can be tested early in the development cycle?
- Which parts of the code are most complex, and thus most subject to errors?
- Which parts of the application were developed in rush or panic mode?
- Which aspects of similar/related previous projects caused problems?
- Which aspects of similar/related previous projects had large maintenance expenses?
- Which parts of the requirements and design are unclear or poorly thought out?
- What do the developers think are the highest-risk aspects of the application?
- What kinds of problems would cause the worst publicity?
- What kinds of problems would cause the most customer service complaints?
- What kinds of tests could easily cover multiple functionalities?
- Which tests will have the best high-risk-coverage to time-required ratio?

RTM
Metrics
Software Testing Metrics are the quantitative measures used to estimate the
progress, quality, productivity and health of the software testing process. The goal
of software testing metrics is to improve the efficiency and effectiveness in the
software testing process and to help make better decisions for further testing
process by providing reliable data about the testing process.

Test process ,

“I’m a QA Lead with 15+ years of experience, I have previously worked with saama
technologies for 3 yrs in life science domain and I have handled various clients
Pizer,PPD,novatech and worked in core product team and worked in different projects SDQ,
[Link] & DH.

Before saama I have worked in Mphasis for 12 years . I have worked in various domains like
Life Sciences ,Enery….

. I’ve worked extensively with 21 CFR Part 11, GxP, and CSV documentation, and led QA teams
for regulated platforms at SAAMA, including Pfizer programs.
I’m strong in test strategy, RCA, risk-based testing, and SQL validation. Currently, I’m
upskilling in Python and Playwright automation to bring automation efficiency into compliance-
focused QA environments.”

1️⃣ “Why Automation Now?”

🎤 Strong Answer

“Over the years, I’ve built strong expertise in compliance-driven QA,

governance, and defect prevention. However, I strongly believe that modern
QA leadership should combine both process discipline and automation
efficiency.

In regulated environments like Life Sciences, automation is becoming

essential for faster regression cycles, repeatability, and audit traceability. So
I decided to upskill in Python and Playwright to strengthen my technical
capability and support hybrid QA models.

It’s not a shift from manual testing — it’s an evolution of my QA leadership

skills to align with current industry needs.”

2️⃣ “Why Career Break?” (If They Ask)

(Keep it calm and simple. Do NOT over-explain.)

🎤 Strong Balanced Answer

“I took a short break to focus on personal priorities and to reassess my next

career direction. During this period, I consciously used the time to upskill in
automation using Python and Playwright so that I can return to the industry
stronger and more future-ready.

Now I am fully prepared and committed to taking up a long-term role.”

3️⃣ “Why Should We Hire You?”

This is where you must be powerful.

🎤 Strong Leadership Answer

“You should consider me because I bring a combination of domain expertise,

compliance knowledge, leadership experience, and now evolving automation
capability.
I have led QA in regulated environments aligned with 21 CFR Part 11 and
GxP standards, handled CAPA and audit readiness, and worked with global
clients like Pfizer. I understand not just testing, but quality governance and
risk prevention.

Additionally, I am actively building automation skills in Python and

Playwright, which allows me to contribute both strategically and technically.

I don’t just execute testing — I focus on preventing defects, improving

processes, and ensuring release stability.”

1️⃣ QA LEAD – TECHNICAL INTERVIEW QUESTIONS

❓ How do you define a Test Strategy?

Answer:

“A Test Strategy defines the overall quality approach for a project. It includes
scope, risk assessment, test types, environments, entry/exit criteria,
resource planning, and compliance requirements.

In regulated environments, I also ensure traceability through RTM and

alignment with 21 CFR Part 11 and CSV documentation standards.”

❓ How do you handle defect leakage?

Answer:

“I focus on prevention rather than detection.

I conduct:

 Risk-based test planning

 RCA for escaped defects

 Coverage gap analysis

 Strengthening regression suite

In regulated programs, I ensure traceability between requirements and test

cases to minimize leakage.”
❓ What is your approach to CAPA?

Answer:

“CAPA is not just corrective action; it’s preventive governance.

I analyze root cause, identify process gaps, define preventive measures,

assign ownership, and track closure effectiveness.

In QMO initiatives, I’ve handled CAPA documentation and migration activities

aligned with compliance standards.”

❓ How do you manage offshore teams?

Answer:

“I clearly define deliverables, maintain daily sync calls, track sprint progress,
and ensure clarity in documentation.

I also review test cases personally for critical releases to ensure quality
consistency.”

3️⃣ SCENARIO-BASED LEADERSHIP QUESTIONS

❓ What if developer says “It works on my machine”?

Answer:

“I avoid confrontation. I reproduce the issue with evidence, attach

logs/screenshots, and discuss environment differences.

I focus on resolution, not blame.”

❓ How do you handle production defect?

Answer:
“First, assess severity and business impact.

Second, provide immediate workaround if possible.

Third, conduct RCA and strengthen regression suite to prevent recurrence.”

❓ What if deadline is tight?

Answer:

“I prioritize based on risk.

Critical flows are tested first.

I communicate clearly to stakeholders about scope coverage and residual

risks.”

📘 What CSV Documentation Includes

CSV documentation typically covers the full validation lifecycle of a
computerized system to ensure it is fit for intended use and compliant.

It includes:

1️⃣ Validation Planning Documents

 Validation Plan (VP)

Defines scope, responsibilities, validation approach, risk level, and
deliverables.
 Risk Assessment (RA)
Identifies system impact on patient safety, product quality, and data
integrity.

 Validation Strategy
Defines whether it is full validation, partial validation, or leveraging
vendor documentation.
 2️⃣ Requirement & Design Documents

 URS (User Requirement Specification)

What the system must do from user/business perspective.
 FRS (Functional Requirement Specification)
How the system will function to meet URS.

 DS (Design Specification)
Technical design details.

 Traceability Matrix (RTM)

Maps URS → FRS → Test Cases → Results.

This is very important in audits.

3️⃣ Testing Documentation

 IQ (Installation Qualification)
Verifies system installed correctly.
 OQ (Operational Qualification)
Verifies system functions as intended.

 PQ (Performance Qualification)
Verifies system performs in real-world conditions.

 Test Protocols & Test Scripts

 Test Execution Records

 Defect Logs & Deviation Reports

4️⃣ Compliance & Governance Documents

 21 CFR Part 11 Assessment

 Data Integrity Assessment

 CAPA Documentation

 Change Control Records

 Audit Trail Review Documentation

 5️⃣ Final Documentation

 Validation Summary Report (VSR)

Confirms validation activities completed and system is fit for use.
 Approval Sign-offs

 Release Authorization

 “CSV documentation covers the entire validation lifecycle including

Validation Plan, Risk Assessment, URS, FRS, Design Specifications,
RTM, IQ/OQ/PQ protocols, test execution records, deviation handling,
CAPA documentation, and finally the Validation Summary Report.

 In regulated environments, traceability and audit readiness are key

focus areas.”

 That answer sounds senior.

 🔥 Bonus Tip for You

 If interviewer asks:
“What is most critical in CSV?”

 Say:

 “Traceability, risk-based validation, and ensuring system is fit for

intended use while maintaining data integrity.”

 Perfect answer.

Interv\

API TESTING:

Know what is webservices , soap and rest web services

Bottom status bar of the api – option to collapse side bar , cookies delete , vault – store secret keys ,
trash – rem

Settings – has shortcuts ,can import and export data

API contains – Header , Sidebar, Builder and Status bar.

what is the difference between publish and share collections in postman api
In the Postman API tool, Publish Collection and Share Collection are two
different ways of giving access to your API requests. The main difference is
who can access it and how they access it.

1️⃣ Share Collection

Purpose:
Used to share the collection with specific people or team members.

How it works:

 You share it with team members inside your Postman workspace.

 They can open, edit, run, and collaborate on the API requests.

 Used mainly for internal team collaboration.

Example:
You and your developers are testing APIs.
You share the collection so everyone in the team can run the requests.

Key Points

 Only invited users/team members can access it

 Allows editing and collaboration

 Used for development/testing inside a team

2️⃣ Publish Collection

Purpose:
Used to publish the API documentation publicly.

How it works:

 Postman generates a public documentation link.

 Anyone with the link can view the API documentation.

 They can see request details, parameters, headers, and

responses.

 Usually used for API documentation for external users.

Example:
If your company provides APIs for clients, you publish the collection so
clients can see how to use the API.

Key Points

 Creates public API documentation

 Mostly read-only

 Used for external developers or customers


\
API interview Questions:

🔥 Postman API Interview Questions (QA Lead)

🔹 1. What is Postman?

👉 Postman is a tool used to:

 Send API requests (GET, POST, PUT, DELETE)

 Validate responses

 Automate API testing

🔹 2. What is an API?

👉 API = Application Programming Interface

➡️It allows two systems to communicate

Example:
Login page → sends request → server → sends response
 🔹 3. What are HTTP methods?
 GET → Fetch data
 POST → Create data

 PUT → Update full data

 PATCH → Update partial

 DELETE → Remove data

🔹 4. What is a Collection in Postman?

👉 Group of API requests

➡️Used to organize and run multiple APIs together

🔹 5. What is Environment in Postman?

👉 Stores variables like:

 URL
 Token

 Username

➡️Helps run same APIs in:

 Dev / QA / Prod

🔹 6. What are Variables in Postman?

 Global
 Environment

 Collection

👉 Used to reuse values

Example: {{base_url}}

🔹 7. What is Pre-request Script?

👉 Runs before API call

Use case:

 Generate token
 Set dynamic values

🔹 8. What is Test Script?

👉 Runs after API response

Used to:

 Validate response
 Write assertions

🔹 9. How do you validate response in Postman?

Example:

[Link]("Status code is 200", function () {

[Link](200);
});

👉 Checks API is working correctly

🔹 10. What is Newman?

👉 Command line tool to run Postman collections

➡️Used in CI/CD pipeline

🔹 11. How do you integrate Postman with CI/CD?

 Export collection
 Run using Newman

 Integrate with Jenkins

🔹 12. What is API chaining?

👉 Using response of one API in another

Example:

 Login API → get token

 Use token in next API

🔹 13. How do you handle authentication?

 Basic Auth
 Bearer Token

 OAuth

🔹 14. What is status code?

 200 → Success
 201 → Created

 400 → Bad request

 401 → Unauthorized

 500 → Server error

🔹 15. How do you perform data-driven testing?

👉 Use:

 CSV / JSON file

 Collection Runner

🔹 16. What is Collection Runner?

👉 Runs multiple requests with different data

🔹 17. How do you manage large API testing as QA Lead?

👉 (Important leadership question)

Answer:

 Define API test strategy

  Use collections & environments

 Automate using Newman

 Integrate with CI/CD

 Ensure proper validation & reporting

🔹 18. Difference: Postman vs Rest Assured?

Postman Rest Assured

UI Tool Code-based

Easy for beginners Used in automation

Manual + basic automation Full automation

🔹 19. What is mocking in Postman?

👉 Simulate API response without backend

🔹 20. What is monitoring in Postman?

👉 Run APIs at scheduled time

💡 QA Lead Level Tip (Very Important)

In interview, always add:

 Strategy
 Team handling

 Automation + CI/CD

👉 Not just tool knowledge

🔥 Final Advice
Prepare these topics strongly:

 API validation
 Automation using Newman

 CI/CD integration

 Real-time scenarios

Rest Assured Interview Questions (QA Lead)

🔹 1. What is Rest Assured?

👉 Rest Assured is a Java library used for automating REST API testing

✔ Works with Java

✔ Used in automation frameworks
✔ Supports BDD style (Given–When–Then)

🔹 2. Why use Rest Assured instead of Postman?

👉 Postman is manual + basic automation

👉 Rest Assured is fully automated + code-based

✔ CI/CD integration
✔ Reusable framework
✔ Better for large projects

🔹 3. What is BDD style in Rest Assured?

Example:

given()
.when()
.then();

👉 Makes code readable like English

 🔹 4. What are main components in Rest Assured?
 Given() → request setup
 When() → send request

 Then() → validate response

🔹 5. How do you validate response?

Example:

then().statusCode(200);

👉 Check API is successful

🔹 6. How do you send GET request?

Example:

given()
.when()
.get("/users")
.then()
.statusCode(200);

🔹 7. How do you send POST request?

Example:

given()
.body(payload)
.when()
.post("/users")
.then()
.statusCode(201);

🔹 8. How do you handle authentication?

 Basic Auth
 OAuth

 Bearer Token

Example:
given().auth().oauth2("token");

🔹 9. How do you validate JSON response?

Example:

then().body("name", equalTo("John"));

🔹 10. What is serialization & deserialization?

 Serialization → Java object → JSON
 Deserialization → JSON → Java object

🔹 11. How do you perform data-driven testing?

👉 Use:

 TestNG DataProvider
 External files (Excel/JSON)

🔹 12. How do you integrate with TestNG?

👉 Use annotations:

 @Test
 @BeforeClass

✔ For execution control

🔹 13. How do you handle reusable code?

👉 Create:

 Base class
 Utility methods

 Common request specs

 🔹 14. What is RequestSpecification?

👉 Used to define:

 Base URI
 Headers

 Auth

👉 Reuse in multiple tests

🔹 15. How do you log request & response?

Example:

given().log().all()
.then().log().all();

🔹 16. How do you handle dynamic values?

👉 Extract response:

String token = [Link]().get("token");

👉 Use in next API

🔹 17. How do you perform API chaining?

👉 Use response data in next request

(Login → Token → Next API)

🔹 18. How do you integrate with CI/CD?

👉 Use:

 Jenkins
 Maven

✔ Run tests automatically in pipeline

 🔹 19. What is Maven?

👉 Build tool to manage:

 Dependencies
 Test execution

🔹 20. QA Lead Scenario Question (Very Important)

❓ How will you design API automation framework?

👉 Answer:

 Use Rest Assured + TestNG

 Create reusable utilities

 Implement data-driven approach

 Integrate with CI/CD

 Maintain reporting (Allure/Extent)

💡 QA Lead Level Tips

In interview, don’t just say code. Say:

✔ Framework design
✔ Reusability
✔ CI/CD integration
✔ Team usage

🔥 Final Strategy
👉 For your level, focus on:

 Framework design
 API chaining

 Data-driven testing

 CI/CD integration
WSDL?
Why static in import
Wizdler

PLAYWRIGHT
Playwright show-trace <path>
Datadriven testing:
Fixtures are setups prepared in advane that tests can use when needed
--this code will run the tests in sequence one after the other.

Overriding fixtures:
 Interview question playwright:
Workers in Playwright are parallel processes that execute tests simultaneously to improve
execution speed.
 Python:

‘
1. Install Playwright and Pytest-Playwright

pip install pytest-playwright

Install browsers :L

playwright install

to check reports:
 How to get the report with your code
To get a report while using pytest , you need to install the pytest-html plugin and run
a specific command:
YouTube +1

1. Install the plugin:

bash
pip install pytest-html
Use code with caution.
2. Run your test with the report flag:

bash
pytest --html=[Link]

To run in UI mode or to debug

Use --ui command
\
Typesript
Doubts / Interview qs:
What is [Link]
What is the use of –Ui mode and how to run headed mode
What is the difference between constructor and functions

Syntax:

Npx playwright test – to run

Npx playwright test –ui --headed ---showreport

JS vs TS:
POM:
Hi, myself Narmadha. I have around 15 years of experience in Software
Testing and QA, with strong exposure to regulated environments and
validation activities. Currently, I am working as a QA Lead, handling end-to-
end testing and validation activities for data-driven applications used in life
science and pharmaceutical domains.

I have experience in SDLC, STLC, and Computer System Validation

processes, including preparation and review of validation deliverables such
as Validation Plan, Test Scripts, Traceability Matrix, Defect Management, and
Validation Summary Reports. I have worked on different types of testing
including Functional Testing, System Testing, Regression Testing, GUI
Testing, OQ, and PQ activities.

I also have knowledge of regulatory guidelines like GAMP 5, Annex 11, and
21 CFR Part 11, and I understand the importance of compliance, audit trails,
data integrity, and maintaining systems in a validated state.

In my current role, I coordinate with cross-functional teams, manage multiple

tasks and timelines, support release activities, and ensure quality
deliverables within project schedules. I also have experience validating
backend data using SQL and working closely with development and business
teams during defect triage and UAT support.

I am a quick learner, detail-oriented, and comfortable working with both

onsite and offshore teams. Now, I am looking for an opportunity where I can
further contribute my QA leadership and validation experience in a regulated
environment.”

🔥 Short Version (2-minute introduction)

“Hi, I am Narmadha with around 15 years of QA experience, currently
working as a QA Lead. I have strong experience in software testing and
validation activities in regulated environments, especially in life
science/pharma-related applications.

My experience includes validation documentation such as Validation Plan,

RTM, Test Scripts, OQ, PQ, defect management, and VSR preparation. I have
worked on Functional, Regression, GUI, and System Testing and have
knowledge of regulatory standards like 21 CFR Part 11, GAMP 5, and Annex
11.

I also have experience coordinating with cross-functional teams, validating

backend data using SQL, and supporting releases in validated environments.
I am now looking for a challenging role where I can utilize my QA Lead and
validation expertise.”