Common Areas of Improvement in Test Cases

  1. Necessity (Non-triviality) – a lot of times, a test case isn’t necessary anymore. A broad use case testing may cover a lot of test cases. Delete such “small step” test cases. It will reduce testing, reporting and automation overheads
  2. Necessity (Non-redundancy) –
    1. Careless testers write such tests. “Who cares if there already exists such a test?”
    2. Similar or even identical test steps across test cases
    3. This leads to wrong estimate of efforts and increase test case maintenance work
  3. Clarity of Name –
    1. Government official type tester tend to write such tests – all the information you asked for in as unfriendly way as possible
    2. “Test case #1020234” is NOT a good name
    3. The name must be descriptive of what is being tested or your developer will never review the test
  4. Loop Unrolling –
    1. Programmer type tester tend to write such tests – they will have “if”s and “for”s
    2. “Test the following for the Sun, the Moon and all the stars in the universe”
    3. This is BAD from test effort estimation and fault reporting. A test case failed must report a bug – and block testing
  5. Clarity of Steps –
    1. Poets type testers tend to write such tests – This inverse of “Clarity of Name” – If your words are short and sweet\ You should not test but tweet
    2. “Test the module” – is a real test case step description from a lot of test databases
    3. A lot of time, there are one-liner tests and a lot is left on the imagination of the tester
    4. Such tests create freedom of testing loaded with confusion and inability to reproduce the bug
  6. Clarity of Expected Results –
    1. Dictator type testers tend to write such tests – not telling you why
    2. “Follow all these steps” … and never ask why
    3. A test is a Boolean hypothesis – and under iron heels of the test mandate, peppered with ridicule of the person asking the question “why?”, Boolean nature of the test goes for a toss. Anything can be concluded – and confused as a result
  7. Atomicity of Result –
    1. Religious type testers tend to write such tests – trying to help your this world and next
    2. “Make sure you can download the music file, see cartoons rolling and feel the phone vibrating”
    3. When anything fails, communication about what failed becomes very confusing
  8. Presentation and Readability –
    1. Lawyers and lawmaker type testers tend to write such tests – Writers of such tests consider text as a means of exercising power on lesser mortals
    2. “Then go to the management console and click on the longest possible link. And assure that premium paid gets displayed” instead of …
    3. “Management Console: Click on the longest possible link”; “Expected Result: End user display: Message ‘Premium Paid’ gets displayed”
    4. Such tests are a pain to the tester who reads steps with a hope to
  9. Sufficiency –
    1. This type of tests are written under a manager who insists on getting certain number of tests written
    2. Such tests don’t cover the feature enough – for example, it will advise you to test that a configuration is persistent through failing over from node A to B but will not ask you to modify the configuration again and then failing over from node B to node A
    3. Such test cases are big waste of time and give false confidence in testing
  10. Generality –
    1. Historian type of testers tend to write such tests – they state that roads were built in Rome, and stop their statement there
    2. “Step 5: Load Firefox version 2.0.2” – is this test applicable in any other Firefox?
    3. Such test cases blur the line between a generic test and a specific test. We need specific tests also to test legacy support
  11. Release Information –
    1. History challenged testers tend to write such tests – they assume because a feature is introduced today in this branch, it will magically appear in older branch
    2. “Test this feature” [Notice the absence of information on ‘applicable to releases branched with or after x’]
    3. When multiple parallel releases are to be tested and there is a feature absent in older tests, it skews testing effort estimate AND if an inexperienced manpower is testing it, time is wasted in an FAD bug
  12. Third Party Dependence Information –
    1. Tunneled vision testers tend to write such tests – they never know the feature they are testing is dependent on the environment, like the browser
    2. “Test this feature” [Notice the absence of information on ‘will unleash a nightmare of compatibility if Firefox updates’]
    3. Test Automation team needs this vital information. Tunneled vision tester miss this key part and Automation team makes fatal mistakes in designing supporting libraries
  13. Third Party Specificity Information –
    1. Jailed testers tend to write such tests – they never know the test they carry out is specific to long term assignment of an environment they have been jailed to – like an operating system or a browser
    2. “Test this feature” [Notice the absence of information ‘on Chrome only’]
    3. Apart from skewing test effort estimate and confusing the heck out of Automation design, this type of test cases in hands of inexperienced hands increase FAD bugs
  14. Priority –
    1. Insecure testers forget to mark a bug with appropriate priority and mark everything “smoke test” – or careless testers leave it to the default “medium” priority
    2. Statistically very high percentage of one type of priority
    3. Nothing hurts testing effort estimate more than this – too high a priority and you waste time, too low a priority and you miss bugs
  15. Placement of the Test Case in Test Database –
    1. Right brain, artistic testers tend to misplace their test cases
    2. “I wrote it right under the release x folder. Why should it be under a feature based hierarchy?” – and let me remind you, this isn’t the only way of misplacing a test case
    3. Such misplacement has two problems – it skews test effort estimation AND it increases probability of missing that test case when related regression testing needs to be carried out
  16. Independence from Other Test Cases –
    1. Such testers can tell you a story but can not tell you a joke. They have problem making a clean cut. They sure have trouble understanding why RDBMS insisted on having independent records. Such testers are also fond of brevity at the cost of confusion
    2. “After previous test case, execute the following steps”
    3. Test Cases may change, move or get deleted. Because previous test case has moved or got deleted or even changed, this test case may lose ALL its meaning
  17. Reviewer information –
    1. Testers that miss to mention reviewers are scientifically challenged. They don’t understand tremendous value peer review adds
    2. Typically reviewer information is missing or reviewer name is the same as the writer
    3. Even if the reviewer is a complete moron, questions from a different brain are worth answering
  18. Coverage –
    1. This typically an oversight over long time
    2. A product grows in features and cross-coupling of features goes unnoticed
    3. Missing coverage ends up in having bad quality
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s