Professional Documents
Culture Documents
Requirements-based testing is a testing approach in which test cases, conditions and data are derived
from requirements. It includes functional tests and also non-functional attributes such as
performance, reliability or usability.
1
requirements. The ambiguity review produces a higher-quality set of requirements for review by the
rest of the project team.
4. Perform domain expert reviews. Feedback of users and domain experts should be used to refine
the requirements before additional work is done.
5. Structure and formalize requirements. To systematically achieve high test coverage formal and
structured representations of requirements need to be created. Multiple techniques can be used to
provide structure and formality to natural language requirements. The purpose of these techniques
is to reveal cause-effect relationships embedded within requirements, that is to express
requirements as a set of conditions (causes) and resulting actions (effects).
6. Logical consistency checks performed and test cases designed. A set of logical test cases can be
defined (manually or automatically), which is exactly equivalent to the functionality captured in the
requirements. However, this set of test cases may include many redundant cases (i.e. overlapping
with other test cases).
7. Review of test cases by requirements authors. The designed test cases are reviewed
by the requirements authors. If there is a problem with a test case, the requirements associated with
the test case can be corrected and the test cases redesigned.
2
8. Validate test cases with the users/domain experts. If there is a problem with the test case, the
requirements associated with it can be corrected and the test case redesigned. Users/domain experts
obtain a better understanding of what the deliverable system will be like.
9. Review of test cases by developers. The test cases are also reviewed by the developers. By doing
so, the developers understand what they are going to be tested on, and obtain a better understanding
of what they are to deliver so they can deliver for success.
10. Use test cases in design review. The test cases restate the requirements as a series of
causes and effects. As a result, the test cases can be used to validate that the design is robust enough
to satisfy the requirements. If the design cannot meet the requirements, then either the requirements
are infeasible or the design needs rework.
11. Use test cases in code review. Each code module must deliver a portion of the requirements.
The test cases can be used to validate that each code module delivers what is
expected.
12. Verify code against the test cases derived from requirements. The final step is to build test
cases from the logical test cases that have been designed by adding data and navigation to them, and
executing them against the code to compare the actual behavior to the expected behavior.
Software testing is process of Verification and Validation to check whether software application
under test is working as expected. To test the application we need to give some input and check if
getting result as per mentioned in the requirements or not. This testing activity is carried out to find
the defects in the code & improve the quality of software application. Testing of application can be
carried out in two different ways, Positive testing and Negative testing.
Positive Testing:
Positive Testing is testing process where the system validated against the valid input data. In this
testing tester always check for only valid set of values and check if an application behaves as
expected with its expected inputs. The main intention of this testing is to check whether software
application not showing error when not supposed to & showing error when supposed to. Such
testing is to be carried out keeping positive point of view & only execute the positive scenario.
Positive Testing always tries to prove that a given product and project always meets the requirements
and specifications.
Negative Testing:
Negative Testing is testing process where the system validated against the invalid input data.
A negative test checks if a application behaves as expected with its negative inputs. The main
3
intention of this testing is to check whether software application not showing error when supposed
to & showing error when not supposed to. Such testing is to be carried out keeping negative point of
view & only execute the test cases for only invalid set of input data.
Negative testing is a testing process to identify the inputs where system is not designed or un-
handled inputs by providing different invalid. The main reason behind Negative testing is to check
the stability of the software application against the influences of different variety of incorrect
validation data set.
The Negative testing helps to improve the testing coverage of your software application under test.
Both positive and negative testing approaches are equally important for making your application
more reliable and stable.
4
Testing. If the input data is picked outside the boundary value limits, then it is said to be Negative
Testing.
Equivalence Partitioning:
This is a software testing technique which divides the input date into many partitions .Values from
each partition must be tested at least once. Partitions with valid values are used for Positive Testing.
While ,partitions with invalid values are used for negative testing.
3. Compatibility testing
User Documentation covers all the manuals, user guides, installation guides, setup guides, read me
files, software release notes, and online help that are provided along with the software to help the
end user to understand the software system. User Documentation Testing should have two
objectives:-
1. To check if what is stated in the document is available in the software
2. To check if what is there in the product is explained correctly in the document
This testing is plays a vital role as the users will refer this document when they start using the
software at their location. A badly written document can put off a user and bias them against the
product even the product offers rich functionality.
Defects found in the user documentation need to be tracked to closure like any regular software
defect. Because these documents are the first interactions the users have with the product. A good
User Documentation aids in reducing customer support calls. The effort and money spend on this
effort would form a valuable investment in the long run for the organization. Testing documentation
involves the documentation of artifacts which should be developed before or during the testing of
Software.
Documentation for Software testing helps in estimating the testing effort required, test coverage,
requirement tracking/tracing etc. This section includes the description of some commonly used
documented artifacts related to Software testing such as:
Test Plan
Test Scenario
Test Case
Traceability Matrix
Benefits
Highlighting problems over looked during reviews.
It ensures consistency of documentation and product, thus minimizing possible defects
reported by customers.
Results in less difficult support calls.
New programmers and testers who join a project group can use the documentation to learn
the external functionality of the product.
8
Customers need less training and can proceed more quickly to advanced training and product
usage.
5. Domain testing
Domain testing can be considered as the next level of testing which is based on the domain
knowledge and expertise in the domain of application. It requires critical understanding of the day-
to-day business activities for which the software is written. This type of testing requires business
domain knowledge rather than the knowledge of what the software specification contains or how the
software is written.
The test engineers performing this type of testing are selected because they have in-depth knowledge
of the business domain. This reduces the effort and time required for training the testers in domain
testing and also increases the effectiveness of domain testing. Domain testing is the ability to design
and execute test cases that relate to the people who will buy and use the software. It helps in
understanding the problems they are trying to solve and the ways in which they are using the
software to solve them. It is also characterized by how well an individual test engineer understands
the operation of the system and the business processes that system is support.
Domain testing involves testing the product, not by going through the logic built into the product.
The business flow determines the steps, not the software under test. This is also called “business
vertical testing”. Domain testing is done after all components are integrated and after the product has
been tested using other black box approaches.