 |
| Software Testing Interview Questions |
1. Can you explain the PDCA cycle and where testing fits
in?
Software testing is an important part of the software development process.
In normal software development there are four important steps, also referred
to, in short, as the PDCA (Plan, Do, Check, Act) cycle.
Let's review the four steps in detail.
Plan: Define the goal and the
plan for achieving that goal.
Do/Execute: Depending on the plan
strategy decided during the plan stage we do execution accordingly in this
phase.
Check: Check/Test to ensure that we are moving
according to plan and are getting the desired results.
Act: During the check cycle, if
any issues are there, then we take appropriate action accordingly and revise
our plan again.
2. What is the difference between white box, black box,
and gray box testing?
Black box testing is a testing strategy based solely on requirements and
specifications. Black box testing requires no knowledge of internal paths,
structures, or implementation of the software being tested.
White box testing is a testing strategy based on internal paths, code
structures, and implementation of the software being tested. White box testing
generally requires detailed programming skills.
There is one more type of testing called gray box testing. In this we look
into the "box" being tested just long enough to understand how it has
been implemented. Then we close up the box and use our knowledge to choose more
effective black box tests.
3)On what basis is the acceptance plan prepared?
Requirement document: This
document specifies what exactly is needed in the project from the customers
perspective.
Input from customer: This can be
discussions, informal talks, emails, etc.
Project plan: The project plan
prepared by the project manager also serves as good input to finalize your
acceptance test.
4) 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.
5)Can you explain calibration?
It includes tracing the accuracy of the devices used in the production,
development and testing. Devices used must be maintained and calibrated to
ensure that it is working in good order.
6)What's the difference between alpha and beta testing?
Alpha and beta testing has different meanings to different people. Alpha
testing is the acceptance testing done at the development site. Some
organizations have a different visualization of alpha testing. They consider
alpha testing as testing which is conducted on early, unstable versions of
software. On the contrary beta testing is acceptance testing conducted at the
customer end.
7) What is configuration management?
Configuration management is the detailed recording and updating of
information for hardware and software components. When we say components we not
only mean source code. It can be tracking of changes for software documents
such as requirement, design, test cases, etc.
When changes are done in adhoc and in an uncontrolled manner chaotic
situations can arise and more defects injected. So whenever changes are done it
should be done in a controlled fashion and with proper versioning. At any
moment of time we should be able to revert back to the old version. The main
intention of configuration management is to track our changes if we have issues
with the current system. Configuration management is done using baselines.
8)Which is the best testing model?
In real projects, tailored models are proven to be the best, because they
share features from The Waterfall, Iterative, Evolutionary models, etc., and
can fit into real life time projects. Tailored models are most productive and
beneficial for many organizations. If it's a pure testing project, then the V
model is the best.
9)Should testing be done only after the build and
execution phases are complete?
In the requirement phase we can verify if the requirements are met
according to the customer needs. During design we can check whether the design
document covers all the requirements. In this stage we can also generate rough
functional data. We can also review the design document from the architecture
and the correctness perspectives. In the build and execution phase we can
execute unit test cases and generate structural and functional data. And
finally comes the testing phase done in the traditional way. i.e., run the
system test cases and see if the system works according to the requirements.
During installation we need to see if the system is compatible with the
software. Finally, during the maintenance phase when any fixes are made we can
retest the fixes and follow the regression testing.
10)Are there more defects in the design phase or in the
coding phase?
The design phase is more error prone than the execution phase. One of the
most frequent defects which occur during design is that the product does not
cover the complete requirements of the customer. Second is wrong or bad
architecture and technical decisions make the next phase, execution, more prone
to defects. Because the design phase drives the execution phase it's the most
critical phase to test. The testing of the design phase can be done by good
review. On average, 60% of defects occur during design and 40% during the
execution phase.
11)What group of teams can do software testing?
When it comes to testing everyone in the world can be involved right from
the developer to the project manager to the customer. But below are different
types of team groups which can be present in a project.
Isolated test team
Outsource - we can hire external
testing resources and do testing for our project.
Inside test team
Developers as testers
QA/QC team.
12)Does an increase in testing always improve the
project?
No an increase in testing does not always mean improvement of the product,
company, or project. In real test scenarios only 20% of test plans are critical
from a business angle. Running those critical test plans will assure that the
testing is properly done. The following graph explains the impact of under
testing and over testing. If you under test a system the number of defects will
increase, but if you over test a system your cost of testing will increase.
Even if your defects come down your cost of testing has gone up.
13)What's the relationship between environment reality
and test phases?
Environment reality becomes more important as test phases start moving
ahead. For instance, during unit testing you need the environment to be partly
real, but at the acceptance phase you should have a 100% real environment, or
we can say it should be the actual real environment. The following graph shows
how with every phase the environment reality should also increase and finally
during acceptance it should be 100% real.
14)What are different types of verifications?
Verification is static type of s/w testing. It means code is not executed.
The product is evaluated by going through the code. Types of verification are:
Walkthrough: Walkthroughs are
informal, initiated by the author of the s/w product to a colleague for
assistance in locating defects or suggestions for improvements. They are
usually unplanned. Author explains the product; colleague comes out with
observations and author notes down relevant points and takes corrective
actions.
Inspection: Inspection is a
thorough word-by-word checking of a software product with the intention of
Locating defects, Confirming traceability of relevant requirements etc.
15) Which test cases are written first: white boxes or
black boxes?
Normally black box test cases are written first and white box test cases
later. In order to write black box test cases we need the requirement document
and, design or project plan. All these documents are easily available at the
initial start of the project. White box test cases cannot be started in the
initial phase of the project because they need more architecture clarity which
is not available at the start of the project. So normally white box test cases
are written after black box test cases are written.
16)Explain Unit Testing, Integration Tests, System
Testing and Acceptance Testing?
Unit testing - Testing performed on a single, stand-alone module or unit of
code.
Integration Tests - Testing performed on groups of modules to ensure that
data and control are passed properly between modules.
System testing - Testing a predetermined combination of tests that, when
executed successfully meets requirements.
Acceptance testing - Testing to ensure that the system meets the needs of
the organization and the end user or customer (i.e., validates that the right
system was built)
17) What is a test log?
The IEEE Std. 829-1998 defines a test log as a
chronological record of relevant details about the execution of test cases.
It's a detailed view of activity and events given in chronological manner.
18)Can you explain requirement traceability and its
importance?
In most organizations testing only starts after the execution/coding phase
of the project. But if the organization wants to really benefit from testing,
then testers should get involved right from the requirement phase.
If the tester gets involved right from the requirement phase then
requirement traceability is one of the important reports that can detail what
kind of test coverage the test cases have.
19)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.
20)What is the difference between verification and
validation?
Verification is a review without actually executing the
process while validation is checking the product with actual execution. For
instance, code review and syntax check is verification while actually running
the product and checking the results is validation.
21) 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.
22)Can you explain calibration?
It includes tracing the accuracy of the devices used in the production,
development and testing. Devices used must be maintained and calibrated to
ensure that it is working in good order.
23)Can you explain cohabiting software?
When we install the application at the end client it is very possible that
on the same PC other applications also exist. It is also very possible that
those applications share common DLLs, resources etc., with your application.
There is a huge chance in such situations that your changes can affect the
cohabiting software. So the best practice is after you install your application
or after any changes, tell other application owners to run a test cycle on
their application.
24)What's the difference between System testing and Acceptance
testing?
Acceptance testing checks the system against the "Requirements."
It is similar to System testing in that the whole system is checked but the
important difference is the change in focus:
System testing checks that the system that was specified has been
delivered. Acceptance testing checks that the system will deliver what was
requested. The customer should always do Acceptance testing and not the
developer.
The customer knows what is required from the system to achieve value in the
business and is the only person qualified to make that judgement. This testing
is more about ensuring that the software is delivered as defined by the
customer. It's like getting a green light from the customer that the software
meets expectations and is ready to be used.
25)Can you explain the workbench concept?
In order to understand testing methodology we need to understand the
workbench concept. A Workbench is a way of documenting how a specific activity
has to be performed. A workbench is referred to as phases, steps, and tasks as
shown in the following figure.
Input: Every task needs some
defined input and entrance criteria. So for every workbench we need defined
inputs. Input forms the first steps of the workbench.
Execute: This is the main task of
the workbench which will transform the input into the expected output.
Check: Check steps assure that
the output after execution meets the desired result.
Production output: If the check
is right the production output forms the exit criteria of the workbench.
Rework: During the check step if
the output is not as desired then we need to again start from the execute step.