Manual Testing Notes

What is the software?

Software is a collection of computer programs that helps us to perform a task.

Types of software:

1. System Software (e.g., Device drivers, OS, servers, etc.)

2. Programming Software (e.g., compilers, debuggers, interpreters, etc.)
3. Application Software (e.g., Web Applications, Mobile Apps, Desktop Applications, etc.)

What is Software Testing?

1. Software Testing is a part of the software development process.

2. Software Testing is an activity to identify the bugs in the software.
3. The objective/motive of testing is to release quality products to the client.
4. To ensures the client about the correctness and completeness of the software
application.

Necessity of Software Testing:

1. To avoid risks (prevent)

2. To identify errors (detect)
3. To avoid extra costs
4. To gain customer confidence
5. To accelerate software development
6. To optimize business
7. To check software adaptability

Objectives/Motive of Software Testing:

1. To prevent defects.
2. Finding defects that may get created by the programmer while developing the software.
3. Helps to provide a quality product.
4. To ensure that it satisfies the BRS and SRS.
5. To ensure that the result meets the business and user requirements.
6. Gaining confidence and providing information about the level of quality.
What is Debugging:

1. Once the Development team receives the testing team’s report, they will
start debugging. This phase aims to locate the bug and remove it from the
software. It is a one-off process and is done manually.
2. In this process, a special tool called a debugger is used in locating the bugs,
most programming environments have the debugger.
3. Some popular Debugger tools: WinDbg, OllyDbg, IDA Pro...

What is the difference between Testing and debugging?

• Testing means checking the behavior of the application whether it is
expected or not. And Testing can be done without any internal knowledge
of software architecture. It’s done by a tester.
• Debugging means finding out the main cause of defects and debugging
requires Internal knowledge of the software architecture and coding. It’s
done by the developer.

What defines (the quality of software) Software Quality:

1. Bug-free
2. Delivered on time
3. Within budget
4. Meets the requirements and/or expectations of the customer
5. Maintainable

Psychology of testing:
• In software testing, psychology plays an extremely important role.
• It is one of those factors that stay behind the scenes but has a great impact on the end
result.
• It is mainly dependent on the mindset of the developers and testers, as well
 as the quality of communication between them. Moreover, the psychology
of testing helps them work towards a common goal.
• The three sections of the psychology of testing are:
o The mindset of Developers and Testers.
o Communication in a Constructive Manner.
o Test Independence.

QA Vs. QC:

3P’s: Every Company has 3 Pillars:

 • P - People (QC - Testers)
• P - Process (QA - Involves throughout development/SDLC process.)
• P - Product

Quality Assurance:

• QA is process-oriented.
• QA is a proactive process.
• QA focuses on preventing defects.
• QA team works with the development team to produce quality software.
• QA ensures that approaches and techniques are implemented correctly
(during software development).
• QA is responsible for SDLC.
• E.g., Verification

Quality Control:

• QC is product-oriented.
• QC is a reactive process.
• QC focuses on identifying/detecting the defects.
• QC comes into the picture after Quality Assurance.
• QC verifies that the developed project meets the defined quality standards.
 • QC is responsible for STLC.
• E.g., Validation

QE (Quality Engineering):

• Quality Engineer writes the code but for the software testing purpose.
• Quality Engineers are nothing but Automation Testers.

What is QAMS?
• A quality management system is a collection of business processes focused
on consistently meeting customer requirements and enhancing their
satisfaction. It is aligned with an organization's purpose and strategic
direction.
• A quality management system (QMS) is a system that documents the policies,
business processes, and procedures necessary for an organization to create
and deliver its products or services to its customers, and therefore increase
customer satisfaction through high product quality.

Capability Maturity Model (CMM-Levels):

It has long been accepted that continuous process improvement is based on

many small evolutionary steps rather than larger revolutionary innovations.
The Capability Maturity Model (CMM) provides a framework for organizing
these evolutionary steps into five maturity levels that lay successive
foundations for continuous process improvement.

This methodology is at the heart of most management systems which are

designed to improve the quality of the development and delivery of all
products and services.
The five Software Capability Maturity Model levels have been defined as:

1. Initial

The software process is characterized as ad hoc, and occasionally even

chaotic. Few processes are defined, and success depends on individual
effort and heroics.

2. Repeatable

Basic project management processes are established to track cost,

schedule, and functionality. The necessary process discipline is in place
to repeat earlier successes on projects with similar applications.
 3. Defined

The software process for both management and engineering activities

is documented, standardized, and integrated into all processes for the
organization. All projects use an approved version of the
organization’s standard software process for developing and
maintaining software.

4. Managed

Detailed measures of the software process and product quality are

collected. Both the software process and products are quantitatively
understood and controlled.

5. Optimizing

Continuous process improvement is enabled by quantitative feedback

from the process and from piloting innovative ideas and technologies.

==========================================================================
===

Project Vs. Product:

• If a software application is developed for a specific customer based on their

requirement, then it is called a Project.
• If a software application is developed for multiple customers based on the
market requirements, then it is called a Product.

7 Principles of Software Testing:

1. Testing shows the presence of defects, not their absence
2. Exhaustive testing is impossible
3. Absence-of-errors is a fallacy
4. Early testing saves time and money
5. Testing is context-dependent
6. Defects cluster together
7. Beware of the pesticide paradox
✓ BETA DET

1. Testing shows the presence of defects, not their absence:

 • Testing can show that defects are present but cannot prove that there are
no defects. Testing reduces the probability of undiscovered defects
remaining in the software, but testing is not proof of correctness even if
no defects are found.

2. Exhaustive testing is impossible:

• Testing everything (all combinations of inputs and preconditions) is not
feasible except for trivial cases.
• Rather than attempting to test exhaustively, risk analysis, test
techniques, and priorities should be used to focus test efforts.

3. Early testing saves time and money:

• To find defects early, both static and dynamic test activities should be
started as early as possible in the software development lifecycle.
• Testing early in the software development lifecycle helps reduce or eliminate costly
changes.

4. Absence-of-errors is a fallacy
• Some organizations expect that testers can run all possible tests and find
all possible defects, but this is impossible. It is a fallacy (i.e., a wrong belief)
to expect that just finding and fixing a large number of defects will ensure
the success of a system.
• For example, testing all specified requirements and fixing all defects found
could still produce a system that is difficult to use but does not fulfill the
users’ needs and expectations.

5. Testing is context-dependent
• Testing is done differently in different contexts.
• For example, testing in an Agile project is done differently than
testing in a sequential software development lifecycle project.
6. Defects cluster together
• This is the idea that certain components or modules of software
usually contain the most number of issues or are responsible for most
operational failures.
• Testing, therefore, should be focused on these areas.

7. Beware of the pesticide paradox

 • If the same tests are repeated over again and again, eventually these tests
no longer find any new defects.
• To detect new defects, existing test cases and test data may need
changing, and new tests may need to be written.
• Tests are no longer effective at finding defects, just as pesticides are no
longer effective at killing insects after a while. In some cases, such as
automated regression testing, the pesticide paradox has a beneficial
outcome, which is the relatively low number of regression defects.

==========================================================================
===

SDLC - Software Development Life Cycle:

• SDLC is a process used by the software industry to design, develop and test
software.
• SDLC process aims to produce high-quality software that meets customer
expectations.
• The software development should be complete in the pre-defined time frame and
cost.
• SDLC consists of a detailed process that explains how to plan, build,
and maintain specific software.

Why is SDLC Needed?

Here, are prime reasons why SDLC is important for developing a software system.

✓ It provides a standard set of frameworks for SDLC activities.

✓ SDLC is helpful for project tracking and control.
✓ Increased and enhanced development speed.
✓ Helps you to decrease project risk and project management plan overhead.
✓ Increases visibility of project planning to all involved stakeholders
 of the development process.
✓ Improved client relations.
✓ It offers a basis for project planning, scheduling, and estimating.

Phases in SDLC:

1. Requirement Gathering and Analysis

2. Design
3. Coding (Development/Implementation)
4. Testing
5. Deployment / Installation
6. Maintenance
RDC-TDM

1. Requirement Analysis:

• We have to collect and understand the requirement of the customer.

Normally BA’s, Project Managers, and Product Managers are involved in
this phase.
• They will talk to the customer, get the requirements, and prepare a
certain number of documents (BRS/SRS).
• This stage gives a clearer picture of the scope of the entire project and forecasts
issues.
• This helps companies to finalize the necessary timeline to finish the work of that
system.

2. Design:

• This helps to define the overall system architecture.

• In this phase, both system and software design documents are
prepared as per the requirement specification document.
• This design phase serves as input for the next phase of the model.
• It contains documents like DDS (Design Document Specification) OR
TDD (Technical Design Document).
• There are two kinds of design documents developed in this phase:
a. High-Level Design (HLD):
✓ Brief description and name of each module.
✓ An outline of the functionality of every module.
✓ Integration between modules.
✓ Database tables are identified along with their key elements.
✓ Complete architecture diagrams along with technical details.
 b. Low-Level Design (LLD):
✓ Actual Functional logic of the modules.
✓ Complete input and outputs for every module.
✓ Complete details of the integrations/interfaces.
✓ Addresses all types of dependency issues.
✓ List of error messages.
✓ Database tables, which include type and size.

3. Coding:
• Once the system design phase is over, the next phase is coding. In this
phase, developers start to build the entire system by writing code using
the chosen programming language.
• In the coding phase, tasks are divided into units or modules and
assigned to the various developers.
• It is the longest phase of the Software Development Life Cycle process.
• In this phase, the developer needs to follow certain predefined coding guidelines.
• They also need to use programming tools like compilers, interpreters,
and debuggers to generate and implement the code.

4. Testing:
• Once the software is complete, it is deployed in the testing environment.
The testing team starts testing the functionality of the entire system. This
is done to verify that the entire application works according to the
customer’s requirements.
• During this phase, QA and testing team may find some bugs/defects which
they communicate to developers. Then development team fixes the bug
and sends it back to QA for a retest. This process continues until the
software is bug-free, stable, and working according to the business needs
of that system.
5. Deployment / Installation:
• Once the software testing phase is over and no bugs or errors are left in
the system then the final deployment process starts. Based on the
feedback given by the project manager, the final software is released and
checked for deployment issues if any.

6. Maintenance:
 • Once the system is deployed, and customers start using the developed
system, the following three activities may occur:
✓ Bug fixing - Bugs are reported because of some scenarios
which are not tested at all.
✓ Upgrade - Upgrading the application to the newer versions of the
Software.
✓ Enhancement - Adding some new features to the existing software.

==========================================================================
===

Which SDLC model is best?

• There is no model that we can consider as the best for software

development process. But nowadays the
• Agile model is currently the most popular and widely used by all the
software organization. In this model after
• every development stage (Sprint), the user is able to see whether the
product meets his requirements. By this
• way the risks are reduced as continuous changes are done depending on client’s
feedback.

==========================================================================
===
Types (Models) of SDLC:

1. Waterfall Model
2. Spiral Model
3. Rapid Application Development (RAD) Model
4. Iterative or Incremental Model
5. Prototype Model
6. V Model
7. Agile Model

1. Waterfall Model:
• Waterfall is one of the earliest and most commonly used software
development models (processes), in which the development process
looks like the flow, moving step by step through the phases like
analysis, design, coding, testing, deployment/installation, and
support. So, it is also known as the “Linear Sequential Model”.
• This SDLC model includes gradual execution of every stage completely.
This process is strictly documented and predefined with features
expected for every phase of this software development life cycle
model.
 Advantages of Waterfall Model:
1. Simple, easy to understand, and use.
2. Easy to implement because of its linear process.
3. Since requirement changes are not allowed, the chances of finding bugs will be
less.
 4. Initial investment is less since the testers are hired at the later stages.
5. Preferred for small projects where requirements are frozen (well
understood at an early stage).

Disadvantages of Waterfall Model:

1. Requirement changes are not allowed.
2. If there is a defect in the Requirement that will be continued in later phases.
3. Poor model for a long and ongoing project.
4. Testing will start only after the coding phase.
5. Total investment is more because if the rework was done due to
defects, leads to time-consuming and high investment.

Where we Use (Use Cases for) Waterfall SDLC Model:

1. The requirements are precisely documented.
2. Product definition is stable.
3. The technologies stack is predefined which makes it not dynamic.
4. No ambiguous (doubtful) requirements.
5. The project is short.

==========================================================================
===

2. Spiral Model: PREE

1. Spiral Model is also known as an iterative model.
2. It is a combination of the Prototype and Waterfall model.
3. Spiral Model is mostly used in high-risk projects (in large and complex
projects).
4. It is used when the requirement is large also unclear and complex.
5. Spiral Model overcomes drawbacks of Waterfall Model.
6. It consists of 4 stages Planning, Risk Analysis, Engineering, and Evaluation.
7. In every cycle new software [module] version will be released to the customer.
8. Software will be released in multiple versions. So, it is also called
a version control model.
 Stages:
1. Planning objectives or identifying alternative solutions: In this
stage, requirements are collected from customers, and then the
aims are recognized and analyzed at the beginning of developing
the project. If the iterative round is more than one, then an
alternative solution is proposed in the same quadrant.

2. Risk analysis and resolving: As the process goes to the second

quadrant, all likely solutions are sketched, and then the best
solution among them gets selected. Then the different types of
risks linked with the chosen solution are recognized and resolved
through the best possible approach. As the spiral goes to the end
of this quadrant, a project prototype is put up for the most
excellent and likely solution.

3. Develop the next level of product: As the development progress

goes to the third quadrant, the well-known and most required
features are developed as well as verified with the testing
methodologies. At the end of this third quadrant, new software or
 the next version of existing software is ready to deliver.

4. Plan the next Phase: As the development process proceeds in the

fourth quadrant, the customers appraise the developed version of
the project and report if any further changes are required. At last,
planning for the next (subsequent) phase is initiated.
 Prototype: A prototype is a blueprint of the software.

Initial requirements from the customer ---> PROTOTYPE ---> customer

---> Design, Coding, Testing....

Advantages of Spiral Model:

1. Suitable for large projects: Spiral models are recommended when
the project is large, bulky, or complex to develop.
2. Risk Handling: There are a lot of projects that have un-estimated
risks involved with them. For such projects, the spiral model is the
best SDLC model to pursue because it can analyze risk as well as
handle risks at each phase of development.
3. Customer Satisfaction: Customers can witness the development of
the product at every stage and thus, they can let themselves
habituate to the system and throw feedback accordingly before the
final product is made.
4. Requirement’s flexibility: All the specific requirements needed at
later stages can be included precisely if the development is done
using this model.

Disadvantages of Spiral Model:

1. Requirement changes are NOT allowed in between the cycle.
2. Every cycle of the spiral model looks like a waterfall model.
3. There is no testing in the requirement and design phase.
4. Does not work for smaller projects.
5. It can be quite expensive.

==========================================================================
===
3. RAD Model:

RAD stands for “Rapid Application Development”. As per the name itself,
the RAD model is a model to develop fast and high-quality software
products by Requirements using workshops.

1. Prototyping and early, reiterative user testing of designs.

2. The re-use of software components.
3. Less formality in reviews and other team communication.

==========================================================================
===

4. Iterative Model:
 1. In an iterative model application will get divided into small parts
and development will be done by specifying and implementing only
small parts of the software, which can be reviewed to identify
further requirements.
2. This process is repeated, creating a new version of the software for
each cycle of the model. The iterative model is very simple to
understand and use. In this model, we can’t start developing the
complete software with full specification of requirements

==========================================================================
===

5. Prototype Model:
• It is a trial version of the software. It is a sample product that is
designed before starting actual testing.
• This model is used when user requirements are not very clear, and this
software is tested based on raw requirements obtained from the user.
The available types of prototyping are Rapid, Incremental,
Evolutionary, and Extreme.
• Prototype Model will work like --
1. We will take basic requirements
2. Based on the discussion, we will create an initial prototype (A
prototype – is a working model)
3. Once the working prototype is built, we will ask the client to check and use it
4. Next step will be to test and enhance
5. Again, we will call the user to check and use it, and again we will
make changes as per the user's feedback until we get all the
requirements from the user.
6. Once, all requirements are fulfilled and the client will agree, then
the last step will be signed off (Sign off - Deliver the product and
finish the contract)
 Advantages of Prototype Model:
1. Users are actively involved in the development
2. Missing functionalities can be identified easily
3. Based on user feedback, the SRS document is finalized

Disadvantages of Prototype Model:

1. Sample model is not used for actual implementation
2. Scope of the system may expand beyond original plans

==========================================================================
===
6. V Model:
• In parallel to the software development phase, a corresponding series of
test phases also runs in this model. Each stage ensures a specific type of
testing is done, and once that testing is passed, only then the next phase
starts.
• When the requirement is well-defined and ambiguous (uncertain), we use V-Model.
• It is also known as Verification and Validation model.

Verification: Design Phase:

1. Verification checks whether we are building the right product
(software) (to check whether the specific requirements will meet or
not).
2. Focus on documentation. Testing the project-related documents are called static
testing.
3. Verification does not involve the code execution.
4. Verification typically involves Static Testing techniques like:
✓ Reviews
✓ Walkthroughs
 ✓ Inspections
5. There are the various phases of the Verification Phase in the V-model,
i. BRS (Business Requirement Specification):
o This is the first step where product requirements are
understood from the customer's side. This phase contains
detailed communication to understand customers’
expectations and exact requirements.
ii. SRS (Software Requirement Specification):
 o In this stage system engineers analyze and transfer the
business of the proposed system to SRS by studying the
user requirements document (BRS).
iii. HLD (High-Level Design):
o High-level design (HLD) explains the architecture that
would be used to develop a system.
o The architecture diagram provides an overview of an
entire system, identifying the main components that
would be developed for the product and their interfaces.
iv. LLD (Low-Level Design):
o In the module design phase, the system breaks down into
small modules.
o The detailed design of the modules is specified, which is
known as Low- Level Design

Coding Phase:
• After designing, the coding phase is started. Based on the requirements,
a suitable programming language is decided. There are some guidelines
and standards for coding. Before checking in the repository, the final build
is optimized for better performance, and the code goes through many
code reviews to check the performance.

Validation: Testing Phase:

1. Validation checks whether we are building the product (software)
right (to check whether we are developing the right software).
2. Focus on software.
3. Validation typically involves actual testing.
4. Takes place after verifications are completed.
5. Here we use the below Dynamic testing techniques:
✓ Unit Testing
✓ Integration Testing
 ✓ System Testing
✓ UAT

• Advantages of the V Model:

1. Testing is involved in each and every phase.
2. Every stage of the V-shaped model has strict results, so it is easy to control.
3. Testing and verification take place in the early stages.
4. Good for small projects, where requirements are static and clear.
5. Testing Methods like planning, test designing happens well before coding.
 • Disadvantages of the V Model:
1. Documentation is more.
2. If any changes happen in the midway, then the test documents along with
the
required documents, must be updated.
3. Initial investment is more.
4. Very rigid and least flexible.
5. Software is developed during the implementation stage, so no
early prototypes of the software are produced.

When to use V Model:

1. The V-shaped model should be used for small to medium-sized
projects where requirements are clearly defined and fixed.
2. Experienced technical resources are available

Is Waterfall Model and V Model being the same.?:

V Model is the updated version of Waterfall Model.

==========================================================================
===

Static Testing Techniques:

We use Static Testing Techniques on the Verification side in V Model.
1. Review
2. Walkthrough
3. Inspection

1. Review:
 Review conducts on documents to ensure correctness and completeness.

• Requirement reviews
• Design reviews
• Code reviews
• Test Plan reviews
• Test cases reviews etc.

2. Walkthrough:
 • It is an informal review.
• It is not pre-planned and can be done whenever required.
• Author reads the documents or code and discusses it with peers.
• Also, the walkthrough does not have minutes of the meeting.

3. Inspection:
• It is the most formal review type.
• Inspection will have a proper schedule which will be intimated
via email to the concerned developer/testers.
• In which at least 3-8 people sit in the meeting 1-reader, 2-
writer, 3-moderator plus concerned people.

Dynamic Testing Techniques:

We use Dynamic Testing Techniques on the Validation side in V Model.

1. Unit Testing
2. Integration Testing
3. System Testing
4. User Acceptance Testing (UAT)

Why do we need testing in the SDLC process?

• The testing phase is very important to check whether the developed software
is a quality product and matches with a design document. This stage confirms
that the developed product meets the requirements defined by clients. In
this stage, we perform different types of tests including unit testing,
acceptance testing, system testing, etc. The software testing team works
together with developers to identify and resolve software bugs and provides
the Quality Application to the client.
 Explain the software release process in brief:
• In the software release process, the project manager makes a release team
consisting of developers, testers, project management executives. This team
goes to customers’ places and deploys software products or they just deploy
the software at the client’s server. The team also delivers some training to
customers regarding the functioning of software if required.
 What is the difference between SDLC and STLC?
• Software Development Life Cycle involves the complete Verification and
Validation of a Process or a Project.
• Whereas Software Testing Life Cycle involves only Validation.

==========================================================================
===

STLC - Software Testing Life Cycle:

DESCRIPTION

1. Requirement Analysis
2. Test Planning
3. Test Design
4. Test Environment Setup
5. Test Execution
6. Test Closure
 1. Requirement Analysis: In this phase, the requirements documents are
analyzed and validated, and the scope of testing is defined.
2. Test Planning: In this phase, test plan strategy is defined, estimation of
test effort is defined along with automation strategy and tool selection is
done.
3. Test Design: In this phase test cases are designed; test data is
prepared, and automation scripts are implemented.
4. Test Environment Setup: A test environment closely simulating the
real-world environment is prepared.
5. Test Execution: To perform actual testing as per the test steps.
6. Test Closure: Test Closure is final stage of STLC where we will make all
details documentations which are required submit to client at time of
software delivery. Such as test report, defect report, test cases summary,
RTM details, release note.

==========================================================================
===
What is Test Closure?

Test Closure is final stage of STLC where we will make all details documentations
which are required submit to client at time of software delivery. Such as test
report, defect report, test cases summary, RTM details, release note.
What is the list of test closure documents?

It includes,

1. test case documents, (i.e., Test Case Excel sheet we prepare during actual testing)
2. test plan, test strategy,
3. Release note
4. test scripts,
5. test data,
6. traceability matrix, and
7. test results and reports like bug report, execution report etc.

Explain about each of test closure documents?

1. test case documents: Include detail test cases that can be reviewed.
2. test plan, test strategy: Included Entire Test planning, Strategies, Schedules Etc.
3. Release note: Includes all release related data like Software version,
supporting hardware details, known issues, closed issues, added features
etc.
4. test scripts: It contain Scripts in terms of automation testing.
5. test data: It contains which date you were used while testing.
6. traceability matrix: traceability includes all pass and fail test cases matrix and defect
records.
7. test results and reports like Bug Report and Execution Report: Test
Results shows entire summery on tested applications.

What is a Build?
• It is a number/identity given to Installable software that is given to the
testing team by the development team
 What is release?
• It is a number/ identity given to Installable software that is handed over to
the customer/client by the testing team (or sometimes directly by the
development team)

What is deployment?
• Deployment is the mechanism through which applications, modules,
updates, and patches are delivered from developers to end-
user/client/customer.

When will actual testing start?

 • Testing includes many activities in each phase of the development life
cycle as requirement analysis, creating test plan, test design, etc. So,
software testing activity should be started as soon as possible (After
requirement baseline) in the development life cycle.

Which tools you are using to write review test cases?

• Generally, in our company we preferred to write down test cases in an
excel sheet because it’s very easy and user-friendly. After completion of
the review, we will add that test cases in TestLink for future tracking
purposes.
• TestLink
Version: -1.9.13 (Strombringer)

What is a different attribute of test cases?

1. TestCaseID - A unique identifier of the test case.
2. Test Summary - One-liner summary of the test case.
3. Description - Detailed description of the test case.
4. Prerequisite or pre-condition - A set of prerequisites that must be
followed before executing the test steps.
5. Test Steps - Detailed steps for performing the test case.
6. Expected result - The expected result in order to pass the test.
7. Actual result - The actual result after executing the test steps.
8. Test Result - Pass/Fail status of the test execution.
9. Automation Status - Identifier of automation - whether the application is automated
or not.
10. Date - The test execution date.
11. Executed by - Name of the person executing the test case.

What is the code freeze?

 • Code freeze means Finalization of code and no further changes will be happening in
code.

How would you define that testing is sufficient and it’s time to enter the
Test Closure phase? Or when we should stop testing?
• Testing can be stopped when one or more of the following conditions are met,
1. After test case execution – The testing phase can be stopped when
one complete cycle of test cases is executed after the last known
bug fix with the agreed-upon value of pass percentage.
2. Once the testing deadline is met - Testing can be stopped after
deadlines get met with no high priority issues left in the system.
 3. Based on Mean Time Between Failure (MTBF)- MTBF is the time
interval between two inherent failures. Based on stakeholders’
decisions, if the MTBF is quite a large one can stop the testing
phase.
4. Based on code coverage value – The testing phase can be stopped
when the automated code coverage reaches a specific threshold
value with sufficient pass percentage and no critical bug.

What is your (QA/Tester) basic roles and responsibility?

• Understanding & analyzing Test Requirements.
• Prepare Test Scenarios for individual modules.
• Writing & review the Test Cases as per requirements.
• Test cases execution.
• Defect creation, Defect verification, and QA task management.
• Weekly Test status reporting.
• Continuous Communication with the team & client.
• Preparation of Test Plan Documentation (if have 3+ years exp).

How to write effective test cases?

• Effective test cases have been considered
1. Test cases should be simple to understand which helps to review and retest.
2. Test cases should focus on end-user requirements.
3. Test cases should be able to find defects.
4. Test cases should contain proper steps and test data.
5. Test cases should be Re-usable
6. Test cases should express expected and actual results.

Mention what are the types of documents in QA?

• The types of documents in QA are
• Requirement Document
• Test Metrics
• Test cases and Test plan
• Task distribution flow chart
• Transaction Mix
• User profiles
• Test log
• User profiles
• Test incident report
 • Test summary report

Explain what should your QA documents include?

• QA testing document should include
• List the number of defects detected as per severity level
• Explain each requirement or business function in detail
• Inspection reports
• Configurations
• Test plans and test cases
• Bug reports
• User manuals
• Prepare separate reports for managers and users

==========================================================================
===

HERE WE NEED TO CREATE AND ADD TESTING TYPES IMAGES:

Types of Software Testing:

1. Functional testing: Functional testing involves validating the functional
specifications of the system.
2. Non-Functional testing: Non-Functional testing includes testing the
non-functional requirements of the system like performance, security,
scalability, portability, endurance etc.

Methods of Testing (Testing Methods) (White box, Black box, Grey box)
1. Black Box testing
 2. White Box Testing
3. Grey Box Testing

Black Box Testing:

✓ Black box testing is the testing of requirements and functionality

without knowledge of internal content. Inputs are fed into the
system and outputs are determined expected or unexpected.
White Box Testing:

✓ White box testing is testing based on knowledge of the internal

logic (algorithms) of an application’s code. It’s an approach that
attempts to cover the software’s internals in detail. White box
testing is also known as ‘glass box testing’, ‘clear box testing’,
‘transparent box testing’, and ‘structural testing’.

Grey Box Testing:

✓ Grey box testing uses a combination of black and white box testing.
Grey box test cases are designed with knowledge of the internal
logic (algorithms) of an application’s code, but the actual testing is
performed as the black box. Alternately a limited number of white-
box testing is performed followed by conventional black-box testing
 Levels of Software Testing:
1. Unit Testing
2. Integration Testing
3. System Testing
4. User Acceptance Testing (UAT)

1. Unit Testing:
• A unit is a single component or module of software.
• Unit testing conducts on a single program or single module.
• Unit testing is a white box testing technique.
• The developers conduct Unit testing.

• Unit Testing Techniques:

✓ Basis path testing
✓ Control structure testing
✓ Conditional coverage
✓ Loops coverage
✓ Mutation testing.

2. Integration Testing:
• Integration testing performed between two or more modules.
• Integration testing focuses on checking data communication
between multiple modules.
• Integration testing is a white box testing technique.
• Integration testing conducted by the tester at the application level (at the UI
level).
• Integration testing conducted by the developer at the coding level.

• Types (Techniques) of Integration Testing:

✓ Incremental integration testing

a. Top-down approach
 b. Bottom-up approach
c. Sandwich/Hybrid approach

✓ Non-incremental integration testing

3. System Testing: (This is the actual area where testers are mostly involved.)
 • Testing the overall functionality of the application with
respective client requirements.
• It is a black box technique.
• The testing team conducts System testing.
• After completion of component (unit) and integration level
testing, we start System testing.

• System Testing focuses on the below aspects (types):

✓ User Interface Testing (GUI)
✓ Usability Testing
✓ Functional Testing
✓ Non-functional Testing

In-System Testing we both perform some functional, non-functional testing.

✓ User Interface Testing (GUI):
• Graphical user interface testing or GUI testing is a process of
testing the user interface of an application.
 • A graphical user interface includes all the elements such as
menus, checkboxes, buttons, colors, fonts, icons, content, and
images.
• GUI testing mostly focuses on the front-end part.
• Here we mainly focus on the look and feel of the application.

✓ Usability Testing:
• During this testing validates application provide context-sensitive
help or not to the user.
• Checks how easily the end-users can understand and operate the
application is called usability testing.
• This is like a user manual so that the user can read the manual and proceed
further.

✓ Functional Testing:
• In functional testing, we check the functionality of the software.
• Functionality describes what software does. Functionality is
nothing but the behavior of the application.
• Functional testing talks about how your feature should work.
I. Objective Properties Testing
II. Database Testing: DML operations like insert, delete, update, select
 III. Error Handling
IV. Calculation/Manipulations Testing
V. Links Existence and Links Execution
VI. Cookies and Sessions

i. Objective Properties Testing:

✓ Check the properties of objects like enable, disable, visible, focus, etc.

ii. Database Testing:

Checking database operations concerning user operations,

✓ DML operations like insert, delete, update, select

✓ Table and column level validations (Column type, Column
length, number of columns...)
✓ Relation between the tables (Normalization)
✓ Functions
✓ Procedures
✓ Triggers
✓ Indexes
✓ Views, etc.

iii. Error Handling:

✓ The tester verifies the error messages while performing
incorrect actions on the application.
✓ Error messages should be readable.
✓ Use understandable/simple language.

iv. Calculation/Manipulations Testing:

✓ The tester should verify the calculations.
v. Links Existence and Links Execution:
✓ Where exactly the links are placed - Links existence.
✓ Links are navigating to the proper or not - Links Execution
✓ Types of Links:
i. Internal Links
 ii. External Links
iii. Broken Links

vi. Cookies and Sessions:

✓ Temporary files are created by Browser while browsing
the pages on the internet.
✓ Sessions are time slots created by the server. The
session will be expired after some time. (If you are idle
for some time.)

Types of Functional Testing:

• Smoke
• Sanity
• Unit
• Integration
• System
• UAT (User Acceptance Testing)
• Retesting
• Regression Testing

✓ Non-functional Testing

Non-functional testing, we check the performance of the software

under different conditions.

Types of Non-functional Testing:

a. Performance Testing
▪ Load Testing
▪ Stress Testing
▪ Volume Testing
b. Security Testing
c. Recovery Testing
d. Compatibility Testing
e. Configuration Testing
f. Installation Testing
g. Sanitation / Garbage Testing
h. Endurance testing
i. Scalability testing.
a. Performance Testing: Speed of the application.
✓ Load: Gradually increase the load on the application slowly
then check the speed of the application. Here load means
data.
✓ Stress: Suddenly increase/decrease the load on the
application and check the speed of the application.
✓ Volume: Check how much data can handle by the
application. Here we apply huge data to system until it gets
hang. Generally, this test is performed to check how system
is responding to bulk of user at a time.

b. Security Testing: To check how secure our application is.

✓ Authentication: User is valid or not.
✓ Authorization / Access control: Permissions of the valid user.

c. Recovery Testing:
✓ Check the system change from abnormal to normal.

d. Compatibility Testing:
✓ Forward Compatibility
✓ Backward Compatibility
✓ Hardware Compatibility (Configuration testing)

e. Configuration Testing:
✓ It is a combination of hardware and software, in which we
need to test whether they are communicating properly or
not. In simple words, we check how the data is flow from one
 module to another.

f. Installation Testing:
✓ Check screens are clear to understand.
✓ Screens navigation
✓ Simple or not.
✓ Un-installation.
 g. Sanitation / Garbage Testing
✓ If any application provides extra features/functionality,
then we consider them a bug.

4. UAT (User Acceptance Testing):

• User Acceptance Testing (UAT) is a type of testing performed by the end-
user or the client to verify/accept the software system before moving the
software application to the production environment. UAT is done in the
final phase of testing after functional, integration, and system testing are
done
• Here are two types of UAT:
o Alpha Testing:
Generally alpha testing is performed in our side as per client
environment. Post Alpha Testing the software is ready for
deployment into client Environment.
o Beta Testing:
Beta Testing Done into client side, where whole system is tested
as per the client Environment. Generally, Beta and Alpha testing
are done by two separate team. Largely it is done by Team who
is functional user of that software. As a QA Team we assist them
as per request from the client.

==========================================================================
===

Functional Testing Vs. Non-

Functional Testing: Functional

Testing:

• Validates functionality of Software.

• Functionality describes what software does.
 • Concentrates on user requirements.
• Functional testing takes before Non-functional testing.

Non-Functional testing:

• Verify the performance, security, reliability of the software.

• Non-functional testing describes how the software works.
• Concentrates on user expectations.
• Non-functional testing performed after finishing functional testing.
 ==========================================================================
===

Test Techniques / Test Design Techniques / Test Data / Test

Written Techniques: Used to prepare data for testing.

✓ Data
✓ Coverage (cover every area/functionality of the feature)

• Test Design Techniques (During Designing Test Cases) (for Black Box Testing):
1. Equivalence Class Partitioning (ECP)
2. Boundary Value Analysis (BVA)
3. Decision Table
4. State Transition
5. Error Guessing

1. Equivalence Class Partitioning (ECP):

a. Partition data into various classes and we can select data according
to class then test. It reduces the number of tests cases and saves time
for testing.
b. Value Check.
c. Classify/divide/partition the data into multiple classes.
2. Boundary Value Analysis (BVA):

a. Mainly we focus on boundaries of the value.

b. Here we consider 6 factors: Min, Min + 1, Min - 1, Max, Max + 1, Max – 1.
*** In Input Domain Testing mostly we use ECP and BVA techniques.

*** Input Domain testing: The value will be verified in the textbox/input fields.

3. Decision Table:

a. Decision Table is also called a Cause-Effect Table.

b. This technique will be used if we have more conditions and corresponding actions.
c. In the Decision table technique, we deal with combinations of inputs.
d. To identify the test cases with a decision table, we consider conditions and
actions.
e. If we have a greater number of conditions/actions, then we use the
decision table technique.

Example for Decision Table:

• Take an example of transferring money online to an account
that is already added and approved.
• Here the conditions to transfer money are,
1. Account already approved.
2. OTP (one-time-password) matched.
3. Sufficient money in the account.
 • And the actions performed are,
1. Transfer money.
2. Show a message as the insufficient amount.
3. Block the transaction in case of a suspicious transaction.

4.State Transition:

a. In State Transition Technique input is given in sequence one step at

a time. Under this technique we can test for limited set of input
values.
b. The technique should be used when the testing team wants to test sequence of
events
which happen in the application under test.
c. The tester can perform this action by entering various input conditions in a
sequence.
d. In the State transition technique, the testing team provides positive
as well as negative input test values for evaluating the system
behavior.
 5.Error Guessing:

a. Error guessing is one of the testing techniques used to find bugs in a

software application based on the tester's prior experience.
b. In Error guessing we do not follow any specific rules.
c. It depends on Tester’s Analytical skills and experience.
d. Some of the examples are,
• Submitting a form without entering values.
• Entering invalid values such as entering alphabets in the numeric field.

==========================================================================
===
Test Plan Vs. Test Strategy:

What is Test Plan/Test Planning:

• The test plan serves as a blueprint to conduct software testing activities
as a defined process, which is monitored and controlled by the test
manager.
• A Test Plan is a detailed/formal document that describes the test
strategy, objectives, schedule, estimation, deliverables, and resources
required to perform testing for a software product. Test Plan helps us
determine the effort needed to validate the quality of the application
under test.
 Importance of Test Plan:
• 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.
• Test Plan ensures that your Testing Project is successful, and it helps to control the risk

When To Write Test Plan:

• Software Testing should start very early stage in the project life cycle as
soon as there's a Functional Requirements Document (FRD). The STLC
consists of a series of phases carried out methodically to help certify the
Application Under Test.

How to write a Test Plan:

• Analyze the product
• Design the Test Strategy
• Define the Test Objectives
• Define Test Criteria
✓ Suspension Criteria
✓ Exit Criteria
• Resource Planning
• Plan Test Environment
• Schedule & Estimation
• Determine Test Deliverables
 Test Plan IEEE 829 Format (Different Test Plan Attributes):
1. Test Plan Identifier
2. References
3. Introduction
4. Software Risk Issues
5. Test Items
6. Approach
7. Features to be Tested
8. Features not to be Tested
9. Item Pass/Fail Criteria
10. Suspension Criteria and Resumption Requirements
11. Environmental Needs
12. Staffing and Training Needs
13. Responsibilities
14. Schedule
15. Test Deliverables
16. Approvals
17. Glossary
18. Remaining Test Tasks
19. Planning Risks and Contingencies
 Test Plan template Contents: (WHAT to test, HOW to test, WHEN to test):
1. Overview
2. Scope
✓ Inclusions
✓ Exclusions
✓ Test Environments
3. Test Approach/Strategy
4. Defect Reporting Procedure
5. Roles/Responsibilities
6. Test Schedule
7. Test Deliverables
8. Pricing
9. Entry and Exit Criteria
10. Suspension and Resumption Criteria
11. Tools
12. Risk and Mitigations
13. Approvals

==========================================================================
===

Use Case, Test Scenario, and Test Case:

1. Use Case: (Describes the requirement)

a. Use case describes the requirement.
b. Use case contains three items.
i. Actor, who is the user, who can be a single person or a
group of people, interacting with a process.
ii. Action, who is to reach the final outcome.
iii. Goal/Outcome, which is the successful use outcome.
2. Test Scenario: (What to test)
a. A possible area to be tested (What to test).
b. Test Scenario is an overview of any functionality in a software
application that is under testing.
c. A test scenario is derived from a use case.
d. We can say the test scenario contains all the conditions, which can
be determined the testing coverage against the business
requirement.

3. Test Case: (How to test)

a. It is detailed description of any functionality for how to test.
b. A Test Case is a set of actions executed to validate a particular
feature or functionality of your software application.
c. Step by step actions to be performed to validate the functionality of AUT (How to
test).
d. Test case contains test steps, expected result, and actual result.
e. It contains many details like, pre-condition, test data, expected result,
actual result, status etc.
• Use Case V/s Test Case
a. Use Case: Describes functional requirement, prepared by Business Analyst (BA).
b. Test Case: Describes Test Steps/Procedure, prepared by Testers.

• Test Scenario V/s Test Case

a. Test Scenario is "What to be tested" and Test Case is "How to be tested".
• Test Suite (Test Bed):
a. Test Suite is a group of test cases that belong to the same category.

==========================================================================
===

• Test Case (Writing) Contents:

1. Test Case ID
2. Test Case Title
3. Description
4. Pre-condition
5. Priority (P0, P1, P2, P3) - order (P0 - Smoke and Sanity, P1 -
Regression, P2 - Functional, P3 - UI)
6. Requirement ID
7. Steps/Actions
8. Expected Result
9. Actual Result
10. Test Data
[ADD TEST CASE BHUSHAN TEMPLATE]
• Test Case Template:

==========================================================================
===

• Test Case V/s Test Scenario

==========================================================================
===

• Test Environment:
1. Test Environment is a platform specially built for test case execution on the software
product.
2. It is created by integrating the required software and hardware along
with proper network configuration.
3. Test environment simulates production/real-time environment.
4. Another name for the test environment is Test Bed.
5. This is nothing, but an environment created to execute the Test Cases.

==========================================================================
===
• Test Execution:
1. To perform actual testing as per the test steps. i.e., During this phase
test team will carry out the testing, based on the test plans and the test
case prepared.
2. Entry Criteria (Inputs): Test Cases, Test Data, and Test Plan.
3. Activities:
✓ Test cases are executed based on test planning.
✓ Status of test cases is marked, like passed, failed, blocked, run, etc.
 ✓ Documentation of the test results and log defects for failed cases are done.
✓ All the clocked and failed test cases are assigned bug ids.
✓ Retesting once they are fixed.
✓ Defects are tracked till closure.
4. Deliverables (Outputs): Provides defect report and test case execution
report with completed results.

• Guidelines for Test Execution:

1. The build being deployed to the QA environment is the most
important part of the test execution cycle.
2. Test execution is done in Quality Assurance (QA) environment.
3. Test execution happens in multiple cycles.
4. Test execution phase consists of Executing the test cases + test scripts (if
automation).

==========================================================================
===

• Requirement Traceability Matrix (RTM):

1. RTM Describes the mapping of Requirements with the Test cases.
2. The main purpose of RTM is to see that all the Test cases are covered so
that no functionality should miss while doing Software testing.
3. RTM Parameters include:
✓ Requirement ID
✓ Requirement Description
✓ Test Case IDs
[Image: Another perfect example for RTM]

Which are the different types of RTM?

• Forward Traceability: This document is used to map the requirements to
the test cases. This will help you in ensuring that your project is moving in
the right direction. It will also ensure that all the requirements are tested
thoroughly.
• Backward Traceability: When you map your test cases with the
requirements, you will be creating a Backward Traceability Matrix. This
will help you in making sure that you are not expanding the scope of the
project by adding features or functionality that was not a part of the
original requirements.
• Bidirectional Traceability: When you are mapping the requirements to
test cases for Forward traceability and test cases to requirements for
Backward traceability in a single document, it is called a Bidirectional
Traceability Matrix. This document will help you in ensuring that all the
 specified requirements have corresponding test cases and vice versa.

How to create a traceability matrix for requirements?

1. Set goals: The first step you need to take before you actually create an
RTM is to define your goals. It will help you in answering the question,
what purpose will the RTM serve? Here is an example of a goal I want to
create a traceability matrix to keep track of test cases and bugs that will
be impacted if there are any changes made to the requirements.
2. Collect artifacts: As you have defined your goal, now you need to know
which artifacts you will need in order to accomplish your goal. For
creating a Requirements Traceability Matrix, you will need:
• Requirements
• Test cases
✓ Test results
✓ Bugs
The next step will be to collect these artifacts. For this, you will have to
access the latest version of requirements and make sure each
requirement has a unique identification ID. You can then gather all the
test cases from the testing team. If the testing is going on or it has been
completed, you will have access to the test results as well as the bugs
found.

3. Prepare a traceability matrix template: For a requirements traceability

matrix template, you can create a spreadsheet in excel and add a column
for each artifact that you have collected. The columns in the excel will be
like: Requirements, Test cases, Test results

4. Adding the artifacts: You can start adding the artifacts you have to the
columns. You can now copy and paste requirements, test cases, test
results & bugs in the respective columns. You need to ensure that the
requirements, test cases, and bugs have unique ids. You can add separate
columns to denote the requirement id such as Requirement_id,
TestCaseID, BugID, etc.

5. Update the traceability matrix: Updating the traceability matrix is an

ongoing job which continues until the project completes. If there is any
 change in the requirements, you need to update the traceability matrix.
There might be a case that a requirement is dropped; you need to update
this in the matrix. If a new test case is added or a new bug is found, you
need to update this in the requirements traceability matrix.

==========================================================================
===

Error, Bug/defect, and Failure:

• Error: It is a human mistake. We can say a mistake was made by the developer.
• Bug/defect: It is the difference between the expected and actual results.
• Failure: It comes in a customer/client environment. Where applications
are unable to perform their functions.
 Why the software has bugs?
• Software complexity
• Programming errors
• Changing requirements
• Lack of skilled testers

Why does defect/bug occur?

• In software testing, the bug can occur for the following reasons:
1. Wrong coding
2. Missing coding
3. Extra coding

==========================================================================
===

Defects/Bugs/Issues:
1. Any mismatched functionality found in an application is called a Defect/Bug/Issue.
2. During Test Execution Test engineers are reporting mismatches as
defects to developers through templates or using tools.
3. Defect Reporting Tools:
o Clear Quest
o DevTrack
o Jira
o Quality Center
o Bug Zilla etc.
 Test Management tools and Bug tracking tools are completely different.
Test (Case) Management Tool Vs. Project Management Tool Vs. Bug Tracking Tool.

==========================================================================
===

Defect Report Contents:

1. Defect_ID
2. Defect Description
3. Version
 4. Steps
5. Data Raised
6. Reference
7. Detected By
8. Status
9. Fixed By
10. Date Closed
11. Severity
12. Priority

==========================================================================
===

Defect Classification / Categorization:

• Severity
1. Blocker (Show stopper)
2. Critical
3. Major
4. Minor

• Priority
1. P1 (High)
2. P2 (Medium)
3. P3 (Low)
 Defect Severity: S-T (S-S-T) (Severity-System)
• Severity is assigned/given by the QA Testers.
• It affects the functionality.
• Severity describes the seriousness of the defect and how much impact
on Business workflow (functionality). It is categorized into Blocker,
Critical, Major, Minor.

Defect Priority: D-P (D-I-P) (Priority-People)

• Priority is mostly given/assigned by the developer.
• It affects business values.
• Priority describes the importance of defects. The defect which is urgent for repair.
• Defect Priority states the order in which a defect should be fixed.
• Defect priority can be categorized into three categories:
1. P1: The defect must be resolved immediately as it affects the
system severely and cannot be used until it is fixed.
2. P2: It can wait until a new version/build is created.
 3. P3: The developer can fix it in later releases.

[Image: Example]

==========================================================================
===
 Defect Resolution:

After receiving the defect report from the testing team, the development
team conducts a review meeting to fix defects. Then they send a Resolution
Type to the testing team for further communication.

Resolution Types:
1. Accept
2. Reject
3. Duplicate
4. Enhancement
5. Need more information
6. Not Reproducible
7. Fixed
8. As Designed.

==========================================================================
===

Defect Life Cycle/Bug Life Cycle:

• The Bug is the informal name of defects, which means that software
or application is not working as per the requirement.
• In software testing, a software bug can also be an issue, error, fault,
or failure. The bug occurred when developers made any mistake or
error while developing the product.
==========================================================================
===

Test Cycle Closure:

a. Activities:

• Evaluate cycle completion criteria based on Time, Test coverage,

Cost, Software Critical Business Objectives, Quality.
• Prepare test metrics based on the above parameters.
• Document the learning out of the project.
• Prepare Test summary report.
• Qualitative and quantitative reporting of quality of the work product to the
customer.
• The result analysis to find out the defect distribution by type and severity.

b. Deliverables:

• Test Closure report.

• Test metrics.

c. Test Metrics:
==========================================================================
===

QA/Testing Activities:
• Understanding the requirements and functional specifications of the application.
• Identifying required Test Scenarios.
• Designing Test Cases to validate the application.
• Setting up Test Environment (Test Bed).
• Execute Test Cases to valid applications.
• Log Test results (How many tests cases pass/fail.)
• Defect reporting and tracking.
• Retest fixed defects of the previous build.
• Perform various types of testing in the application.
• Reports to Test Leas about the status of assigned tasks.
• Participated in regular team meetings.
• Creating automation scripts.
• Provides recommendations on whether or not the application/system is ready for
 production.

==========================================================================
===
 Software Testing Terminologies: (Other Types of Testing):
a. Regression Testing
b. Re-testing
c. Exploratory testing
d. Adhoc Testing
e. Monkey Testing
f. Positive Testing
g. Negative Testing
h. End to End Testing
i. Globalization and Localization Testing

a. Regression testing:

Testing conducted on modified build (updated build) to make sure there will
not be an impact on existing functionality because of changes like
adding/deleting/modifying features. Also, we can say Smoke Testing is a
small part of regression testing.

1. Unit regression testing type:

i. Testing only the changes/modification done by the developer.

2. Regional Regression testing type:

i. Testing the modified module along with the impacted modules.
ii. Impact Analysis meeting conducts to identify impacted
modules with QA and developer.

3. Full Regression type:

i. Testing the main feature and remaining part of the application.
ii. Example: The developer has done changes in many
modules, instead of identifying impacted modules, we
 perform one round of full regression.

• When we performed regression testing:

✓ After Defect get Fixed and Retesting is done.
✓ Modification, Updating, change request into Existing functionality.
✓ After addition of new functionality.
✓ Before release.
✓ After release.
✓ Data Migration.
 ✓ After change in Environment

b. Re-Testing:
1. Whenever the developer fixed a bug, the tester will test the bug fix called re-
testing.
2. Tester closes the bug if worked otherwise re-open and send to a developer.
3. To ensure that the defects which were found and posted in the
earlier build were fixed or not in the current build.
4. Example:
i. Build 1.0 was released, test team found some defects
(Defect ID 1.0.1, 1.0.2) and posted them.
ii. Build 1.1 was released, now testing the defects 1.0.1 and
1.0.2 in this build is retesting.

Re-Testing VS. Regression Testing:

Example of Re-Testing Vs. Regression Testing:
Smoke Vs. Sanity Testing:
c. Exploratory testing:
• We have to explore the application, understand completely and test it.
• Understand the application, identify all possible scenarios,
documents it, then use it for testing.
• We do exploratory testing when the application is ready but there is no
requirement.
• Test Engineer will do exploratory testing when no requirement is.

Drawbacks of Exploratory testing:

• You might misunderstand any feature as a bug (or) any bug as a
feature since you do not have requirements.
• time-consuming.
• If there is any bug in the application, you will never know about it.
d. Adhoc Testing:
• Testing application randomly without any test cases or any
business requirement document.
• Adhoc testing is an informal testing type with an aim to break the system.
 • Tester should have knowledge of application even though he does
not have requirements/test cases.
• This testing is usually an unplanned activity.

e. Monkey/Gorilla Testing:
• Testing applications randomly without any test cases or any business
requirement.
• Adhoc testing is an informal testing type with an aim to break the system.
• Tester does not have knowledge of the application.
• Suitable for gaming applications.

Adhoc Testing Vs. Monkey Testing Vs. Exploratory Testing

f. Positive Testing:
• Testing the application with valid inputs is called positive testing.
• It checks whether an application behaves as expected with positive inputs.
g. Negative Testing
• Testing the application with invalid inputs is called negative testing.
• It checks whether an application behaves as expected with the negative
testing.
 Positive Vs. Negative Test Cases:
For example, if a text box is listed as a feature and in FRS it is
mentioned as a Text box that accepts 6-20 characters and only
alphabets.

a. Positive Test Cases:

1. Textbox accepts six characters.
2. Textbox accepts up to 20-character lengths.
3. Textbox accepts any value between 6-20 characters long.
4. Textbox accepts all alphabets.

b. Negative Test Cases:

1. Textbox should not accept less than 6 characters.
2. Textbox should not accept characters more than twenty
characters.
3. Textbox should not accept special characters.
4. Textbox should not accept numerically.

h. End to End Testing:

1. Testing the overall functionalities of the system including the data
integration among all the modules are called end-to-end testing.
i. Globalization and Localization Testing:

============================================================
=================

Agile – Scrum

Agile Model/Agile Methodology/Agile Process:

• Agile is an approach to software development under which
requirements and solutions evolve through the collaborative effort of
self-organizing and cross-functional teams and their customer/end
customer.
• Both development and testing activities are done parallelly and collaboratively.
• In Agile, instead of BA’s, the Product Owner collects and discusses with
the customer/end client.
 • It’s a Quick assign Quick Design model.
• Agile model is combination of Iterative and Incremental model.

Agile Principles:
• Requirement changes are accepted from the customer.
• So, the customer no need to wait, which provides customer satisfaction.
• We develop, test, and release pieces of software to the customer with some features.
 • The Whole team works together toward achieving one goal.
• Here we focus on F2F conversation.
• We follow iterative and incremental nature.

Advantages of Agile Model:

• We can accept/accommodate the required changes in the middle of development.
• Release will be very fast.
• So, the customers no need to wait for a long time.
• Create good communication between teams.
• Easy model to adapt.
• It is suitable for both small and large software development projects.

Disadvantages of Agile Model:

• Less focus on design and documentation, as we focus on fast delivery of the software.
• Project can easily go out of track if the customer representative is not
clear about what final outcome they want.

Development Task:
• Review the story
• Estimate the story
• Design
• Code
• Unit Testing
• Integration Testing etc.

QA Task:
• Review the story
• Test Cases
• Test Scenarios
• Test Data
• Test Review
• Test Environments
• Execute Test Cases
• Report Bugs etc.

==========================================================================
===
 Scrum: Scrum is a framework through which we build the software product
by following Agile Principles.

Scrum workflow -

User Stories → Product Backlog → Sprint Planning → Sprint Backlog →

Sprint (1 – 3 weeks and daily scrum meetings) → Product → Sprint Review
and retrospective Meeting

Scrum Team:

Scrum Team involves,

1. Product Owner
2. Scrum Master
3. Development Team
4. QA Team

1. Product Owner:
• Product Owner is the First Point of Contact.
• He will get input from the customers.
• Defines the feature of the product.
• Prioritize the features according to the market value.
• Adjust features or priority every iteration, as needed.
• Product Owner can Accept or Reject the work result.
• He will define features of the product in the form of User Stories or Epics.
2. Scrum Master:
• Scrum Master has the main role of facilitating and driving the Agile Process.
• He acts like a manager/team lead for Scrum Team.
• He leads over all the Scrum ceremonies.

3. Developers and QA:

• Develop and test the software.
 Advantages of Scrum (i.e., Agile Scrum):
• The quality can be ensured because each and every Sprint will be tested multiple
times.
• The requirement can be accepted at any level of project maintenance.
• All the participating in Scrum meetings so that transparency can be maintained.
• Each and every Sprint we are delivering to the client so we can
maintain the customer’s satisfaction and we can avoid the delivery risk
of the project.
• Helps to save time and cost of the project.

==========================================================================
===

Definition of Ready (DOR):

If the below points are ready or clear regarding User Stories, is DOR.

• User Story is clear.

• User Story is testable.
• User Story is feasible.
• …………………………..
• …………………………..
• …………………………..
• …………………………..

Definition of Done

(DOD): It is achieved

when,
 • The story is developed completely
• Testing (QA) complete
• Regression around the story is complete
• The story meets and satisfies the acceptance criteria
• The feature is eligible to be deployed in production.

==========================================================================
===

Scrum Terminologies:

Product Backlog: Contains a list of all requirements (like user stories and
epics). Prepared by Product Owner.
 Epic: Collection of related user stories. Epic is nothing but a large (high level) requirement.
User Story: A feature/module in a software. Define the customer needs. It is
nothing but the phrasing of the requirement in the form of a story.
Task: To achieve the business requirements development team create tasks.
Sprint/Iteration: Period/time to complete (means development and testing)
the user stories, decided/selected by the Product Owner and Team. It is usually
for 2-4 weeks of time.
Sprint Backlog: List of committed stories by the Developers and QAs for a specific Sprint.
Sprint Planning Meeting: This is the meeting with the team, to define what
can be delivered in the Sprint and its duration.
Sprint Review Meeting: Here we walkthrough and demonstrate the feature or
story implemented by the team to the stakeholder.
Sprint Retrospective Meeting: Conducts after completion of Sprint only. The
entire team including the Product Owner and Scrum Master should participate.
They discuss majorly on 3 things,
✓ What went well?
✓ What went wrong?
✓ Improvements are needed in the upcoming sprint.
Backlog Grooming Meeting:

• In this meeting, the scrum team along with the scrum master and product owner.
• The product owner presents the business requirements and as per
the priority team discussed over it and identifies the complexity,
dependencies, and efforts.
• The team may also do the story pointing at this stage.

Scrum Meeting/Scrum Call/Standup Meeting: This happens every day.

Points to be discussed in Daily stand-up meetings:
✓ What are we going to do today?
✓ What have I done yesterday?
✓ Any blockers/issues, due to which we are not able to proceed.

Story Point: Rough estimation given by Developers and QA in the form of the Fibonacci
series.
 Time Boxing in Scrum: Timeboxing is nothing but the Sprint which is the
specific amount of time to complete the specified amount of work.
Scum of Scrums:
• Suppose 7 teams are working on a project and each team has 7 members.
Each team leads its particular scrum meeting. Now to coordinate among
the teams a separate meeting has to be organized, thatmeeting is called
Scrum of Scrums.
• An ambassador (team leads) (a designated person who represents the
team) represents the team in the scrum of scrums.
• Few points discussed in the meeting are:
✓ The progress of each team, after the last meeting.
 ✓ The task is to be done before the next meeting.
✓ Issues that the team had faced while completing the last task.
Spike in Agile Scrum: It is a story that cannot
be estimated. Sprint Zero:
• Sprint zero usually takes place before the formal start of the project.
• This Sprint should be kept lightweight and relatively high level. It is all
about the origination of project exploration and gaining an understanding
of where you want to head while keeping velocity low.

Scrum Board/Task Board: It is showing the status of the story.

Scrum Board contains points like,

• User Story: It has the actual business requirement.

• To Do: Tasks that can be worked on.
• In Progress: Tasks in progress.
• To Verify/Testing: Tasks pending for verification or testing.
• Done: Completed tasks.

Release Candidate: The release candidate is a code/version/build released to

make sure that during the last development period, no critical problem is left
behind. It is used for testing and is equivalent to the final build.

Velocity:
• Velocity (is a metric) used to measure the units of work done
(completed) in the given time frame.
• We can say it is the sum of story points that the Scrum team completed over a
sprint.
Burndown Chart:
• Shows that how much work is pending/remaining in the Sprint. Maintain
by the Scrum Master daily. The progress is tracked by a Burndown chart.
• Burndown chart is nothing but, it shows that estimated Vs. actual efforts of the
Scrum Task.
• To check whether the stories are doing progress towards the
completion of the committed story points or not.
Burnup Chart: Amount of work completed within a project.

==========================================================================
===
Difference between Scrum and Waterfall:
• Feedback from the customers is received at an early stage in Scrum than Waterfall.
• New changes can easily accommodate in Scrum than the Waterfall.
• Rollback or accommodate new changes is easy in Scrum.
• Testing is considered a phase in the Waterfall, unlike Scrum.

Difference between Scum and Iterative Model:

• Scrum is a type of Iterative model, but it is an Incremental + Iterative
model. As we break the product into small Incremental builds and then
small pieces of builds are completed in multiple iterations.

Any other Agile Methodology apart from Scrum:

• Kanban, XP (Extreme Programming), Lean is another Agile Methodologies than
Scrum.

Other frameworks used in the agile model:

• There are some development and methodologies where you can use
agile like feature-driven development,lean software development, crystal
methodologies, dynamic development.

Different ceremonies perform in the Scrum:

• Planning Meeting
• Review Meeting
• Retrospective Meeting
• Backlog Grooming Meeting
 Different Amigos/person involved in the Scrum:

There are three types of persons involved in Scrum which are, Product
Owner, Scrum Master, and Scrum Team which includes Developer, Tester,
and BA.

Ideal Size of Scrum team is 7 to 9

resources. Ideal duration of
Sprint is 2-4 weeks.
Requirements are defined in Scrum as User Stories.
Different artifacts in Scrum:

Two artifacts are maintained in the Scrum are,

• Product Backlog: Contains a list of all user stories. Prepared by Product Owner.
• Sprint Backlog: Contains the User Stories committed by the Developer
and QAs for a specific Sprint.

============================================================
=================

Extra Questions:

• Types of User Acceptance Testing

1. Alpha Testing
2. Beta Testing

• Different Tools for Functional Testing:

1. Selenium
2. QTP (HP Product)
3. SoapUI (This is API tool)

• Different Tools for Non-Functional Testing:

1. JMeter
2. Loadster
3. LoadRunner
4. LoadStorm
5. NeoLoad
6. Forecast
 7. Load Complete

So, in the scrum, which entity is responsible for the deliverables? Scrum Master or
Product Owner?
• Neither the scrum master nor the product owner. It’s the responsibility of
the team that owns the deliverable.
 How do you create the Burn-Down chart?
• It is a tracking mechanism by which for a particular sprint; day-to-day tasks
are tracked to check whether the stories are progressing towards the
completion of the committed story points or not. Here, we should remember
that the efforts are measured in terms of user stories and not hours.

What do you do in a sprint review and retrospective?

• During Sprint review we walk-through and demonstrate the feature or story
implemented by the scrum team to the stakeholders.
• During Retrospective, we try to identify collaboratively what went well,
what could be done better, and action items to have continuous
improvement.

What qualities should a good Agile tester have?

• One should be able to understand the requirements quickly.
• One should know Agile concepts and principles.
• As requirements keep changing, one should understand the risk involved in it.
• The agile tester should be able to prioritize the work based on the requirements.
• Communication is a must for an Agile tester as it requires a lot of
communication with developers and business associates.

How does agile testing (development) methodology differ from other testing
(development) methodologies?
• In agile testing methodology, the entire testing process is broken into a small
piece of codes and in each step, these codes are tested. There are several
processes or plans involved in this methodology like communication with the
team, short strategical changes to get the optimal result, etc.
 Describe the places where ‘Scrum’ and ‘Kanban’ are used?
• ‘Scrum’ is used when you need to shift towards a more appropriate or more
prominent process while if you want improvement in running the process
without any changes in the whole scenario, you should use ‘Kanban’.

Why aren’t user stories simply estimated in man-hours?

• Estimation of user stories based on man-hours can be done but it is not
preferred. If we do so we will concentrate on the cost and budget of the
management while using man-hours.
• Instead of that, we can use story points, as it provides the complete idea
about both the complexity of work and required efforts which can’t be
derived from Man-hours.

Do you think scrum can be implemented in all the software development processes?
• Scrum is used mainly for
✓ Complex projects.
✓ Projects which have early and strict deadlines.
✓ When we are developing any software from scratch.

Tell me one big advantage of using scrum?

• The major advantage is – Early feedback from the client so if any changes
are required those can be done at the initial stage and producing the
Minimal Viable Product to the stakeholders.

Do you see any disadvantages of using scrum?

• I don’t see any disadvantage of using scrum. The problems mainly arise when
the scrum team does not either understand the values and principles of the
scrum or are not flexible enough to change.

In case you receive a story on the last day of the sprint to test and you find
there are defects, what will you do? Will you mark the story as done?
• No, I will not be able to mark the story as done as it has open defects and the
complete testing of all the functionality of that story is pending. As we are on
the last day of the sprint, we will mark those defects as Deferred for the next
sprint and we can spill over that story to the next Sprint.
 How do you measure the complexity or effort in a sprint? Is there a way to
determine and represent it?
• Complexity and effort are measured through “Story Points”. In Scrum, it’s
recommended to use the Fibonacci series to represent it. Considering the
development effort+ testing effort + resolving dependencies and other
factors that would require to complete a story.

When we Estimate with story points, we assign the point value to each item.
• To set the Story Point- Find the simplest story and assign the 1 value to that
story and accordingly on basis of complexity we can assign the values to
user stories.
 During Review, suppose the product owner or stakeholder does not agree
with the feature you implemented what would you do?
• First thing we will not mark the story as done.
• We will first confirm the actual requirement from the stakeholder and
update the user story and put it into the backlog. Based on the priority, we
would be pulling the story in the next sprint.

Apart from planning, review, and retrospective, do you know any other ceremony in
scrum?
• These three meetings are the ones which occur on regular basis, apart from
these We have one more meeting which is the Product Backlog Grooming
Meeting where the team, scrum master, and product owner meet to
understand the business requirements, splits it into user stories, and
estimating it.

Can you give an example of where scrum cannot be implemented? In

that case, what do you suggest?
• Scrum can be implemented in all kinds of projects. It is not only applicable
to software but is also implemented successfully in mechanical and
engineering projects.

What is MVP in scrum?

• A Minimum Viable Product is a product that has just the bare minimum
required feature which can be shown to the stakeholders and is eligible to
be deployed to production.
 How do you calculate a story point?
• A story point is calculated by considering the development effort +
testing effort + resolving dependencies and other factors that would
require to complete a story.

You are in the middle of a sprint and suddenly the product owner comes with
a new requirement, what will you do?
• In an ideal case, the requirement becomes a story and moves to the backlog.
Then based on the priority, the team can take it up in the next sprint.
• But if the priority of the requirement is really high, then the team will have
to accept it in the sprint, but it has to be very well communicated to the
stakeholder that incorporating a story in the middle of the sprint may result
in spilling over few stories to the next sprint.
 Which are the top agile matrices?
• Sprint burndown matric: Shows that how much work is pending/remaining in
the Sprint. Maintain by the Scrum Master daily. The progress is tracked by a
Burndown chart. It shows that estimated Vs. actual efforts of the Scrum Task.
• Velocity: Velocity (is a metric) used to measure the units of work done (completed) in
the given
time frame.
• Work category allocation: This factor provides us a clear idea about where
we are investing our time or where to set priority.
• Defect removal awareness: Quality products can be delivered by active
members and their awareness
• Cumulative flow diagram: With the help of this flow diagram, the uniform
workflow can be checked, where X-axis shows time and Y-axis shows no. of
efforts.
• A business value delivered: Business value delivered is an entity that shows
the team’s working efficiency. This method is used to measure, which around
100 points are associated with each project. Business objectives are given
value from 1,2,3,5 and so on according to complexity, urgency, and ROI.
• Defect resolution time: It’s a process where team member detects the bug
and priority intention by the removal of the error. A series of processes are
involved in fixing the bug:
✓ Clearing the picture of a bug
✓ Schedule fix
✓ Fixation of Defect is done
✓ Report of resolution is handed
• Time coverage: Amount of time given to code in question in testing. It is
measured by the ratio of no. of the line of code called by the test suite by the
total no. of the relative lines of code (in percentage).

How do you define a user story?

• Generally, the User stories are written by BA. So, I am not sure about the
Syntax, but it is a process of Phrasing the requirements in a form of a story, it
 is a way of describing a feature set/Requirement like – “I need …, So that ...”.

Which SDLC model is the best?

SDLC models are selected according to the requirements of the development

process. Each model provides unique features for software development. Due
to that, it may vary software-to-software to decide which model is best. But
nowadays the Agile Model is the most popular and widely adopted by software
firms.
Different Types of test plans in software testing?

Test plans can be used as supporting documentation for an overall testing

objective (a master test plan) and specific types of tests (a testing type-specific
plan).

• Master test plan: A master test plan is a high-level document for a project
or product’s overall testing goals and objectives. It lists tasks, milestones,
and outlines the size and scope of a testing project. It encapsulates all
other test plans within the project.
• Testing type-specific plan: Test plans can also be used to outline details
related to a specific type of test. For example, you may have a test plan
for unit testing, acceptance testing, and integration testing. These test
plans drill deeper into the specific type of test being conducted.

What are the important tasks in the Test Planning stage?

• Understanding and analyzing the requirements
• Risk Analysis
• Test Estimations (Scope of the project, Time, Budget, Available resources)
• Team formation
• Test Approach (Strategy) Implementation
• Defining Test Environment setup
• Traceability Matrix
• Test Plan Documentation

What are the reference documents for Test Planning?

• Reference Documents for Test Planning stage:
✓ Requirements
✓ Project Plan
✓ Test Strategy
—

• Design docs
✓ Process guidelines docs
✓ Corporate standards docs, etc.

What is Test Point Analysis?

• A formula-based test estimation method based on function point analysis.
What is Software Test Process?
• The fundamental test process comprises test planning and control, test
analysis and design, test implementation and execution, evaluating exit
criteria and reporting, and test closure activities.

What is Function Point Analysis?

• A Method aiming to measure the size of the functionality of an
information system. The measurement is independent of the technology.
This measurement may be used as a basis for the measurement of
productivity, the estimation of the needed resources, and project control.

What are the Entry criteria in Test Plan?

• The set of generic and specific conditions for permitting a process to go
forward with a defined task, e.g., test phase.
• The purpose of entry criteria is to prevent a task from starting which
would entail more (wasted) effort compared to the effort needed to
remove the failed entry criteria.

What is Exit criteria in Test Plan?

• The set of generic and specific conditions, agreed upon with the
stakeholders, for permitting a process to be officially completed. The
purpose of exit criteria is to prevent a task from being considered
completed when there are still outstanding parts of the task that have not
been finished. Exit criteria are used to report against and to plan when to
stop testing.

What is a Test deliverable?

 • Any test (work) product must be delivered to someone other than the
test (work) product’s author.

What are the Test deliverables in Software Test Process?

Test deliverables are nothing, but the documents prepared after testing. Test
deliverables will be delivered to the client not only for the completed
activities but also for the activities, which we are implementing for better
productivity.

Some Test Deliverables in the project are,

• Test deliverables
 • Test plan document,
• Test case document,
• Test Result Documents (will be prepared at the phase of each type of testing,
• Test Report or Project Closure Report (Prepare once we rolled out the project to the
client),
• Coverage matrix, defect matrix, and Traceability Matrix,
• Test design specifications,
• Release notes,
• Tools and their outputs,
• Error logs and execution logs,
• Problem reports and corrective action

==========================================================================
===