Quality Assurance should be a integral part of the development culture and not just some testing done as an afterthought. The focus of Quality assurance has two facets: to make sure we do the right things, and to make sure we do things right. Preparation refers to the analysis of documentation on what is required, while prevention refers to looking into the proper adherence to standards and methodology to improve the odds of getting the development done correctly. Quality Assurance is much more than testing. If you want to focus on testing only, click on the right arrow above for more information. Before you decide to limit your focus consider the other roles of QA.

We have often been asked why it should be QA's business to look into the analysis and coding steps rather than to concentrate on testing at the end of the project. The first answer is quite simply that any errors you can detect before the code is written saves you rewriting the code. The earlier you detect errors, the less work has to be redone, there is no science to it. The second answer is more to the point that you cannot test with certainty if the requirements that you test against are rather vague. You have to look at the same source information that the developers use to write the code, so if you are puzzled about how to test something there is a good chance that the developer is puzzled about how to code that same something. By insisting on the testability of requirements you can flush out a lot of potential problems before any code is ever written, and you have assurances that the resulting product can be tested.

Testing at the end of the development life cycle is only a safeguard against releasing unfit code into production, a final confirmation that everything works. There is little you can do other than to send the code back to get the bugs fixed, you cannot easily send things back to the drawing board to fix fundamental design flaws. Even with the best effort at QA along the way it is possible that the initial requirements were flawed and that the client will realize only at the last minute that what was asked for was wrong. The effort required of QA (and the analysts) is to do what they can to minimize that exposure by being vigilant at all stages of the development process. Below are some of the initiatives that will help minimize the exposure on your project:

Making sure we do the right things...

The idea is that QA confirms that there has been due diligence in gathering the requirements for a project (to develop or purchase a software product). We want to make sure it is not the project that is sold to the clients, as it should be the clients that ask for the project. The project team only sells a proposed implementation.

PM4HIRE.COM developed a comprehensive approach to requirements elicitation that ensures a thorough consideration of all things that might be part of a project. We know that most projects can only provide so much functionality, for budget reasons, but you cannot make an informed decision if there is incomplete information about what might be provided. From a QA point of view it is important to see that the appropriate effort has been made to gather complete requirements. There is no point to going any further because you would essentially replicate the requirements gathering process and it would be unlikely that you would add much value to the requirements elicitation that has been completed. What you want to look for is substance, you do not want to see a project go through the motions in order to deliver project documentation that does not add value to the process.

The reason we come in hard and fast here is that this is where most projects get pointed into the direction of success or failure (and there are more directions that lead to failure, by the way). We use requirements as the foundation for all other aspects of the development project. If that foundation is weak, the best result that can be expected is a weak product. You will generally find it difficult if not impossible to revisit the requirements later and to then upgrade the software. This will work for small enhancements but it will generally lead to failure if you are faced with fundamental flaws that need to be corrected. The only opportunity you have for intercepting this root problem is up front, by auditing the adequacy of the requirements elicitation process.

There is no simple set of guidelines for what is adequate and what is not. Even if the team has elicited all the requirements you cannot be sure that these are valid requirements. In fact, these can be precisely what clients ask for, and then when the product gets delivered it may dawn on the client that what was asked for is not quite what is needed. That risk is relatively small by comparison to the risk of inadequate requirements elicitation, so it makes sense that you concentrate on reviewing that the appropriate effort has been made to establish a solid foundation for the project.

Making sure that we do things right...

There is always a risk that QA is viewed as a bunch of "know it alls" because they have the responsibility for pointing out that a project may not adhere to proper methodology. It is best to be cool about things and to realize that nobody likes to get negative feedback, but you should be straight and to the point with your comments or it will come across as confused and wishy-washy. Truth is, we do not participate in the technical development, and it is quite possible that insisting on standards may not be the popular view in the project team.

PM4HIRE.COM is of the opinion that the main reason for standards is to produce maintainable software, even if that takes some extra effort. If it is decided that there are better ways to do things then the standards need to be adjusted to reflect that opinion, but it should not be left up to individuals to make decisions on whether to follow the methodology or not. You cannot check every aspect of the code but you can make sure that the appropriate naming conventions are followed in order to assist any future maintenance programmer who may have to make small changes.

Code and documentation go hand-in-hand. The QA team will generally focus on the documentation that will be used to guide the code development, and that will be used also to create test cases and test scripts. The first step is to make sure that all documentation is internally consistent, so that business requirements reconcile with user requirements, that reconcile with functional requirements, that reconcile with code specificiations. If you find any inconsistencies that may indicate that a part of the process has not been implemented correctly, and before you can think of testing you need to know what is accurate.

While the QA team will generally focus on the documentation in order to establish that the right functionality has been specified, that does not guarantee the actual program code itself will be correctly implemented. You could participate in code walkthroughs (explained below) if you have the technical expertise, or you can facilitate these walkthroughs, to learn about the actual quality of the coding itself. Needless to say that you have to have some level of technical expertise to perform this role.

Software development is always largely an art...

Each developer has a unique style that is a reflection of their personal ability, which is fine so long as that does not produce code that cannot easily be understood by others. In addition, the code that is produced must also faithfully reflect the true business requirements for which that code is implemented. It must not be subject to interpretation but it must be explicitly written to most clearly reflect business needs. Code Walkthroughs are a standard technique to subject code to peer reviews that address these concerns.

PM4HIRE.COM can facilitate the walkthrough process to make sure the intent is well understood and to prevent any discussions from becoming more personal than what might be considered healthy. Code development is highly subjective and what may be perfectly clear to one person may be poison to another. From a QA perspective you may not want to get into the debate over adequacy, leaving that instead for peer developers to comment on. The same caveat applies to the general maintainability of the code that has been produced. However, you want to insist that the code adheres to all naming conventions, especially with respect to the interfaces (files, screen layouts, etc.).

Standards, and specifically naming conventions, are implemented to make it easier to find information that is consistent across multiple systems. If a change is required then consistent naming makes it possible to find all other instances that may be affected. If a field is called "apple" in one program and "orange" in another you are faced with comparing apples and oranges to see where changes may be required. This goes well beyond the individual creative freedom that developers covet so much, and it is a legitimate QA concern to see that these naming conventions are properly adhered to.

The QA Team must educate itself to prepare for testing...

To provide a meaningful QA service the testing team must prepare for what is required to determine if a new product meets all the needs of the end-users. We recommend a 5-step process:

Testing Strategy: define an overall approach to the testing process, even if you have a standard set of practices. Based on the requirements you can determine what needs to be tested, and you can even set expectations of what it may cost to test a given system sufficiently thoroughly to meet all quality concerns.

Test Plan: analyze the detailed functional specifications for consistency with requirements and determine what is more or less important to test. This is necessary in case you do not have a budget large enough to cover all testing so that you can focus on the most critical testing needs first.

Test Scripts: write detailed step by step instructions for how the different test scenarios must be executed, including the specific input values as well as the expected output results. You may need to regression test the system in the future so make scripts understandable and maintainable.

Testing Schedule: work out a "who does what and when" list to make sure you can make the most of any testing opportunity, and that you are prepared with sufficient resources to meet the testing deadlines. Make sure people are focused on their work and that they do not interfere with one another.

Testing Results: keep track of the results from the testing with regular testing status reports. Determine ahead of time who needs to be informed of what and confirm in advance what the expectations are.