What are different functional specifications while drawing a test plan?

The successful completion of the software testing cycle depends entirely up on the quality of its test plan. Any test plan is composed of certain specifications which are not to be missed if you want your plan to be effective. Specifications are of two types namely:

1. Functional specifications and
2. Design specifications.

What are functional specifications?

- Functional specifications which are nothing but a formal document that is created for the purpose of describing a detailed overview of the software system’s or application’s intended functions and capabilities.

- It describes in detail the appearance of the software application as well as how it is to interact with the users.

- The functional specifications can be thought of as guidelines or references by the program developers and programmers while the development of the software is in progress.

- The functional specifications for the software system or application that are equipped with some windows and dialogs are aimed at showing the visual appearance of its user interface and also to give a detailed description of all the possible inputs from the users and the reactions of the application to them.

- A functional specification may or may not include a formal description of the dependency of the application on other programs or applications, usability criteria and user tasks.

- To define a functional specification formally we can say that it is to describe the solution technically and is also used as a representation of the contract between a client and project development team.

- It forms the basis for building any application.

What are different functional specifications while drawing a test plan?

- While drawing the test plan, the program manager baselines the functional specifications which are placed under the change control since it sustains all the information that is needed to design the solution.

- Functional specifications seek to incorporate logical, physical and conceptual designs in to the solution for making it more efficient.

- All the high level design decisions regarding the network configurations and server management should also be included under the functional specifications.

What aspects should a functional specification include?

A typical functional specification describes the following aspects:

1. Summary of the project scope (as agreed up on the by both parties in a business context).

2. Any additional requirements

3. The design of the solution

4. Specifications of the components that form a part of the solution

5. Features:
Documentation of all the planned features along with their quantitative specifications such as performance metrics, concurrent user capacity, and data base capacity and so on.

6. Security requirements:
Specifications regarding the strength of security concerning the functions that involve working with sensitive data like transactions. The encryption standards that have been implemented in the security mechanism should also be mentioned along with the location and type of the security mechanisms.

7. Legal requirements:
These must be clearly stated along with the custom codes to me business policy, custom user scenario or a governmental requirement etc.

8. Risk assessment:
This documentation must include the descriptive details about:
- potential vulnerabilities,
- mitigation strategies and
- the impact of the above strategies and vulnerabilities on the application.

There should be no ambiguity in the description of the above stated aspects and the quantitative measurements should be used wherever possible.

What aspects should a functional specification should not include?

Now we list the aspects that should not be included in the functional specifications:
1. Detailed data base schema
2. Details of the software architecture
3. Details about the programming language

Data base details suffice the purpose of the functional specifications and save the development team from extraneous efforts.
The functional specifications are changed only with the due permission of the client. Functional specifications are the living documents i.e., they are continuously updated throughout the development cycle and show how a solution can be deployed in a timely and cost effective manner.

What are different characteristics of non-functional testing?

Non functional testing can be defined as the testing of the software system or the application for its all non functional requirements. It happens many times that the names of the non functional requirements get overlapped during the non functional testing.

Therefore, the name so the non functional requirements are used interchangeably many times. Non functional testing includes various testing aspects. Few have been given below:
- Compatibility testing
- Baseline testing
- Compliance testing
- Endurance testing
- Documentation testing
- Internationalization testing
- Localization testing
- Load testing
- Recovery testing
- Performance testing
- Security testing
- Resilience testing
- Scalability testing
- Usability testing
- Volume testing
- Stress testing

In non functional testing, typically the software system or the application is tested against the specifications and conditions listed by the client or the customer.
Non functional testing is entirely based upon the test cases and specifications and the requirements stated by the customer or the client.

Apart from the above listed non functional requirements aspects there are several other aspects covered by the non functional testing. They have been listed below:
- Ergonomics testing
- Migration testing
- Data conversion testing
- Penetration testing
- Installation testing
- Operational testing
- Readiness testing
- Application security testing
- Network security testing
- System security testing

Non functional testing is carried out only after the functional testing has been successfully completed on the software system. Earlier, non functional testing was not considered important. But, eventually software engineers started realizing its importance and they began to concentrate on the extra external feature of the whole software and the hardware system like reliability, interface testing and configuration testing. So, the non functional testing came to the scene and has got a great importance in the field of software development.

Comparison between functional and non-functional testing
- Functional testing gives coverage and concentrates on the relevant functionality or part of the software system or the application whereas non functional testing focuses primarily on the irrelevant components or functionality of the whole software system. The best example is given by graphical user interface or GUI which is also known as look and feel testing.

Generally non functional requirements include performance, volume, stress, load, and security, recovery etc and so on.

- Manual testing as an aspect of non functional testing relates to the testing of functionality which are simply not mentioned in the functional requirements documentation. This is how manual testing and non functional testing is related to each other.

- Functional testing relates to the business documents, requirements documents, test plans and exact mapping of the variables. Non functional testing is in great contrast with the functionality testing.

- Functional testing deals with the stability of the software system or the application. For example, it checks how the software system or the application responds to the irrelevant data input for some function. Non functional testing is a kind of ad hoc testing. But it also checks the stability.

Non functional testing tests the requirements of a software system that do not relate to the functionalities of the software system or application. These non functional requirements include fail over and recovery, social-ability, performance, stress, security and so on.

Non functional testing is to test the features and specifications and the stability of the software system which don’t correspond directly to the business related functionalities i.e., functional requirements, but are equally necessary.
In non functional testing you can look and feel the objects. For example, the installation testing.

Some best practices that contribute to improved software testing

There is always a serach for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The basic practices are like training wheels which you need to get started and when you take them off, you know ow to ride. The basic practices include:

- Functional Specifications
It is basically a development activity but it is also necessary for software functional test. It defines the external view of an object or procedure. It helps the test generation activity to move in parallel with code development. It helps in the clarity from designer's and an architect perspective.
- Reviews and Inspections
Software reviews and inspection provides a ten times gain in debugging process.
- Formal entry and exit criteria
This practice offers a careful management of software development process. Every process step has a precise entry and exit criteria defined by development process and management keeps a track of the movement from one stage to another.
- Functional test varaitions
This practice involves understanding how to write variations which refers to combination of input condition to yield a output and gain coverage to thoroughly test the function.
- Multi platform testing
Today products run on different platforms so the necessity arises of designing and testing the product for different platforms. This practice addresses aspects of multi platform development and testing.
- Internal betas
Beta means the product is released to few customers and their feedback is recorded. This practice deals with beta programs to best levarage it and reduce cost of external beta.
- Automated test execution
Using automated test execution, the amount of manual work is minimized and higher coverage is gained. This is the best practice which is well understood in some areas. This practice needs to levarage and then develop methods for areas where automation is not fully done.
- Beta programs
- Nightly builds
Nightly build captures frequent builds from changes that being promoted. Advantages include firstly, errors are captured quickly if major regression occurs. Secondly, regression tests can run in background. Thirdly, newer releases of software are available to developers and testers sooner.

Software requirements - Functional requirements

Most of the software requirement specifications given today have functional requirements. Functional requirements are the descriptions of the behaviors expected from the software in the given conditions. Functional requirements may include calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to achieve. It is pretty easy to deduce why emphasis is given to these specifications but nonfunctional software requirements are also equally important. The functional requirements are supported by the nonfunctional requirements which impose constraints on the design or implementation. Nonfunctional requirements specify overall characteristics such as cost and reliability.
Nonfunctional requirements are sometimes interchangeably called as quality requirements. These quality requirements add quality attributes, quality factors and quality of the service in the software requirements. Some of the nonfunctional requirements include usability, portability, reliability, availability, efficiency, Integrity, security, safety, robustness and performance. These include both the internal and external quality aspects which are important to users and developers respectively.
The most difficult part of the nonfunctional requirements is specifying the quality attributes but once specified they provide an edge from the other available products. The nonfunctional requirements turn an ordinary product that serves the purpose to a delightful product. One cannot expect customers to like the product unless the quality attributes are explicitly specified. It is important to outline these specifications because sometimes these specifications propel significant architectural and design decisions and there would be a lot of wastage of resources in case re-designing is required.
A low point of these attributes is that they have a seesaw effect. The most prominent conflict is between the efficiency and most other attributes. For example addition of more layers of security cause a decline in the efficiency and similarly improvement in efficiency might affect the maintainability features. Hence it is extremely critical that user and developers decide on which attributes are more important for the product.
While giving the quality requirements the most common mistake that is made is giving abstract specifications which are in relative terms and are not verifiable. If a specification is given that the product should be user friendly then there is no way to enforce quality on the user friendliness of the software unless explicitly specified. One of the specifications that can be given is that the availability standard at the minimum should be 90% and the desired availability standard is 95%. Although it is more tempting and less time consuming to demand 24 hours availability but its serves as the best recipe to make all the project stakeholders to move towards a common objective.

RS232 Standard

RS232 is a asynchronous serial communication protocol widely used in computers and digital systems. It is called asynchronous because there is no separate synchronizing clock signal as there are in other serial protocols like SPI and I2C.
In RS232 there are two data lines RX and TX. TX is the wire in which data is sent out to other device. RX is the line in which other device put the data it need to sent to the device.
Voltage levels in RS232 are HIGH=-12V and LOW=+12V.

RS-232 Specifications :
- Cabling : Single-ended
- Number of Devices : 1 transmit, 1 receive
- Communication Mode : Full duplex
- Distance(max) : 50 feet at 19.2kbps
- Data Rate(max) : 1Mbps
- Signaling : Unbalanced
- Mark(data 1) : -5V (min) -15V (max)
- Space(data 0) : 5V (min) 15V (max)
- Input Level(min) : ±3V
- Output Current : 500mA
- Impedance : 5kW (Internal)
- Bus Architecture : Point-to-Point

RS232 Data Transmission :
Transmission
1. When there is no transmission the TX line sits HIGH (STOP CONDITION).
2. When the device needs to send data it pulls the TX line low for 104uS (This is the start bit which is always 0).
3. Then it sends each bit with duration of = 104uS.
4. Finally it sets TX lines to HIGH for at least 104uS (This is stop bit and is always 1).
Reception :
1. The receiving device is waiting for the start bit i.e. the RX line to go LOW.
2. When it gets start bit it waits for half bit time i.e. 104/2 = 51uS, i.e.it is in middle of start bit, it reads it again to make sure it is a valid start bit and not a spike.
3. Then it waits for 104uS and now it is in middle of first bit. It then reads the value of RX line.
4. In the same way it reads all the 8 bits.
5. Now the receiver has the data.

Limitations of RS232 Standard :
* The large voltage swings and requirement for positive and negative supplies increases power consumption of the interface and complicates power supply design. The voltage swing requirement also limits the upper speed of a compatible interface.
* Single-ended signaling referred to a common signal ground limits the noise immunity and transmission distance.
* Multi-drop connection among more than two devices is not defined. While multi-drop "work-arounds" have been devised, they have limitations in speed and compatibility.
* Asymmetrical definitions of the two ends of the link make the assignment of the role of a newly developed device problematic; the designer must decide on either a DTE-like or DCE-like interface and which connector pin assignments to use.
* The handshaking and control lines of the interface are intended for the setup and takedown of a dial-up communication circuit; in particular, the use of handshake lines for flow control is not reliably implemented in many devices.
* No method is specified for sending power to a device. While a small amount of current can be extracted from the DTR and RTS lines, this is only suitable for low power devices such as mice.
* The 25-way connector recommended in the standard is large compared to current practice.

The Cleanroom Strategy and Functional Specifications

The cleanroom approach makes use of a specialized version of the incremental process model. A pipeline of software increments is developed by small independent software teams. As each increment is certified, it is integrated into the whole. Hence, functionality of the system grows with time.

- Increment Planning : adopts the incremental strategy.
- Requirements Gathering : defines a description of customer level requirements (for each increment).
- Box Structure Specification : describes the functional specification.
- Formal Design : specifications (called “black boxes”) are iteratively refined (with an increment) to become analogous to architectural and procedural designs (called “state boxes” and “clear boxes,” respectively).
- Correctness Verification : verification begins with the highest level box structure (specification) and moves toward design detail and code using a set of “correctness questions.” If these do not demonstrate that the specification is correct, more formal (mathematical) methods for verification are used.
- Code Generation, Inspection and Verification : the box structure specifications, represented in a specialized language, are transmitted into the appropriate programming language.
- Statistical Test Planning : a suite of test cases that exercise of “probability distribution” of usage are planned and designed.
- Statistical Usage Testing : execute a series of tests derived from a statistical sample (the probability distribution noted above) of all possible program executions by all users from a targeted population.
- Certification : once verification, inspection and usage testing have been completed (and all errors are corrected) the increment is certified as ready for integration.

Functional Specifications :
Cleanroom Software engineering compiles with the operational analysis principles by using a method called box structure specification. A "box" encapsulates the system at some level of detail. Three types of boxes are used :
- Black box : It specifies a set of transition rules that describe the behavior of system components as responses to specific stimuli, makes use of inheritance in a manner similar to classes. It also specifies system function by mapping all possible stimulus histories to all possible responses.
S*->R i.e. stimulus history->responses
- State box : It is a generalization of a state machine, encapsulates the data and operations similar to an object, the inputs (stimuli) and outputs (responses) are represented, data that must be retained between transitions is encapsulated. The state is the encapsulation of the stimulus history. State variables are invented to save any stimuli that need to retained.
S x T -> R x T i.e. stimuli X state data -> responses X state data
- Clear box : It contains the procedural design of the state box, in a manner similar to structured programming. It specifies both data flow and control flow.
S x T -> R x T i.e. stimuli X state data -> responses X state data

BOX PRINCIPLES :
- Transaction closure of stimuli and responses
* Users and uses are considered including security and error recovery.
- State migration within box hierarchy
* Downward migration of state data is possible whenever new black boxes are created inside a clear box.
* Upward migration of state date is desirable when duplicate data is updated in several places in the tree.
- Common services
* Reusable boxes from library.