« Table of Contents »
Previous « Meeting Milestone 5 — Step Writing
The Behaviour Specification Handbook
The Behaviour Specification Writing Process
Meeting Milestone 6 — Determine Test Types
At this point in the process, the Behaviour Specification Descriptions and steps for a given software component have been written. This final milestone is the most appropriate time to review all the behaviours and decide what type of test each Behaviour Specification should be implemented as, and add an appropriate “@tag” in a line above the description. As you do this, please remember the Testing Pyramid and keep in mind that there should be many more Unit Tests in comparison with Integration Tests.
Some technologies (especially older ones) however, make Unit Testing too difficult or even impossible. When performing this milestone, the team already should have a good understanding of the technology that will be used to implement each software component, and how viable Unit Testing is. If you find yourself in a situation where a component cannot be Unit Tested, then do your best to test at the bottom-most pyramid level as possible.
As a team, review each Behaviour Specification and ask “Can this behaviour be tested as a Unit Test”? The developers typically are in the best position to answer that question, since they best understand the technology and are the ones who would write the automated Unit Tests. I recommended tagging Unit Tests with “@UnitTest” just above the Behaviour Specification Description.
If on the other hand, the test would require the software component to be deployed into a test environment, then it can be classified generally as an Integration Test. I recommend tagging Integration Tests with “@IntegrationTest” just above the Behaviour Specification Description.
The team also needs to decide and agree whether they think there will be enough time to do the automation of each test, or whether the test should be performed manually, at least, for the short-term. Considerations for this can include:
- The Testing Pyramid and the idea of testing at the most appropriate level;
- Whether the behaviour can be implemented as a Unit Test versus an Integration Test;
- Resourcing and skill issues;
- Technical complexity — perhaps it might be too expensive or not technically feasible to develop the test automation; and
- The perceived risk and value of a behaviour.
After considering the trade-offs, for any test that is unlikely to be automated within the necessary timeframe, I recommend that in additon to the tags “@UnitTest” and “@IntegrationTest”, also tagging those tests with “@Manual”.