Requirements Testing

Requirements testing seem to be brief. They fly in and out of projects; they are unpredictable, inflexible and sometimes invisible. While gathering requirements we are looking for all the criteria for a system’s success. Some of the techniques Using gathering information for requirements testing are Blitzing, Rapid Application Development (RAD), Joint Application Development (JAD), Quality Function Deployment (QFD), interviewing, apprenticing, data analysis.

1. Abstract
Testing the software is an integral part of building a system. But if the software is based on inaccurate requirements, then with well written code software will be unsatisfactory.

2. The Quality Gateway:
As the requirement got singled out then testing can start. The aim is to catch requirements-related defects as early as identified. It would prevent from incorporating incorrect requirements in the design and implementation. To pass through the quality gateway, requirement must pass a number of tests. These tests are concerned about ensuring that the requirements are accurate. This will make sure that the requirement will not cause any problem in design and implementation in later stages.

3. Make the Requirement Measurable
There would be a quality measure for each requirement. Each requirement should have a quality measure that makes it possible to divide all solutions of the requirement into two classes: those which that fit into the requirement and those which that they do not fit into the requirement. In other words quality measure for a requirement means that any solution that meets the measure will be acceptable. Of course it is also true to say that any solution that does not meet the measure will not be acceptable. The quality measures are used for testing the new system against the requirements.

4. Quantifiable Requirements
Quantifiable requirement are those which the system respond quickly to customer enquiries. First thing to find a property of this requirement that provides us with a scale for measurement within the context.

5. Non-quantifiable Requirements
An attempt to define the quality measure for a requirement helps to rationalize fuzzy requirements. Something like “the system must provide good value” is an example of a requirement that everyone would agree with, but each person has his own meaning. By investigating the scale that must be used to measure “good value” identify the diverse meanings.

6. Coherency and Consistency
The requirements engineer has the intention that each requirement to be understood in the same way by every person who reads it. This subjectivity means that many systems are built to satisfy the wrong interpretation of the requirement. The obvious solution to this problem is to specify the requirement in such that it is understood in only one way.

Black Box Testing

Black box testing takes an external perspective of the test object to derive test cases. These test cases can be functional or non-functional. Usually functional test cases are called Black box testing. The test designer selects positive and negative cases and determines the adequate output. There is no information of the test object's internal formation.

1. Testing Strategies/Technique

* Black box testing should make use of randomly generated inputs, to eliminate any guess work by the tester as to the methods of the function.
* Data outside of the specified input range should be tested to check the robustness of the system.
* Boundary cases should be tested (top and bottom of specified range) to make sure the highest and lowest allowable inputs produce proper output
* The number zero should be tested when numerical data is to be input
* Stress testing should be performed, especially with real time systems
* Crash testing should be performed to see what it takes to bring the system down
* Test monitoring tools to track which tests have been performed and the outputs of these tests, to avoid repetition and to help in the software maintenance
* Other functional testing techniques include: Transaction testing, Syntax testing, Domain testing, Logic testing, and State testing.
* Finite state machine models can be used as a guide to design functional tests

2. Black Box Testing Strategy:

Black Box Testing is not a type of testing; it is a testing strategy. As the name "black box" indicates, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also named as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing against the functional specifications. It is becoming common to handle the Testing work to a third party as the developer of the system knows about the internal logic and coding of the system.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.

These testing types are again divided in two groups

a) Testing in which user plays a role of tester and

b) User is not required.


3. Advantages

More effective on larger units of code.

Tester needs no knowledge of implementation.

Tester and programmer are independent of each other.

Tests are done from a user's point of view.

Will help to expose any ambiguities in the specifications

Test cases can be designed as soon as the specifications are complete.


4. Disadvantages

Only a small number of possible inputs can actually be tested.

Without clear and concise specifications, test cases are hard to design.

There may be redundant test inputs if the tester is not informed of test cases the programmer has already tried.

May leave many program, paths untested.

Cannot be directed toward specific segments of code, which may be very complex.

Prototype Model

A prototype is a working model that is functionally equivalent to a component of the product. In many instances the client only has a general view of what is expected from the software product. In the case of absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed.
This model reflects increase the flexibility of the development process by allowing the client to interact and experiment with a working product model. The developmental process only continues once the client is satisfied with the functioning of the prototype. That time the developer come to know about clients real need.

Software prototyping

Software prototyping, is the creation of Beta versions, i.e., incomplete versions of the software program being developed.A prototype only contains a small subset of the features of the actual program, and the implementation is also not called robust.The purpose of a prototype is to allow users of the software to evaluate the design of the actual product by actually trying them out.

Benefits:
The software developer can obtain early feedback from the users. The client can compare if the software matches the software specification, according to which the software program is built. It will help to determine the developer to kept a goal of his own for the project.

Process of prototyping involves the following steps

1)Identify basic requirements
Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
2)Develop Initial Prototype
The initial prototype is developed that includes only user interfaces.
3) Review
The customers, including end-users, examine the prototype and provide feedback on additions or changes.
4) Revise and Enhancing the Prototype
Using the feedback both the specifications and the prototype can be improved.

Classifications

it can be classified as throwaway prototyping and evolutionary prototyping
Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software.
The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it.

Advantages

Reduced time and costs:
Improved and increased user involvement:

Disadvantages

Insufficient analysis:
User confusion of prototype and finished system:
Developer attachment to prototype:
Excessive development time of the prototype:
Expense of implementing prototyping:

Methods

Dynamic Systems Development Method (DSDM) is a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001 approved.
The four categories of prototypes as recommended by DSDM are:

• Business prototypes.
• Usability prototypes.
• Performance and capacity prototypes.
• Capability/technique prototypes.

Tools

Visual basic etc.