The best practices in software testing can be classified into the following types:
- Basic Best Practices
- Foundational Best Practices
Basic Best Practices
As the name indicates these are the best practices known to a tester with a minimal testing experience.
Functional Specifications
The testers use this to write down test cases from a black box testing perspective. The advantage of having a functional specification is that the test generation activity could happen in parallel with the development of the code. This is ideal from several dimensions. It gains parallelism in execution, removing a serious serialization bottleneck in the development process.
Reviews and Inspection
It is argued that software inspection can easily provide a ten times gain in the process of debugging software. Not much needs to be said about this, since it is a fairly well known and understood practice.
Formal Entry and Exit Criteria
The idea is that every process step, be it inspection, functional test, or software design, has a precise entry and precise exit criteria. These are defined by the development process and are watched by management to gate the movement from one stage to another.
Functional Test – Variations
Most functional tests are written as black box tests working of functional specs. The number of test cases that are generated usually are variations on the input space coupled with visiting the output conditions.
Multi-platform Testing
When code is ported from one platform to another, modifications are sometimes done for performance purposes. The net result is that testing on multiple platforms has become a necessity for most products. Therefore techniques to do this better, both in development and testing, are essential.
Internal Betas
Techniques to best conduct such an internal Beta test are essential for us to obtain good coverage and efficiently use internal resources. This best practice has everything to do with Beta programs though on a smaller scale to best leverage it and reduce cost and expense of an external Beta.
Automated Test Execution
The goal of automated test execution is that we minimize the amount of manual work involved in test execution and gain higher coverage with a larger number of test cases. The automated test execution has a significant impact on both the tools sets for test execution and also the way tests are designed.
‘Nightly’ Builds
The concept of a nightly build has been in vogue for a long time. While every build is not necessarily done every day. The concept captures frequent builds from changes that are being promoted into the change control system.
Foundational Best Practices
Unlike the Basics, they are probably not as well known and therefore need implementation help.
User Scenarios
One of the viable methods of testing is to develop user scenarios that exercise the functionality of the applications. This best practice should capture methods of recording user scenarios and developing test cases based on them. In addition it could discuss potential diagnosis methods when a specific failure scenario occurs.
Usability Testing
Usability testing needs to not only assess how usable a product is but also provide feedback on methods to improve user experience and thereby gain a positive quality image. The best practice for usability testing should also have knowledge about advances in the area of Human Computer Interface.
In-Process ODC Feedback Loops
Orthogonal defect classification is a measurement method that uses the defect stream to provide precise measurability into the product and process. Given the measurement, a variety of analysis techniques have been developed to assist management and the decision-making on a range of software engineering activities.
Multi-Release ODC/Butterfly
The technology of multi-release ODC/Butterfly analysis allows a product manager to make strategic development decisions so as to optimize development costs, time to market, and quality issues by recognizing customer trends, usage patterns, and the product performance.
“Requirements” for Test Planning
One of the roles of software testing is to ensure that the product meets the requirements of the clientele. Capturing the requirements therefore becomes an essential part not only to help develop but to create the test plans that can be used to gauge if the developed product is likely to meet customer needs.
Automated Test Generation
Almost 30% of the testing task can be the writing of test cases. To first order of approximation, this is a completely manual exercise and a prime candidate for the savings through automation.
Related Posts
- Guidelines for Testing Database Level Application
- SQL Compare – Compare and Synchronize tool for SQL Server Database
- Clear Query Cache in SQL Server
- Visual Studio 2010 Resources
- Visual Studio 2010 Great functionality for Developers
Tags: Basic Best Practices, Best Practises, Foundational Best Practices, Testing Best Practises
Interesting topic this because it touches on best practices which actually cover areas outside of testing. I mean these some of these best practices are critical for the test team but the test team might have little influence over them. For example nightly builds and the automation of the build process is essential for the delivery of consistent high quality builds to the test team. Yet the test team usually have no control over the build process.
Ad hoc builds have always been a particular issue for testers where the ability to identify what has gone in to a build is sometimes vague and where silly mistakes in the build process can creep in (for example missing out a fix from a previous release). Having the whole process, from check in through to package release, automated makes for a reliable approach that the test team can count on. There’s nothing more frustrating than getting a build which won’t even run in the test environment!
Reviews and Inspection is another area which isn’t usually driven by the test team, yet having the test team involved at this stage can reap many benefits. Even if the tester doesn’t understand the code being reviewed, overseeing the review can usually give the tester good ideas for tests and help him/her spot high risk areas of the code (which might then require a higher level of test coverage).
In conclusion I think some of these best practices demonstrate just how dependent testers and test teams are on other people in different teams and how important it is to work effectively with other teams.