Quality Assurance & Quality Control

Here I discuss about Quality Assurance and Quality Control where people generally get confused in differentiating them. In this process I’ve discussed about the development life cycle of software as Quality Assurance is nothing taking care of entire process.

They go hand in hand. Quality Control is detecting defects and Quality Assurance is process to prevent them. First let me discuss about the Quality Assurance.

Quality Assurance is mainly related to the process we follow for entire development life cycle. We’ll not discuss about any particular life cycle, but a generic life cycle that has most of the attributes that we would expect to find in any specific examples. The software development lifecycle is always a good starting point for any discussion about software development processes, so in this first article we aim to build a solid foundation for all the topics we will cover in the future.

A software development lifecycle breaks down a software development project into a number of manageable phases. Each phase has processes that are followed and deliverables that are required before the next phase can begin. There are many variations on the phases of a lifecycle and the order in which they are tackled. In this article we will consider a software development lifecycle with five phases: Requirements, Design, Development, Implementation and maintenance (the last two being considered together). For each phase, we will provide a high level overview of the phase, outline its goals, objectives and exit criteria, and suggest simple ways to start accomplishing the specified objectives.

Requirements
The requirement phase is very important. Capturing complete requirements is not an easy task. From a business perspective, gathering requirements entails fully understanding what the system currently does, or what the current business processes are, in order to create a system to meet the users' needs. Requirements need to clearly specify what the system needs to do in order to accomplish the desired end result, so capturing and writing requirements is one of the most important activities in the whole software development lifecycle. The requirements phase is where the user identifies the business objectives of the system, together with the business rules, and rules for handling errors, exceptions and deviations. In some systems requirements are described as a series of use cases. A use case is an activity carried out by one of the roles, or actors, that interact with the system.

Objectives
There are numerous objectives within this initial phase of the software development lifecycle. One of the most important of these is to be certain all stakeholders involved in the project are on the same page. It is vital to be sure that everyone involved in the project understands what the project is intended to achieve. It is also essential to clearly define the scope of the project-what will be included and what will be excluded. The customer may have several objectives, and it is important to identify what is feasible with the available budget; some objectives may have to be deferred. The main risks and cost factors must also be understood, assessed and documented. There may be some risks associated with doing the project and there may be other risks associated with not doing the project.

How to accomplish the objectives?
Since the requirement phase is the beginning of the project, it is important to utilize this phase to set the standards for the phases that follow. It might be appropriate to hold a brief walkthrough meeting to check that the key stakeholders understand what the project is going to accomplish. The goal of this meeting is to walk through what has been gathered to this point and to be certain that all involved are in agreement with what is being proposed. It is a good idea to formulate and employ standard templates for the deliverables within this phase. This will ensure the same expectations are placed on each of the individuals involved.

The key deliverable from the requirement phase is the specification of requirements. This might be a single document or a collection of documents, but it should contain all the key information-objectives, business rules, scope, risks, costs, and eventually the use cases. Specific deliverable documents might include:

• A vision document
• A scope document
• The requirements specification
• A use case specification

A vision document is formulated by or with the user community. It states the customer's general vision of what the project is going to achieve. The vision document outlines the main requirements and the key features of the application. If there are constraints to the project, these will also be listed in the vision document.

A scope document outlines what is going to be accomplished with the project. It states what is in scope and what is out of scope. If the project is going to be finished in phases, it will outline what is going to be accomplished in each phase.

The requirement specification will include unambiguous, measurable and testable business rules. It is good practice to identify the current system's functionality, if there is an existing system, and what the new functionality is adding. This document can be as high level or as detailed as your team needs it to be.

Writing use cases involves identifying who the actors are. Actors define a particular role, job function or system that interfaces with the application. Identifying who the actors are gives you a starting point for writing use cases. Scenarios are built around what these actors will do with the application, or how the actor wants the application to perform. These scenarios will drive the functionality of the application.

Exit Criteria
Each phase of the software development lifecycle should have a set of exit criteria defined, so that it is possible to check that all of the essential processes associated with that phase have been completed before we move on to the next phase. One useful way to define and measure exit criteria is by using a simple checklist. A checklist is a great quality control tool. It is just a list of objectives that need to be met and the criteria by which you can judge whether each objective has been met. If you make sure that all the phase deliverables are complete, consistent and without any obvious defects as early in the development lifecycle as possible, you will significantly reduce the problems that arise later in the lifecycle. For example, just by reviewing the requirement specification and addressing the review comments you will minimize the errors that would otherwise multiply as you proceed to subsequent phases.

These two criteria would be excellent candidates for the Requirements Specification Checklist: Have the requirements been reviewed, and have all the comments been addressed?

When developing the exit criteria for the requirement phase, ask, what needs to be complete before the next phase can begin? As well as the key criteria already mentioned, you might want to include the existence of the four deliverables mentioned earlier in your exit criteria for the requirements phase. Be sure the Vision and Scope documents are properly formulated and reviewed, and the Requirements and Use Case Specifications are created and reviewed as well.

Design
In the design phase, the developer employs the use cases to get a logical view of what needs to be developed, and analyzes the requirements to ensure the design effort can begin. It is at this point that the developer calculates how to account for the planned capabilities listed in the requirements. Test cases are also written in the design phase based on the use cases and any design changes.

Review meetings are completed in the design phase to ensure the design meets the requirements as well as reviewing the test cases to secure test readiness. By conducting reviews, the team members are prepared for code functionality along with what is being tested.

Objective
One purpose of the design phase is to analyze the problem that needs to be solved; another is to design the solution. This is where the architectural foundation is created and the project risks are addressed. The architecture is designed based on the decisions made in the requirements phase. A decision on how to create the system architecture requires an understanding of the scope of the project, the basic functionality, and any nonfunctional requirements. The scope, together with the risk associated with the project, will determine how the project evolves.

These two factors, scope and risk, will help to determine whether prototyping is necessary to fully understand the requirements. A prototype is a system model that the developer builds, and having an executable prototype may allow the user community a window of opportunity to view the design up close. It may also permit the user community to mitigate the risk of the project appropriately, and prepare the customer for the basic functionality of the system. The design phase will analyze the use cases that have been identified in the requirement phase. If the requirements changed or need to be updated because the design couldn't account for the exact requirements, the use cases and test cases will also need to be updated or revised as well.

The design phase will analyze the use cases that have been identified in the requirement phase. If the requirements changed or need to be updated because the design couldn't account for the exact requirements, the use cases and test cases will also need to be updated or revised as well.

A few of the deliverables in the design phase include:
• Design model
• Architecture description
• Test model

A design model is a visual representation of how the use cases that were identified in the requirements phase will be implemented.

An architecture description describes the how the system will be built. It identifies the behaviors of the system, and includes features like style and aesthetics of the application.

The test model is an illustration of what is going to be tested. It includes, but is not limited to, identifying specific test cases and their expected results.

Exit Criteria
In order for the project to move from the design phase to the construction phase of the software development lifecycle, be sure that the exit criteria for the design phase have been met. To establish the exit criteria, look first to the deliverables. Be sure the design model has been developed, the description of the architecture has been written down and the test model created.

Development
The development phase is where the system is created based on the established baseline of the requirements and the design. The development phase will take into account ongoing management of resources, schedules and quality. There are many objectives of the development phase, including the minimization of costs associated with rework and the maintenance of adequate quality levels, while developing the software according to the requirements.

Objectives
To help minimize costs associated with development such as rework and waste it is wise to use a framework of pre-developed objects and libraries wherever possible. The framework and libraries contain pre-coded and tested objects that adhere to the standards of the organization developing the software.

In addition to using pre-coded objects, it is helpful to establish rules and guidelines for the developers to follow while creating the software application. These standards will set the groundwork on how to develop the application using best practices in relation to specific objects, controls and other issues the developer will encounter while writing the code to create the software. The standards may address concepts such as naming conventions, memory management, error handling, and reuse. Several standards will be written in a generic manner to relate to all software development, but there will also be a need to create standards that are specific to particular development languages and platforms.

Training is also a major consideration that will need to be taken into account when identifying the team that will construct the software. If, for example, the current development project team is unfamiliar with the architecture or development language the costs of actually creating the software could escalate exponentially. By properly training and using trained resources, the costs associated with rework and waste could be dramatically reduced.

To maintain appropriate quality levels from a code point of view, rely on the framework, libraries and standards that have been utilized, tested, and established. If the objects used for development are taken from libraries and new objects are created using standards, the developer can start with quality components and will be enabled by proper training to continue creating quality components.

To maintain appropriate quality levels from a code point of view, rely on the framework, libraries and standards that have been utilized, tested, and established. If the objects used for development are taken from libraries and new objects are created using standards, the developer can start with quality components and will be enabled by proper training to continue creating quality components.

How to accomplish the goals?
To document standards for developers, identify and use those standards already written for the industry but add to that list as necessary so it includes the specific standards required by the organization. Once the standards are documented, ensure their use is successful by training and mentoring the developers on the standards and how to use them. With the standards in place a component library can be created utilizing the standards. To create the component library start by using objects that have already been written for past projects and create new components that are standard and used often. Verify that all components pass the standards criteria and have been thoroughly tested before committing the component to the library.

Exit Criteria
The exit criteria of the development phase include a build of the system that is comprised of all required functionality and that operates within the quality standards as verified by reviews and validated by testing. In the development phase the software goes through iterations in which the software is modified and additional functionality is implemented into what is called a build. A build of the software is a component of the application that may or may not consist of all required functionality that will be included in the final product. After the build is compiled, it is validated and verified by the testing team to assure that the product functions as designed and the quality standards have been adhered to. When all functional components have been implemented into the product, a final build is given to the testing team for validation, verification, and sign off. Once the product is signed off it is ready for implementation and maintenance.

Implementation & Maintenance
Implementing a software product involves many tasks that must be accomplished successfully before the end user can make effective use of the software. Implementation of the developed software should also take into account the necessary training material and systems support material which will help assure the end users' ability to successfully use the delivered software. Imagine what it would be like to have a piece of software available for your use in which there were no user manuals, training or support. It is likely that the software would not be used at all.

When an application is in the maintenance phase, the software is maintained in a manner that will assure successful operation for continued daily usage.

The implementation of systems support material will play a large role in the maintenance phase of the developed software. The systems support material should include a mechanism by which end users can obtain assistance or report problems related to the software. In maintenance mode, it is common for the software to be enhanced or repaired, as the users of the system report problems or issues.

Objectives
Preparing and supporting end user systems

The support of end user systems may need hardware and services to be in place prior to application deployment. For example, the front end Graphical User Interface (GUI) of some applications may be accessed through a Web browser from a PC connected to the Internet. In order for users to access a Web application, the necessary infrastructure must be in place. In the case of an Intranet application, a Web application that is not delivered through the Internet but through a corporate Local Area Network (LAN), the end users need to be connected to the network in order to access the applications.

Regression Testing Enhancements and Repairs
When problems or issues related to the software surface, they usually require a change or a fix to the system. This will usually involve adding or modifying code to facilitate new or changed functionality. In this scenario, it is necessary to perform regression testing to ensure that the unchanged parts of the system continue to function as designed. Regression testing aims to validate the software by testing all existing functionality within a given build of the software. When both functional testing of the changes and regression testing have been completed and signed off, the new version of the system can be released to the user community following the implementation guidelines.

Training material and systems support material
If users are to successfully use a software application, they may first need to be trained on how to use the system. It is very important to the success of a software development project that the customers understand exactly how to use the application. The training materials needed for implementation are those items needed for any successful training endeavor: user guides, slides for classes, and so forth. The systems support material will enable customers to obtain support for setting up the system. This can include installation notes, procedures for installation and release notes that indicate known defects and the related workarounds. Systems support also includes a support structure for end users who have questions or issues with the software while it is in production. The user community may need to have access to a human being to resolve some issues. It is important that this support unit is as efficient as possible while tracking and documenting all issues. Such a support structure will prove to be an invaluable asset in providing support to not only to the customer but also to the development side of the house while the application is in maintenance mode.

How to accomplish the goals?
In preparing the end user system for deployment, consider the software requirements and the plan, which describes what components will be needed for the end user. The software requirements could identify additional or upgraded hardware components to the current client configuration or access to different sub systems on the wide area network. In any case the software requirements should identify the components needed to successfully implement the system.

A technical writer should create the user documentation for a system. The documentation can be created when the software requirements are established. The documentation will serve to educate users on how to install the software and use the software to perform specific tasks. Once user documentation is completed, training materials can be created, based on the user documentation, to educate the end users and support teams on using the most common functions and features within the software. Additional training materials will be needed for the support teams on how to troubleshoot the system.

Functional and regression testing can be accomplished by reusing the test assets-test cases and scripts-which were used to test the system prior to production, along with new test assets to verify both the existing and new functionality. To help maintain the current and future builds of the software and its related assets, we would implement the activities associated with configuration management.

Exit Criteria
The exit criteria for the implementation & maintenance phase are:
• Software that is successfully deployed to the user community
• A successfully trained user community
• Comprehensive and well-maintained support and maintenance for the software

Conclusion
The phases outlined here represent the major phases in a typical software development lifecycle. This is not to say that these phases are a standard; they represent one possible type of lifecycle from a choice of many. Whatever lifecycle we choose, however, the key phases discussed here will be needed in some form. During each phase there are inputs, objectives and deliverables. While an article such as this cannot be exhaustive in its coverage, we have attempted to address the objectives that we believe are most important for each phase. In future columns we will examine how quality assurance compliments quality control and the development lifecycle in completing the objectives and deliverables.

If you have any comment on the topic, post it for further discussion.

I'll be coming soon with next topic.