Somebody in the team wrote a testing document and you want to review it? Here is a method that will allow you to do it in thirty seconds. Well, not quite a full review, but a sort of sanity, checking first to see that we are in the right direction. It also saves time and therefore an important test for itself. Here is a method, simple and free, and in three steps:
1. open three documents:
a. Requirements Document from the Product Manager / Owner.
b. Design development documents.
c. The test documents that we are reviewing.
2. find the keywords in each of the two first documents, what does it mean?
Every section revolves around a major term.
For example a requirement for a text editor:
Save: the save function is designed to preserve the document state as is, so the user will be able to restore it later
Of course, the keyword here is Save. And in any section in the requirement, we can find a keyword.
3. look at the test design document for these words.
When someone writes a test on a particular section, that term should be mentioned. In our case, how can you write about the Save option without mentioning the word Save? And if there is no mention - there is something wrong in the document.
Some points:
1. This method is quite accurate, but there may be some misses, such as spelling mistakes.
2. If we pass this test - we will go through a thorough review of the entire document. The fact that things are mentioned does not mean they are mentioned correctly and comprehensively.
Comments
Post a Comment