What is Software Testing?

Software testing is a process of executing a program or application with the intent of finding the
software bugs.

Static Testing:  It can test and find defects without executing code. Static Testing is done
during verification process. This testing includes reviewing of the documents and static analysis.
For example: reviewing, walkthrough, inspection, etc.

Dynamic Testing:  In dynamic testing the software code is executed to demonstrate the result of
running tests. It’s done during validation process. For example: unit testing, integration testing,
system testing, etc.

Why is software testing necessary?

Software Testing is necessary because we all make mistakes. Some of those mistakes are
unimportant, but some of them are expensive or dangerous we need to check that everything is
correct and working fine. – humans make mistakes all the time. 

Buggy:
While testing software application if we found large number of defects then that application is called
Buggy.

Difference between defect, error, bug/Fault, failure:

 
“A mistake in coding is called error, error found by tester is called defect, defect accepted by
development team then it is called bug, build does not meet the requirements then it is failure.”

What is the cost of defects in software testing?

The cost of defects can be measured by the impact of the defects and when we find them. Earlier
the defect is found lesser is the cost of defect. For example if error is found in the requirement
specifications then it is somewhat cheap to fix it. The correction to the requirement specification
can be done and then it can be re-issued. In the same way when defect or error is found in the
design then the design can be corrected and it can be re-issued. But if the error is not caught in
the specifications and is not found till the user acceptance then the cost to fix those errors or
defects will be way too expensive.

What is a Defect Life Cycle or a Bug lifecycle in software testing?

The bug has different states in the Life Cycle. The Life cycle of the bug can be shown
diagrammatically as follows:

What is the difference between Severity and Priority?

Severity of a defect is related to how severe a bug is or impact of bug.

Priority of a defect is related to how quickly a bug should be fixed and deployed to live servers.

High Priority & High Severity: An error which occurs on the basic functionality of the
application and will not allow the user to use the system. (E.g. A site maintaining the student
details, on saving record if it, doesn’t allow to save the record then this is high priority and high
severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on the cover page or
heading or title of an application.(logo color wrong)

High Severity & Low Priority: An error which occurs on the functionality of the application
(for which there is no workaround) and will not allow the user to use the system but on click of
link which is rarely used by the end user.(feature which is rarely used doesn’t work)
Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or
in the report (Not on cover page, heading, title).

What are the principles of testing?

1) Testing shows presence of defects: Testing can show the defects are present, but cannot
prove that there are no defects. Even after testing the application or product thoroughly we
cannot say that the product is 100% defect free. Testing always reduces the number of
undiscovered defects remaining in the software but even if no defects are found, it is not a proof
of correctness.

2) Exhaustive testing is impossible: Testing everything including all combinations of inputs

and preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and
priorities to focus testing efforts. For example: In an application in one screen there are 15 input
fields, each having 5 possible values, then to test all the valid combinations you would need 30 
517  578  125  (515) tests. This is very unlikely that the project timescales would allow for this
number of tests. So, accessing and managing risk is one of the most important activities and
reason for testing in any project. z

3) Early testing: In the software development life cycle testing activities should start as early as
possible and should be focused on defined objectives.

4) Defect clustering: A small number of modules contain most of the defects discovered during
pre-release testing.

5) Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the
same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide
Paradox”, it is really very important to review the test cases regularly and new and different tests
need to be written to exercise different parts of the software or system to potentially find more
defects.

6) Testing is context dependent: Testing is basically context dependent. Different kinds of sites
are tested differently. For example, safety – critical software is tested differently from an e-
commerce site.

7) Absence – of – errors fallacy: If the system built is unusable and does not fulfill the user’s
needs and expectations then finding and fixing defects does not help.

Independent testing in the Software testing is generally where the testing is completely
outsourced and testers work as an individual dedicated unit. Testers will have the complete
independence of testing with almost negligible interference of Developers or Business. This
helps the testers to test freely and raise as many issues as possible without hesitation

Advantages:
 1. Testers raise issues freely and raise as many as possible which in the other way improves
the Quality of the product.
2. Developers will have negligible interference in the issues raised which will force them to
work hard.

Disadvantages:

1. There is scope for increase in Invalid issues count as the developers and testers have
minimal communication.
2. Applications having complex architecture are difficult to test as there is minimum
communication between developers and testers.

   Verification
1. Verification is a static practice of
verifying documents, design, code and
program.
2. It does not involve executing the code.
3. It is human based checking of
documents and files.
4. Verification uses methods like
inspections, reviews, walkthroughs, and
Desk-checking etc.
             Validation
1. Validation is a dynamic mechanism of
validating and testing the actual product.
2. It always involves executing the code.
3. It is computer based execution of
program.
4. Validation uses methods like black box
(functional)  testing, gray box testing, and
white box (structural) testing etc.

5. Verification is to check whether the 5. Validation is to check whether software

software conforms to specifications. meets the customer expectations and
requirements.

6. It can catch errors that validation cannot 6. It can catch errors that verification cannot
catch. It is low level exercise. catch. It is High Level Exercise.

7. Target is requirements specification, 7. Target is actual product-a unit, a module,

application and software architecture, high
level, complete design, and database
design etc.
8. Verification is done by QA team to
ensure that the software is as per the
specifications in the SRS document.
9. It generally comes first-done before
validation.
a bent of integrated modules, and effective
final product.
8. Validation is carried out with the
involvement of testing team.
9. It generally follows after verification.
Explain CMM.
Capability Maturity Model (CMM) is divided in five levels:

1. Initial: The organization is characterized by an adhoc set of activities. The processes aren't defined
and success depends on individual effort.

2. Repeatable: In this level some processes are repeatable, possibly with consistent results.

3. Defined: In this level, we define all processes are documented for both management and engineering
activities, and standards.

4. Managed: Detailed measures of each process are defined and product quality data is routinely
collected. Both process and products are quantitatively understood and controlled.

5. Optimizing: In this we optimize the application by following improvement process

SDLC with STLC

S. SDLC - Software Development Life
Phase STLC - Software Test Life Cycle
No. cycle

Testing team also reviews & analyzes the

requirements. Testing team identifies
Requirements gathering are done by
the testing requirements like what types
business analyst. Development team
Requirements of testing will be required and review the
1 analyzes the requirements from the
Gathering requirements for logical functional
design, architecture & coding
relationship between various features /
perspective.
modules, so that any gaps can be caught
at an early stage.

Here, test architect generally the test

Technical architect works for the high
lead/manager, does the test planning,
level & low design of the software.
2 Design identify high level testing points.
Business analyst works for the UI
Basically, requirement detailing is done
design of the application
in this phase.
 Development team does the actual
Coding or Testing team write the detailed test
3 coding based on the designed
development cases.
architecture.

Test Execution and bug reporting,

In SDLC, actual testing is carried out in testing and regression testing is also
this phase. It includes unit testing,
4 Testing
integration testing & system testing
etc..
manual testing, automation testing is
done, defects found are reported. Re-
done in this phase. But, I don't agree
with this statement. So, if I want to
relate the testing phase with STLC, I
would say it it is testing of test cases &
test plans i.e. is basically review of test
cases, test scenarios etc..

Final testing and implementation is done

Application is deployed on production
5 Deployment
environment for real end users.
is this phase and final test report is
prepared. For this statement as well, I
don't agree. For software / application
deployment is basically, when it is
installed for real use. So, this way, STLC,
deployment would be when test when
test cases getting used i.e. execution of
test cases.

Most of people say - Maintenance

Basically, it includes, post production /
6 Maintenance
deployment support & enhancements.
testing is carried out in this phase. My
definition for this is - updating &
maintenance of test plans, test case
required for the testing of support
requests & enhancements as a part of
maintenance.

STLC:
Phase Activity Deliverables Necessity
You review the software
Requirements/  ‘Review Defect’ Reports
requirements/ design (Well, Curiosity
Design Review
if they exist.)
 Once you have gathered a  Test Plan
general idea of what needs  Test Estimation
Test Planning Farsightedness
to be tested, you ‘plan’ for  Test Schedule
the tests.

 Test Cases / Test

You design/ detail your tests
Scripts /Test Data
on the basis of detailed
Test Designing  Requirements Creativity
requirements/design of the
Traceability Matrix
software.

You setup the test

Test environment (server/ client/
 Test Environment
Environment network, etc) with the goal Rich company
Setup of replicating the end-users’
environment.
You execute your Test  Test Results
Cases/ Scripts in the Test (Incremental)
Test Execution Patience
Environment to see whether  Defect Reports
they pass.

 Test Results (Final)

 Test/ Defect Metrics
 Test Closure Report
You prepare various reports  Who Worked Late & on
Test Reporting Weekends (WWLW) Diplomacy
for various stakeholders.
Report [Depending
on how fussy your
Management is]

Requirement Traceability Matrix it is a document that maps and traces user

requirement with test cases. The main purpose of Requirement Traceability Matrix is to see that
all test cases are covered so that no functionality should miss while testing.

What are Software Testing Levels?

Unit testing: It is basically done by the developers to make sure that their code is working fine and meet
the user specifications. They test their piece of code which they have written like classes, functions,
interfaces and procedures.

Component testing: It is also called as module testing. The basic difference between the unit
testing and component testing is in unit testing the developers test their piece of code but in
component testing the whole component is tested. For example, in a student record application
there are two modules one which will save the records of the students and other module is to
upload the results of the students. Both the modules are developed separately and when they are
tested one by one then we call this as a component or module testing.

Integration testing: Integration testing is done when two modules are integrated, in order to test
the behavior and functionality of both the modules after integration. Below are few types of
integration testing?

 Big bang integration testing

 Top down
 Bottom up
 Functional incremental

What are stubs?

Stubs are basically used in TOP-DOWN approach of integration testing. In this approach, the upper
modules are prepared first and are ready for testing while the bottom modules are not yet prepared by
the developers.
So in order to form the complete application we create dummy programs for the lower modules in the
application so that all the functionalities can be tested.

What are drivers?

A driver is basically a piece of code through which other programs or pieces of code or modules can be
called. Drivers are the main program through which other modules are called.
If we want to test any module it is required that we should have a main program which will call the
testing module. Without the dummy program or driver, the complete testing of the module is not
possible.
Drivers are basically called in BOTTOM UP testing approach. In bottom up testing approach the bottom
level modules are prepared but the top level modules are not prepared. Testing of the bottom level
modules is not possible with the help of main program. So we prepare a dummy program or driver to
call the bottom level modules and perform its testing.

Component integration testing:  This testing is basically done to ensure that the code should not
break after integrating the two modules.

System testing – System Testing (ST) is a black box testing technique performed to evaluate the
complete system and system's compliance against specified requirements. In System testing, the
functionalities of the system are tested from an end-to-end perspective.
Acceptance testing: Acceptance testing is basically done to ensure that the requirements of the
specification are met.
 Alpha testing: Alpha testing is done at the developers site. It is done at the end of the
development process

 Beta testing: Beta testing is done at the customers site. It is done just before the launch of the
product.

What is Non-functional testing

 Reliability testing: Reliability Testing is about exercising an application so that failures
are discovered and removed before the system is deployed. The purpose of reliability
testing is to determine product reliability, and to determine whether the software meets
the customer’s reliability requirements.
 Usability testing: In usability testing basically the testers tests the ease with which the
user interfaces can be used. It tests that whether the application or the product built is
user-friendly or not.
 Efficiency testing: Efficiency testing test the amount of code and testing resources
required by a program to perform a particular
 function. Software Test Efficiency is number of test cases executed divided by unit of
time (generally per hour).
 Maintainability testing: It basically defines that how easy it is to maintain the system.
This means that how easy it is to analyze, change and test the application or product.
 Portability testing: It is process of testing the ease with which a computer software
component or application can be moved from one environment to another, e.g. moving of
any application from Windows 2000 to Windows XP. This is usually measured in terms
of the maximum amount of effort permitted. Results are measured in terms of the time
required to move the software and complete the and documentation updates.
 Baseline testing: Validation of documents and specifications on which test cases would
be designed. The requirement specification validation is baseline testing.
 Compliance testing: It is related with the IT standards followed by the company and it is
the testing done to find the deviations from the company prescribed standards.
 Documentation testing: testing of test incident report, test log, test plan, test procedure,
test report is known as documentation testing.
 Endurance testing: Endurance testing involves testing a system with a significant load
extended over a significant period of time, to discover how the system behaves under
sustained use. For example, in software testing, a system may behave exactly as expected
when tested for 1 hour but when the same system is tested for 3 hours, problems such as
memory leaks cause the system to fail or behave randomly.
 Load testing: A load test is usually conducted to understand the behavior of the
application under a specific expected load. E.g. If the number of users are increased then
how much CPU, memory will be consumed, what is the network and bandwidth response
time.
 Performance testing: Performance testing is testing that is performed, to determine how
fast some aspect of a system performs under a particular workload.
  Compatibility testing: It tests whether the application or the software product built is
compatible with the hardware, operating system, database or other system software or
not.
 Security testing: Security testing is basically to check that whether the application or the
product is secured or not. Can anyone came tomorrow and hack the system or login the
application without any authorization. It is a process to determine that an information
system protects data and maintains functionality as intended.
 Scalability testing: It is the testing of a software application for measuring its capability
to scale up in terms of any of its non-functional capability like load supported, the
number of transactions, the data volume etc.
 Volume testing: Volume testing refers to testing a software application or the product
with a certain amount of data. E.g., if we want to volume test our application with a
specific database size, we need to expand our database to that size and then test the
application’s performance on it.
 Stress testing: It involves testing beyond normal operational capacity, often to a
breaking point, in order to observe the results. It is a form of testing that is used to
determine the stability of a given system.
 Recovery testing: Recovery testing is done in order to check how fast and better the
application can recover after it has gone through any type of crash or hardware failure
etc.
 Internationalization testing and Localization testing: Internationalization is a process
of designing a software application so that it can be adapted to various languages and
regions without any changes. Whereas Localization is a process of adapting
internationalized software for a specific region or language by adding local specific
components and translating text.

Confirmation testing or re-testing: When a test fails because of the defect then that defect is reported
and a new version of the software is expected that has had the defect fixed. In this case we need to
execute the test again to confirm that whether the defect got actually fixed or not.
Regression Testing: When any modification or changes are done to the application or even when any
small change is done to the code then it can bring unexpected issues. Along with the new changes it
becomes very important to test whether the existing functionality is intact or not. This can be achieved
by doing the regression testing.

Can you explain boundary value analysis?

In some projects there are scenarios where we need to do boundary value testing. For instance, let's say
for a bank application you can withdraw a maximum of 25000 and a minimum of 100. So in boundary
value testing we only test the exact boundaries rather than hitting in the middle. That means we only
test above the max and below the max(MIN). This covers all scenarios. The following figure shows the
boundary value testing for the bank application which we just described. TC1 and TC2 are sufficient to
test all conditions for the bank. TC3 and TC4 are just duplicate/redundant test cases which really do not
add any value to the testing. So by applying proper boundary value fundamentals we can avoid duplicate
test cases, which do not add value to the testing.

Can you explain equivalence partitioning?

In equivalence partitioning we identify inputs which are treated by the system in the same way and
produce the same results. You can see from the following figure applications TC1 and TC2 give the same
results (i.e., TC3 and TC4 both give the same result, Result2). In short, we have two redundant test
cases. By applying equivalence partitioning we minimize the redundant test cases.

So apply the test below to see if it forms an equivalence class or not:

 All the test cases should test the same thing.

 They should produce the same results.
 If one test case catches a bug, then the other should also catch it.
 If one of them does not catch the defect, then the other should not catch it.
Decision Table :

Decision Table Testing is a good way to deal with a combination of inputs, which produce
different results. It helps reduce test effort in verifying each and every combinations of test data,
at the same time ensuring complete coverage

Example: To understand the importance of Decision Table Making we will see an example, let's
consider the behavior of Flight Button for different combinations of Fly From & Fly To.

The Error guessing is a technique where the experienced and good testers are encouraged to think of
situations in which the software may not be able to cope. Some people seem to be naturally good at
testing and others are good testers because they have a lot of experience either as a tester or working with
a particular system and so are able to find out its weaknesses.

Exploratory testing is about exploring, finding out about the software, what it
does, what it doesn’t do, what works and what doesn’t work. The tester is constantly making decisions
about what to test next and where to spend the (limited) time.

What Test Coverage does

 Finding area of a requirement not implemented by a set of test cases

 Helps to create additional test cases to increase coverage
 Identifying meaningless test cases that do not increase coverage

Code Coverage is a measurement of how many lines/blocks/arcs of your code are executed while
the automated tests are running.

Smoke and Sanity

Smoke testing is a wide approach where all areas of the software application are tested without
getting into too deep. However, a sanity software testing is a narrow regression testing with a
focus on one or a small set of areas of functionality of the software application.

What is Bug Leakage, Bug Release, Bug Age

Bug (defect) Leakage:

When a Bug (defect) if found by customer / end user missed by the testing team to detect, while
testing the software.

Bug (defect) Release:

Bug Release- Release of the software with the known bugs is called bug release. when software
or an application is handed over to the testing team knowing that the defect is present in a
release.
During this the priority and severity of bug is low.
Bug (defect) Age:
Bug (defect) Age is the difference in time between the date a defect is detected (confirmed and
assigned) and the defect was fixed (verified and closed).

Formula:
Bug (defect) Age = Bug Fix Date – Bug Detection Date

What is difference between QA, QC and Software Testing?

Quality Assurance (QA): QA refers to the planned and systematic way of monitoring the quality of
process which is followed to produce a quality product. QA tracks the outcomes and adjusts the process to
meet the expectation.

Quality Control (QC): Concern with the quality of the product. QC finds the defects and suggests
improvements. The process set by QA is implemented by QC. The QC is the responsibility of the tester.

Software Testing: is the process of ensuring that product which is developed by the developer meets the
user requirement. The motive to perform testing is to find the bugs and make sure that they get fixed.

When to start QA in Project?

A good time to start the QA is from the beginning of the project startup. This will lead to plan
the process which will make sure that product coming out meets the customer quality
expectation. QA also plays a major role in the communication between teams. It gives time to
step up the testing environment. The testing phase starts after the test plans are written, reviewed
and approved.

Test Ware:
The testware is:

- The subset of software which helps in performing the testing of application.

- Testware is term given to combination of all utilities and application software that required for
testing a software package.

Testware is special because it has:

1. Different purpose
2. Different metrics for quality and
3. Different users

Build and Release

BUILD: is a number given to installable software that is given to testing team for testing by the
development team. Build number assigned are incremental and sequential.

RELEASE: is a number given to installable software that is handed over to customer by the
developer or tester.
The information of build, release and version are displayed in software help page. Using this
build and release customer can let the customer team know which release version build that are
using.

Eg "9.4.123.2" (Release Number. Version Number. Build Number. Patch Number)

Following are some challenges of software testing

1. Application should be stable enough to be tested.

2. Testing always under time constraint
3. Understanding requirements, Domain knowledge and business user perspective understanding
4. Which tests to execute first?
5. Testing the Complete Application
6. Regression testing
7. Lack of skilled testers.
8. Changing requirements
9. Lack of resources, tools and training

The reasons for choosing automation testing over manual testing are following:

1. Frequency of use of test case

2. Time Comparison (automated script run much faster than manual execution.)
3. Re-usability of Automation Script
4. Adaptability of test case for automation.
5. Exploitation of automation tool.

Data Driven Testing :

Data Driven is an automation testing part in which test input or output values, these values are
read from data files. It is performed when the values are changing by the time. The different data
files may include data pools, csv files, Excel files. The data is then loaded into variables in
recorded or manually coded scripts. For data driven testing we use Parameterzing and Regular
expression Technique.

Ex: To evaluate login functionality, we use different user name and password combinations,
variables are used to access different username and password. The list of username and password
are stored in a data table or excel sheet.
What are test driver and test stub and why we need them?
- The Stub is called from the software component to be tested. It is used in top down approach.
- The driver calls a component to be tested. It is used in bottom up approach.
- Both test stub and test driver are dummy software components.

We need test stub and test driver because of following reason:

- Suppose we want to test the interface between modules A and B and we have developed only module
A. So we cannot test module A but if a dummy module is prepare, using that we can test module A.

- Now module B cannot send or receive data from module A directly so, in these cases we have to
transfer data from one module to another module by some external features. This external feature used
is called Driver.

What is Bug Triage?

Bug triage is a process to:

- Ensure bug report completeness.

- Analyze and assign bug to proper component.
- Assign bug to proper bug owner.
- Set appropriate bug priority.
- Adjust bug severity properly.

What are the benefits of Automated Testing?

The benefits of Automation Testing are as below:

- Test engineer productivity.

- Coverage of regression testing.
- Re-usability of test cases.
- Consistency in testing.
- Test interval reduction
- Reduced software maintenance cost
- Increased test effectiveness
What is the purpose of test strategy?

We need Test Strategy for the following reason:

1. To have a signed, sealed, and delivered document, where the document contains details about the
testing methodology, test plan, and test cases.
2. Test strategy document tells us how the software product will be tested.
3. Test strategy document helps to review the test plan with the project team members.
4. It describes the roles, responsibilities and the resources required for the test and schedule.
5. When we create a test strategy document, we have to put into writing any testing issues requiring
resolution.
6. The test strategy is decided first, before lower level decisions are made on the test plan, test design,
and other testing issues.

What is good code?

A good code is code that works. The good code must not contain the defect or bug and is readable by
other developers and easily maintainable. Organizations have coding standards all developers should
follow, and also every programmer and software engineer has different ideas about what is best and
what are too many or too few rules. We need to keep in mind that excessive use of rules can decrease
both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems
and enforce standards.

What could go wrong with test automation?

Followings things may be go wrong in test automation:

- Ignoring automation, while planning the development phases.

- In design Phase not choosing the right technology.
- In coding Phase not automating the right test cases.
- Tool selection might go wrong.
- Test script not be updated when application is continuously changing.
- Test data should be unique, if the same data is available on the application then the application will not
accept the data that we are going to add via automation.
What methodologies do you used to develop test cases?
For developing the test cases we use following strategies:

- Error Guessing: The tester has to guess what fault might occur and to design the tests to represent
them.

- Equivalence Class Partitioning: The input domain data is divided into different equivalence data
classes; take few valid values with 2 invalid values. This is used to reduce the total number of test cases
to a finite set of testable test cases.

- Boundary value analysis: Boundary value analysis testing technique is used to identify errors at
boundaries rather than finding those exist in center of input domain. Boundary value analysis is a next
part of Equivalence.

What are the differences between test strategy and test plan?
The differences between these two are described below:

- Test plan is dynamic whereas test strategy is static.

- Test plan is prepared by the Test Lead whereas Test Strategy is prepared by the company
management.

- Test strategy defines: methods and coverage criteria to be covered test completion criteria,
prioritization of the test whereas Test plan is a document describing the scope, approach, resources and
schedule of intended test activities.

What is the need of Test Plan document?

Test Plan tells the tester that what needs to be tested and how testing is going to be performed. Test
plan also tells that what resources are needed for the execution of the test cases, timelines and risk
associated with the test plan. We can also perform the testing without test plan document, but first we
have to select test Approach for the testing and go with testing. Many test plans are being created just
for the sake of processes. Many tester use test plan documents when test plan document contains the
some useful information.

Specification-driven testing: means to test the functionality of software according to the user
requirements. In this, tester inputs multiple data and monitors the outputs from, the test object. In this
testing tester evaluate the showstopper bugs which break the major functionality of the application.
This type of testing requires test plan and test.
How do you decide you have tested enough?

The principle of testing says that exhaustive testing is impossible. i.e. testing everything is not feasible.
We cannot test till all the defects are debugged and removed, it is simply impossible. We have to stop
testing and ship the software. We can decide when to stop is testing based on following points:

- When there is no time and budget.

- When maximum number of test cases are executed.
- All the Requirements are mapped that is RTM is filled completely.
- When Test coverage is more than 80%.
- When bug rate falls below certain level.

What is the difference between functional and nonfunctional testing?

Functional testing basically deals with the functional aspect of the application. This technique
tests that the system is behaving as per the requirement and specification.

These are directly linked with customer requirement. We validate the test cases against the
specified requirement and make the test pass or failed accordingly.

Examples include regression, integration, system, smoke etc…

Nonfunctional testing – on the other hand tests the Nonfunctional aspect of the application. It
tests NOT the requirement, but the environmental factors like performance, load and stress.

What is negative testing? How is it different from positive testing?

Negative testing is a technique which validates that the system behaves gracefully in case of any
invalid inputs.

For example, in case user enters any invalid data in a text box, system should display a proper
message instead of technical message which the user does not understands.

Negative testing is different from positive testing in a way that positive testing validates that our
system works as expected and compares the test results with the expected results.

                  Use Case                        Test Case

1 Use Case is prepared by business
analyst.
2 Based on test cases use cases cannot
be prepared means it is not derived
from test cases.
Test case is prepared by test engineer and
in small companies sometimes it is
prepared by quality analyst too.
Based on use cases test cases can be
prepared means it is derived from use
cases.
 3 Use case describes step by step
instructions means how to use
functionality.
4 Use case cannot be executed means it
is only designed.
5 It is derived from the BRS (Business
requirement specification.)
6 It always tells us about the story of
how people interact with a software
system to achieve a goal.
Test case verifies the functionality means it
is as per the instructions mentioned in use
case or not.
We design the test cases and later execute
them.
It is derived from the use case.
It verifies the goal to see it is as per the
instructions of use case or not.

Login Page Test cases:

1. Verify that the login screen is having option to enter username and password with submit
button and option of forgot password
2. Verify that user is able to login with valid username and password
3. Verify that user is not able to login with invalid username and password
4. Verify that validation message gets displayed in case user leaves username or password
field as blank
5. Verify that validation message is displayed in case user exceeds the character limit of the
user name and password fields
6. Verify that there is reset button to clear the field's text
7. Verify if there is checkbox with label "remember password" in the login page
8. Verify that the password is in encrypted form when entered
9. Verify that there is limit on the total number of unsuccessful attempts
10. For security point of view, in case of in correct credentials user is displayed the message
like "incorrect username or password" instead of exact message pointing at the field that
is incorrect. As message like "incorrect username" will aid hacker in bruteforcing the
fields one by one
11. Verify the timeout of the login session
12. Verify if the password can be copy-pasted or not
 13. Verify that once logged in, clicking back button doesn't logout user
14. Verify if SQL Injection attacks works on login page
15. Verify if XSS vulnerability work on login page

What is a test bed?

Ans. A test bed is a test environment used for testing an application. A test bed configuration can consist
of the hardware and software requirement of the application under test including - operating system,
hardware configurations, software configurations, database etc.

Ques.12. What is a test scenario?

Ans. A test scenario is derived from a use case. It is used for end to end testing of a feature of an
application. A single test scenario can cater multiple test cases. The scenario testing is
particularly useful when there is time constraint while testing.

Ques.13. What is a test case?

Ans. A test case is used to test the conformance of an application with its requirement
specifications. It is a set of conditions with pre-requisites, input values and expected results in a
documented form.

Ques.15. What is a test script?

Ans. A test script is an automated test case written in any programming or scripting language. These are
basically a set of instructions to evaluate the functioning of an application.

What are the categories of defects?

There are three main categories of defects:

1. Wrong: The requirements have been implemented incorrectly. This defect is a variance
from the given specification.
2. Missing: There was a requirement given by the customer and it was not done.
3. Extra: A requirement incorporated into the product that was not given by the end
customer.

What does entry and exit criteria mean in a project?

Entry and exit criteria are a must for the success of any project. If you do not know where to start
and where to finish then your goals are not clear. By defining exit and entry criteria you define
your boundaries.

For instance, you can define entry criteria that the customer should provide the requirement
document or acceptance plan. If this entry criteria is not met then you will not start the project.
On the other end, you can also define exit criteria for your project. For instance, one of the
common exit criteria in projects is that the customer has successfully executed the acceptance
test plan.

What is the difference between latent and masked defects?

A latent defect is an existing defect that has not yet caused a failure because the sets of
conditions were never met.

A masked defect is an existing defect that hasn't yet caused a failure just because another defect
has prevented that part of the code from being executed.

What is coverage and what are the different types of coverage techniques?

Coverage is a measurement used in software testing to describe the degree to which the source
code is tested. There are three basic types of coverage techniques as shown in the following
figure:
  Statement coverage: This coverage ensures that each line of source code has been
executed and tested.
 Decision coverage: This coverage ensures that every decision (true/false) in the source
code has been executed and tested.
 Path coverage: In this coverage we ensure that every possible route through a given part
of code is executed and tested.

Agile Methodology Interview Questions and Answers:

Q#1. What is Agile Testing?

Ans. Agile Testing is a practice that a QA follows in a dynamic environment where testing
requirements keep changing according to the customer needs. It is done parallel to the
development activity where testing team receives frequent small codes from the development
team for testing.

Q#2. What is the difference between burn-up and burn-down chart?

Ans. Burn-up and burn-down charts are used to keep track the progress of the project.

Burn-up charts represent how much work has been completed in any project whereas Burn-down
chart represents the remaining work in a project.

Q#3. Define the roles in Scrum?

Ans. There are mainly three roles that a Scrum team have:
 1. Project Owner – who has the responsibility of managing product backlog. Works with
end users and customers and provide proper requirement to the team to build the proper
product.
2. Scrum Master – who works with scrum team to make sure each sprint gets complete on
time. Scrum master ensure proper work flow to the team.
3. Scrum Team – Each member in the team should be self-organized, dedicated and
responsible for high quality of the work.

Q#4. What is Product backlog & Sprint Backlog?

Ans. Product backlog is maintained by the project owner which contains every feature and
requirement of the product.

Sprint backlog can be treated as subset of product backlog which contains features and
requirements related to that particular sprint only.

Q#5. Explain Velocity in Agile?

Ans. Velocity is a metric that is calculated by addition of all efforts estimates associated with
user stories completed in a iteration. It predicts how much work Agile can complete in a sprint
and how much time will require to complete a project.

Q#6. Explain the difference between traditional Waterfall model and Agile testing?

Ans. Agile testing is done parallel to the development activity whereas in traditional waterfall
model testing is done at the end of the development.

As done in parallel, agile testing is done on small features whereas in waterfall model testing is
done on whole application.

Q#7. Explain Pair Programming and its benefits?

Ans. Pair programming is a technique in which two programmer works as team in which one
programmer writes code and other one reviews that code. They both can switch their roles.

Benefits:

1. Improved code quality: As second partner reviews the code simultaneously, it reduces the
chances of mistake.
2. Knowledge transfer is easy: One experience partner can teach other partner about the
techniques and codes.

Q#8. What is re-factoring?

Ans. Modification of the code without changing its functionality to improve the performance is
called re-factoring.
Q#9. Explain the Iterative and Incremental Development in Agile?

Ans. Iterative Development: Software is developed and delivered to customer and based on the
feedback again developed in cycles or release and sprints. Say in Release 1 software is developed
in 5 sprints and delivered to customer. Now customer wants some changes, then development
team plan for 2nd release which can be completed in some sprints and so on.

Incremental Development: Software is development in parts or increments. In each increment a

portion of the complete requirement is delivered.

Q#10. How do you deal when requirements change frequently?

Ans. This question is to test the analytical capability of the candidate. Answer can be-

Work with PO to understand the exact requirement to update test cases. Also understand the risk
in changing the requirement. Apart from this one should be able to write generic test plan and
test cases. Don’t go for the automation until requirements are finalized.

Q#11. What is a test stub?

Ans. A small code which mimics a specific component in the system and can replace it. Its
output is same as the component it replaces.

Q#12. What qualities should a good Agile tester have?

Ans.

1. Agile tester should be able to understand the requirements quickly.

2. Agile tester should know Agile concepts and principals.
3. As requirements keep changing, he should understand the risk involve in it.
4. Agile tester should be able to prioritize the work based on the requirements.
5. Communication is must for a Agile tester as it requires a lot of communication with
developers and business associates.

Q#13. What is difference between Epic, User stories & Tasks?

Ans. User Stories: User Stories defines the actual business requirement. Generally created by

Business owner.

Task: To accomplish the business requirements development team create tasks.

Epic: A group of related user stories is called an Epic.

Q#14. What is a Task board in Agile?

Ans. Task board is dash board which shows progress of the project. It contains:
 1. User Story: which has the actual business requirement?
2. To Do: Tasks that can be worked on.
3. In Progress: Tasks in progress.
4. To Verify: Tasks pending for verification or testing
5. Done: Completed tasks.

Q#15. What is Test Driven Development (TDD)?

Ans. It is Test-first development technique in which we add a test first before we write a
complete production code. Next we run the test and based on the result re factor the code to
fulfill the test requirement.

Q#16. How QA can add a value to an agile team?

Ans. QA can provide a value addition by thinking differently about the various scenarios to test a
story. They can provide quick feedback to the developers whether new functionality is working
fine or not.

Q#17. What is Scrum ban?

Ans. It is a software development model which is combination of scrum and kanban. Scrum ban
is considered for maintenance projects in which there are frequent changes or unexpected user
stories. It can reduce the minimum completion time for user stories.

Q#18. What is Application Binary Interface?

Ans. Application Binary Interface or ABI defines an interface for complied application programs
or we can say it describes the low level interface between an application and the operating
system.

Q#19. What is Zero sprint in Agile?

Ans. It can be defined as pre step to the first sprint. Activities like setting development
environment, preparing backlog etc. needs to be done before starting of the first sprint and can be
treated as Sprint zero.

Q#20. What is Spike?

Ans. There may be some technical issues or design problem in the project which needs to be
resolved first. To provide the solution of these problem “Spikes” are created. Spikes are of two
types- Functional and Technical.

Q#21. Name some Agile quality strategies.

Ans. Some Agile quality strategies are-

 1. Re-factoring
2. Small feedback cycles
3. Dynamic code analysis
4. Iteration

Q#22. What is importance of daily stand up meeting?

Ans. Daily stand up meeting is essential for any team in which-

1. Team discuss about how much work has been completed.

2. What are the plans to resolve technical issues.
3. What steps need to done to complete the projects etc.

Q#23. What is tracer bullet?

Ans. The purpose of a tracer bullet is to examine how an end-to-end process will work and
examine feasibility.

Q#24. How the velocity of sprint is measured?

Ans. If capacity is measured as a percentage of a 40 hours weeks then completed story points
* team capacity

If capacity is measured in man hours then Completed story points / team capacity

Q#25. What is Agile manifesto?

Ans. The Agile Manifesto: Purpose

"We are uncovering better ways of developing software by doing it and helping others do it. We value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Q#26: What is the difference between mobile and web application?

Ans: mobile applications need to be downloaded on your system but web applications can be
use without downloading on your system with browser and internet connection.
Mobile applications are platform dependent but web applications are not.
Mobile applications need access to gallery or contacts but in web applications not.
There is need to update mobile applications but web application update automatically.
Q#27: what is inspection and walk-through?

Ans; walk through is basically a evaluation of process.it is an informal meeting which

does not require any preparation.
we showcase our product and participents in meeting will add comments on it and we
will use it as a information.
To explain and evaluate contents of document
To establish common understanding of document.
to examine is there any alternative to the solution or not.
example: the server we are selected is increasing our cost, so is there any other server
which is cost effective and we can use it for this purpose or nit
SRS: database,modules,servers.
static testing-> done on documents.

inspection:
 it is usually led by a trained moderator.
 document under inspection is prepared and checked thoroughly before meeting
by reviewers, using rules and checklists.
 example; concrete pouring in building.
 helps author to improve quality of document.
 remove defects efficiently as early as possible.
 improve product quality by producing documents with a high level of quality.

Q#28: what is Deliverable and artifect and ripple?

Ans: A deliverable is a work product that is contractually specified and in turn formally
reviewed, agreed, and signed off by the stakeholders. ... An artifact is a more granular
architectural work product that describes an architecture from a specific viewpoint.

The ripple effect metric shows what impact changes to software will have on the rest of the
system. ... The computation of ripple effect is based on the effect that a change to a single
variable will have on the rest of a program; it provides a measure of the program's complexity.