The testing phase of product development ensures that the product operates as expected. This phase begins after the implementation of the product requirements. Depending on the development methodology used, the testing will occur at different times during the project:
During the testing phase, testing groups will employ a number of methods to ensure that the product operates as expected. Your methods for testing might vary depending on the type of product you are building but the concepts remain very similar.
Developers often conduct“unit tests” prior to the formal testing stage, which actually makes them part of the first phase of testing. During unit testing, the developer runs the new requirement, which is expected to complete its discrete task.
Example:
When building an address import system, unit testing involves pressing the import button, bringing the addresses into the system. This method does not focus on any impact to other features; it ensures that that particular function operates as expected.
Testers can use personas and product requirements to create their own“test cases,” which concentrate on a requirement’s outcomes. Test cases probe each way a user may interact with a feature.
The goal is to find all possible situations that the developer might not have considered. The process of creating test cases often identifies gaps in requirements, and changes that might be necessitated.
While test cases are primarily used in the development of hardware and software, they can be used across any type of product. The key is to understand what the consumer of the product might do with it, and how the product will respond. For example, test cases could be employed with the following product scenarios:
Sample test case: Software scenario
User | Product |
User hits the“import addresses” button, and uploads a CSV file. | System creates addresses and presents them on screen. |
User hits the“import addresses” button, and forgets to upload a CSV file. | System reminds the user to upload the file. |
User hits the“import addresses” button, and uploads a non-CSV file. | System tells the user it cannot process the file, and to upload CSV only. |
After your development team creates the test cases, test them in the most common environment and see what issues may arise. To complete testing, you will want to test in every type of environment where your product is used.
Note that “environments” comprise any variable that can change your product’s effectiveness, and that that the definition will vary depending on what type of product you are creating:
When adding new features, it is important to also test old features. Although existing features have not explicitly changed, new features can have an unintentional impact on older features. By using test cases from past releases, testers can ensure that the entire product operates as expected.
As your product matures and grows, the next step is automated testing. This type of testing can help with executing regression tests each time a developer creates new functionality, to ensure that they did not break old functionality. Automated testing saves a lot of time, but requires dedication to update it with each newly added test case.
Note: Another type of testing not covered here is usability testing. This involves showing your design to potential users to see how they would interact with your product.
To take best advantage of usability feedback, conduct such testing early on when you validate your requirements—not when you’ve reached the phase of final testing.
“How to write effective test cases, procedures and definitions.” (2010). Software Testing Help. Retrieved August 13, 2010, from http://www.softwaretestinghelp.com/how-to-write-effective-test-cases-test-cases-procedures-and-definitions/
Huizinga, D. & Kolawa, A. (2007, August). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press.
Kolawa, A. (n.d.). “Regression testing.” Wrox Programmer to Programmer. Retrieved October 4, 2010, from http://www.wrox.com/WileyCDA/Section/id-291252.html