Embed Size (px)
DESCRIPTION
Testing Related Document by Ravinder
Citation preview
Ravinder Puranam
Testing related Document - Questions and Answers:
Q: Why Testing / Quality is required?
A: Testing is the process to verify that the Software Application / Hardware Module has
satisfied specified requirements or to identify differences between expected and actual
results, where Test Engineers main intention is to find bugs / problems.
Q: What is the Goal of Testing?
A: The main goal of testing is to check if the system meets the user requirements and
check for the systems reliability. Many say that the Goal of testing is to find Bugs / errors
Q: What is Software testing?
A: Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. Software testing also
provides an objective, independent view of the software to allow the business to
appreciate and understand the risks of software implementation. Test techniques include,
but are not limited to, the process of executing a program or application with the intent of
finding software bugs (errors or other defects).
Different software development models will focus the test effort at different points in the
development process. Newer development models, such as Agile, often employ test
driven development and place an increased portion of the testing in the hands of the
developer, before it reaches a formal team of testers. In a more traditional model, most of
the test execution occurs after the requirements have been defined and the coding process
has been completed.
Q: What are SDLC and STLC?
A: SDLC is Software Development Life Cycle which has phases like Analysis, Design,
Development / Coding, Testing and Maintenance. These again can be followed in
different models like 1.Water fall model; 2.V-model; 3.Fish model; 4.Proto type model
(Application developed without functionality); 5.spiral model; 6.Itterative model; 7.RAD
model (Rapid application development) that means every company has its own model.;
8.Pett model: process experts tools and techniques HCL Chennai.; 9. Agile Model
STLC is Software Test life cycle, this starts in the Testing Phase of SDLC, but the actual
STLC starts from Analysis phase of SDLC. Testing in STLC can be performed in Top-
Down approach, Bottom-Up approach and Hybrid approach.
* Each Software Development Life Cycle has its own Advantages and Disadvantages.
Ravinder Puranam
Q: Difference between SDLC and STLC?
A: STLC is the sub phase of the SDLC. SDLC takes care of all the phases of the project
including STLC where as STLC only concentrates on the Testing phase of the project.
Q: What happens in the phases of SDLC and STLC?
A: Below is a table which will describe the tasks performed and output Documents from
each phase of SDLC and STLC, ** these can change depending on the SDLC Model that
the project / company is using
SDLC STLC
Requirement Analysis Phase
(BR Docs / FRS / SRS / Use case
Docs)
Requirement Analysis
Use the Docs from Requirement Phase of
SDLC
Design Phase (HLD, LLD Docs) Prepare Test Strategy, Test Plan, Test Bed
Use Docs from 2 phases of SDLC
Development (or) Coding Phase
Prepare Test Environment Setup, Writing
Test Scenarios and Test Cases
Use Docs from 3 phases of SDLC
Testing Phase Review Test cases, Execute Test cases and
Bug Tracking
Maintenance Test metrics and any support to the
concerned support team
Q: What is a Test Plan or Quality Plan??
A: A Test / Quality Plan is a Document which has all the information on how the
Software / Hardware / Product needed to be tested, i.e., It says how the eventual Testing
workflow will be.
A Test Plan is usually prepared by a QC-Lead / Manager but with significant input from
Test Engineers.
Test Plan has information like:
Project Introduction; Test Modules / Items; Features to be tested; Features not to be
tested; Types of Testing / Approach to be followed; Entry and Exit criteria; Risks;
Testing needs; Test deliverables & tasks; Staffing and training needs; Schedule;
Approvals; Glossary; etc,.
Q: Who writes test cases and how do you verify all test cases are covered?
A: Test Engineer writes test cases which are reviewed by Team Lead. Using Traceability
Matrix, requirement change documents we can verify that all the test cases have been
covered.
Ravinder Puranam
Once the test cases are approved by the Team Lead, Test cases are executed depending
on the Entry criteria in the Test Plan i.e. 1. After Sanity Testing from developer (Is the
Basic Testing performed to assure that the system or methodology works as expected,
often prior to a more exhaustive round of testing) or 2. Module wise testing or any other
conditions etc
Q: Difference between Sanity testing and Smoke testing?
A: Sanity testing: Is an Initial effort to check whether the new released application build
from development team. The basic features of the application are tested to verify the
stability of the application for further testing. Basic GUI functionality, connectivity to
database, etc are concentrated here.
Smoke Testing: Smoke testing is testing most crucial functions of the application to start
with further testing / Regression testing and to approve the build for verification testing.
Hence it is also called as Build verification test (BVT)
Q: Difference between Re-testing and Regression testing?
A: Re-testing is testing ONLY executing the bugs/test cases which are raised in earlier
builds and said to be fixed in the current released Build.
Whereas Regression testing is executing all the test cases which are to be tested in any
newly released build irrespective of pass/fail in earlier build so as to check if no new bugs
are introduced due to the fixes done.
Q: What is INTEGRATION testing?
A: Integration testing is any type of software testing. This is done by developing some
scenarios which are most unlikely that seeks to verify the interfaces between components
against a software design.
Q: What is System Testing?
A: System testing of software or hardware is testing conducted on a complete, integrated
system to evaluate the system's compliance with its specified requirements. System
testing falls within the scope of black box testing, and as such, should require no
knowledge of the inner design of the code or logic.
Q: What is a bug?
A: A Bug is the common term used to describe an error, flaw, mistake, failure, or fault in
the Hardware or an Application program or system that produces an incorrect or
unexpected result, or causes it to behave in unintended ways. We can call an error by any
of the names.
Ravinder Puranam
Q: Difference between Functional and non-functional testing?
A: Functional testing refers to activities that verify a specific action or function of the
code. These are usually found in the code requirements documentation, although some
development methodologies work from use cases or user stories. Functional tests tend to
answer the question of "can the user do this" or "does this particular feature work".
Non-functional testing refers to aspects of the software that may not be related to a
specific function or user action, such as scalability or other performance, behavior under
certain constraints, or security. Non-functional requirements tend to be those that reflect
the quality of the product, particularly in the context of the suitability perspective of its
users
Q: What are Testing methods??
A: Software testing methods are traditionally divided into white- and black-box testing.
These two approaches are used to describe the point of view that a test engineer takes
when designing test cases.
White box testing is when the tester has access to the internal data structures and
algorithms including the code that implement these.
Types of white box testing
The following types of white box testing exist:
* API testing (application programming interface) - testing of the application
using public and private APIs
* Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the
test designer can create tests to cause all statements in the program to be
executed at least once)
* Fault injection methods - improving the coverage of a test by introducing faults
to test code paths
* Mutation testing methods
* Static testing - White box testing includes all static testing
Black box testing
Main article: Black box testing
Black box testing treats the software as a "black box"—without any knowledge of
internal implementation. Black box testing methods include: equivalence partitioning,
boundary value analysis, all-pairs testing, fuzz testing, model-based testing, exploratory
testing and specification-based testing.
Specification-based testing: Specification-based testing aims to test the functionality of
software according to the applicable requirements. Thus, the tester inputs data into, and
only sees the output from, the test object. This level of testing usually requires thorough
test cases to be provided to the tester, who then can simply verify that for a given input,
Ravinder Puranam
the output value (or behavior), either "is" or "is not" the same as the expected value
specified in the test case.
Specification-based testing is necessary, but it is insufficient to guard against certain
risks.
Advantages and disadvantages: The black box tester has no "bonds" with the code, and a
tester's perception is very simple: a code must have bugs. Using the principle, "Ask and
you shall receive," black box testers find bugs where programmers do not. On the other
hand, black box testing has been said to be "like a walk in a dark labyrinth without a
flashlight," because the tester doesn't know how the software being tested was actually
constructed. As a result, there are situations when (1) a tester writes many test cases to
check something that could have been tested by only one test case, and/or (2) some parts
of the back-end are not tested at all.
Therefore, black box testing has the advantage of "an unaffiliated opinion", on the one
hand, and the disadvantage of "blind exploring", on the other.
Grey box testing
Grey box testing (American spelling: gray box testing) involves having knowledge of
internal data structures and algorithms for purposes of designing the test cases, but testing
at the user, or black-box level. Manipulating input data and formatting output do not
qualify as grey box, because the input and output are clearly outside of the "black-box"
that we are calling the system under test. This distinction is particularly important when
conducting integration testing between two modules of code written by two different
developers, where only the interfaces are exposed for test. However, modifying a data
repository does qualify as grey box, as the user would not normally be able to change the
data outside of the system under test. Grey box testing may also include reverse
engineering to determine, for instance, boundary values or error messages.
Q: What is Acceptance testing?
A: Acceptance testing can mean one of two things:
1. A smoke test is used as an acceptance test prior to introducing a new build to the main
testing process, i.e. before integration or regression.
2. Acceptance testing is performed by the customer, often in their lab environment on
their own hardware, is known as user acceptance testing (UAT). Acceptance testing may
be performed as part of the hand-off process between any two phases of development.
Q: What is Alpha and Beta Testing?
A: Alpha testing: Alpha testing is simulated or actual operational testing by potential
users/customers or an independent test team at the developers' site. Alpha testing is often
employed for off-the-shelf software as a form of internal acceptance testing, before the
software goes to beta testing.
Ravinder Puranam
Beta testing: Beta testing comes after alpha testing and can be considered a form of
external user acceptance testing. Versions of the software, known as beta versions, are
released to a limited audience outside of the programming team. The software is released
to groups of people so that further testing can ensure the product has few faults or bugs.
Sometimes, beta versions are made available to the open public to increase the feedback
field to a maximal number of future users
Q: What is Bug Life Cycle?
A: A Bug Life Cycle is defined in the below picture:
Bug status description:
These are various stages of bug life cycle. The status caption may vary depending on the
bug tracking system you are using.
1) New: When Tester / QA files New bug.
2) Open: Once the Tester files a New bug and is opened by the project lead or manager or
any authorized person of the project. Then the bug is in Open state
3) Assign: ‘Assigned to’ field is set by project lead or manager and assigns bug to
‘developer’, then the bug is in Assigned state
4) Rejected/Invalid: Sometimes developer or team lead can mark the bug as Rejected or
invalid if the system is working according to specifications and bug is just due to some
misinterpretation. This can also arise when the bug is non reproducible, then it is stated as
Ravinder Puranam
‘Could not reproduce’: If developer is not able to reproduce the bug by the steps given in
bug report by Tester / QA then developer can mark the bug as ‘CNR’. QA needs action to
check if bug is reproduced and can assign to developer with detailed reproducing steps in
case the bug is marked as Rejected by Developer and Bug is observed by the Tester / QA.
5) Deferred: If the bug is not related to current build or can not be fixed in this release or
bug is not important to fix immediately then the project manager can set the bug status as
deferred.
6) Resolved/Fixed/Verified: When developer makes necessary code changes and verifies
the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing
team.
7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix
then QA can mark it as ‘Reopen’ so that developer can take appropriate action.
8) Closed: If bug is verified by the QA team and if the fix is ok and Bug / problem is
solved then QA can mark bug as ‘Closed’.
Sometimes developer can give information as ‘Need more information’: If developer is
not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she
can mark it as “Need more information’. In this case QA needs to add detailed
reproducing steps and assign bug back to developer to fix.
** Most of the other questions if any in an interview will be related to project and project
related testing.
