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.

Formal Technical Review - Fagan's Inspection Method

Fagan's Inspection Method is introduced by Fagon. Apart from checking codes of programs,it is used to check other work products such as technical documents, model elements, data and code design etc. It follows certain procedural rules that each member should follow:
- The time limit for an inspection meeting is for two hours.
- Inspections are led by a trained moderator.
- Inspections are carried out at a number of points in the process of project planning and systems development.
- All classes of defects in documentation and work product are inspected.
- Inspection is carried out by colleagues at all levels of seniority except the big boss.
- Inspectors are assigned specific roles to increase effectiveness.
- Statistics on types of errors are key, and used for reports which are analyzed in a manner similar to financial analysis.

Different activities that are involved in conducting inspections are:
- Planning is very important and in this case the moderator is asked to build up a plan.
- Presentation should be given which gives an overall overview.
- Each inspector is given 1 to 2 hours alone to inspect the workproduct.
- Meeting should be held in which participants of the meeting are the inspectors, moderator and the developer of the work product.
- The defect list is given for repair.
- Follow up with the repair work.
- Casual analysis meeting is held where inspectors are given a chance to express their personal view on errors and improvements.

What are Formal Technical Reviews (FTR)? What is the aim and guidelines for formal technical reviews?

When tasks are performed in software process, the result is a work product. These results contribute to the development of quality software.
A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives:
- uncover errors in function, logic or implementation of the software.
- verify that the software meets its requirements.
- ensure that the software has been developed according to the standards.
- achieve uniform software.
- make projects manageable.

Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.
The purpose of formal technical review serves as a training ground for junior engineers and to promote backup and continuity.
Constraints of formal technical review meeting’s include 3-5 people involvement, advanced preparation not more than 2 hours for each person, the duration of the review meeting should be less than 2 hours and focus on a specific part of a software product.

There are few guidelines while conducting formal technical reviews. They are:
- Work product should be reviewed and not the developer.
- Make a practice to write down notes while conducting reviews.
- Agenda should be planned.
- Minimize the debate and discussions.
- Keep the number of participants to a minimum and insist on preparing for the review.
- The defect areas should be pointed but no solution should be provided.
- A checklist that is to be reviewed is provided.
- Schedule the reviews as part of the software process and ensure that resources are provided for each reviewer
- Check the effectiveness of review.

What are different activities that comprise Software Quality Assurance?

To build a quality software, software quality assurance comprise of different activities. People involved are development team and software quality assurance team. The team of software quality assurance is responsible for quality assurance planning, overseeing, analyzing, record keeping, defects analysis and rework.

The activities encompassing software quality assurance are:
- Software Quality Assurance Plan is prepared by SQA team. They identify the evaluation to be performed, audits and reviews to be performed, standards that are applicable, procedures for error reporting and tracking, documents to be produced and amount of feedback required.
- SQA team checks if the selected software development process conform to the organizational policy and quality standards.
- SQA team monitor and track deviations from the software development process. It reviews software engineering activities.
- SQA team reviews, monitor and track defects found with each work products. Documentations are done to ensure that corrections have been made.
- The SQA team ensures that deviations in the software activities and work products are handled based on defined standard operating procedures.
- The SQA team reports deviations and non-compliance to standards to the senior management or stakeholders.

Software quality assurance plans saves time, money, increases productivity, enhances training, provides extra support.

What is Software Quality Assurance (SQA)? What are characteristics of a well-engineered software?

Software Quality Assurance(SQA) is a function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
- It is a subset of software engineering that ensures that all deliverables and work products are meet, and they comply with user requirements and standards.
- Its goal is to detect defects before the software isdelivered as a final product to the end-users.
- It includes quality management approach.
- It includes effective methods and tools.
- It includes formal technical reviews.
- It includes a multi-tiered testing strategy.
- It includes control of software documentation.
- It includes a procedure to assure compliance with software development standards, and measuring and reporting mechanism.

How do we say that the software is well-engineered?

- A software should be easy to use by the user.
- A software should have the capability to be able to execute on different platforms.
- A software should be able to transfer from one system to another.
- A software should be able to evolve and adapt to changes over time.
- A software should be reliable, secure and safe.
- A software should be capable of using resources efficiently.

A software has quality if it is fit for use, i.e., it is working properly. It should conform to explicitly stated user's external characteristics, explicitly documented quality standards and implicit characteristics.

Introduction To Software Reviews

What are software reviews?
- serves as a “filter” for the software engineering process.

Purpose: Software reviews serve to uncover errors in analysis, design, coding, and testing and are hence invaluable.

Why do software reviews? The general principle behind doing reviews are:
- To err is human.
- It may not be easy to catch the errors in engineers’ work, the kind of errors that are not found in bugs.
- Finding errors early in the process is always more efficient than detecting errors much later in the cycle.

A review is a way to :
- identify needed improvements of the various parts and modules of a product.
- confirm the improvement areas of a product (if the improvements had been suggested by others).
- achieve technical work that can be more uniform, predicable, and manageable, making for a more better end result and a smoother cycle.

What are the different types of reviews:
- Informal reviews : informal meeting and informal desk checking.
- Formal reviews : Walkthrough, inspection, and round-robin reviews.

Formal Technical Reviews are used to improve work products. As a part of this process, any deliverable that is produced during the development life-cycle is eligible to be reviewed and should be picked up for review starting at an early stage, beginning in the specification stage and recurring at each identifiable milestone.

- A Review meeting is an important part of the of FTR (Formal Technical Review). There are are some essential parameters for the meeting, such as
1. There should be a reasonable number of persons conducting the meeting, not being a free-for-all
2. Each one of them should have done his/her homework and other preparation
3. The meeting should not be carried out for very long and should have a well defined agenda to avoid wastage of time. The duration should be just enough to churn out some constructive results.
4. The Formal Technical Review is effective when a small and specific part of the overall software is under scrutiny.
5. A review is more productive when the review artefacts have been broken down into small modules that can be reviewed independently. The target of the FTR (Formal Technical Review) is on a component of the project, a single module.

- Record keeping and reporting are additional quality assurance activities. They are applied to different stages of software development. During the FTR, it is the responsibility of reviewer (or recorder) to record all issues that have been raised.
At the end of review meeting, a review issue list that summarizes all issues, is produced. A simple review summary report is also compiled. A review summary report answers the following questions.
1. What was reviewed?
2. Who reviewed it ?
3. What were the findings and conclusions?

- Review Guidelines : A minimum set of guidelines for FTR:
* Review the product, not the producer.
* Set an agenda and maintain it.
* Limit debate and rebuttal.
* Enunciate problem areas, but don’t attempt to solve every problem noted.
* Take written notes.
* Limit the number of participants and insist upon advance preparation.
* Develop a checklist for each work product that is likely to be reviewed.
* Allocate resources and time schedule for FTRs.
* Conduct meaningful training for all reviewers.
* Review your early reviews.