Test case writing
When I started my career in Testing, I was given a 40 page RDD (Requirement Definition Document) and was asked to understand it and start writing test cases. Sounds crazy isn’t? Anyways I am not discussing here how to write test cases, rather on the way of writing test case.
Test case writing is not an easy job! It reflects the testing style of a tester. Intent of a test case is to discover more information about the system. So the way we understand test case is : some set of goal oriented steps, accompanied by test data (if any) and the conditions or pre-requisites followed by the expected result.
If we give the same feature to different people for writing test cases, we will see a different pattern. Those patterns differentiates a tester. Almost all will have a mix of Happy/Sad/Bad test case but the proportion will vary from tester to tester. The intent behind writing a test case is to make sure the intended functionality works. Also we have a mix of negative test cases to assure that the system cannot be sabotaged by some unruly users. Most of the times we know what to expect from a given set of steps, but some times while writing test case we figure out data combination or flows which are not captured in Story or RDD. So test case writing is actually a way to question the understanding.
A tester should be good in writing the test cases, should be good in mixing the positive and negative test cases. This is why I feel test case writing should be done in parallel to the development so that the left out scenarios which get discovered while writing test case can be incorporated much before raising bug (for the missing functionality).