Today's blog post was written by Jen Ford, Principal QA at Sonoma Partners.
One of the things that has stuck me over as I work with different QA departments is how different companies name their Test Cycles. Company A conducts ‘Acceptance Testing.’ Company B says they are doing ‘Ad Hoc Testing,’ not Acceptance Testing. Company A’s Acceptance Testing involves coordinating Super Users to test using a minimal test case structure and making sure they’ve covered all of the functionality they expect to be in this software release. Company B’s Ad Hoc Testing involves coordinating Super Users to test using a bullet-pointed list of items to test and make sure they’ve covered all of the functionality they expect to be in this software release.
These are the same thing. Call it Acceptance Testing, call it Ad Hoc Testing; the definitions these two companies apply are the same.
True, there are some testing types that have a clear definition. White Box Testing, for example, is the testing of code paths and deriving test data from what is known about the code. Only a tester that understands how the code was developed will be capable of doing a decent job at White Box Testing. However, White Box Testing also has many different names: Clear Box Testing, Glass Box Testing, Structural Testing, or Logic Driven Testing, to name a few.
The point here is not to get hung up on how the Test Cycles are named. What is important is that when planning your testing, go through the exercise of naming each Test Cycle and defining what type of testing will occur, the roles of the testers, and what test cases will be executed, in each cycle so everyone is on the same page.
For example, testing could be defined this way:
- Unit Testing – testing done by a developer before code is deployed to QA
- Integration Testing – testing done by QA, but only of systems integrating with each other and how data is passed between the two
- System Testing – testing done by QA to make sure the code updates meet the business requirements
- Acceptance Testing – testing done by Super Users and Business Analysts to make sure the code meets the business’ needs.
The ultimate goal with testing is to make sure that we are delivering a high quality product to the customer, and what you name the Test Cycle doesn’t achieve that purpose. Give your Test Cycles a name and definition early on to provide consistency on the project, and then you won’t have to worry about mixed messages on what you are testing.