Pages

"Some birds aren't meant to be caged, their feathers are just too bright"- Morgan Freeman, Shawshank Redemption. This blog is from one such bird who couldn't be caged by organizations who mandate scripted software testing. Pradeep Soundararajan welcomes you to this blog and wishes you a good time here and even otherwise.

The next time you ask a tester to write a test plan where she knows it is not going to be used or maintained, she is not going to put her heart in it.

Some test plan documents are written in a way that it is obsolete in its first draft itself.

Some reviewers of test plan documents aim for perfection. More funny stuff, they may not even know what the product is supposed to do.

Those who know about opportunity cost are likely to write a better test plan document.

Not that you don't know.

Truth About Test Case Documents

~ 90% of testers haven't bothered to think why there is a "case" in "test case".

For most people on earth, a test case means a test idea that is documented.

The expected results column in test case documents are a copy paste of requirements document / stories. So much money goes into re-writing the requirements document into expected results column.

If you are already laughing at test case documentation, you may roar to a bigger laughter at trace ability matrix.

Most traditional testing services projects have 50% of their project duration spent on writing test cases. The team members in such projects complain unavailability of time to "actually" test the product. No wonder.

Unless the context demands, detailing a test case is a sin.

Detailed steps in test case documentation provided for humans to execute is something I personally consider as an act against humanity.

More than 99% ( yeah, more than 99%) testers I have met have passed a test case (or a bunch of them) without actually executing it. It is so f****** boring.

Test case documents bring more money to countries like India than what Bill Gates must have invested in setting up an office in that country.

Those testers who don't know to test without test case documentation aren't testers.

More than 98% of projects I have consulted in India didn't have testers doing "test design". Here is a way: Take the requirement and write at least two or three tests to "check" if that requirement can be marked a Pass. That is all the design that happens.

Test case documents are actually "Check case" documents.

If there wasn't check case documents, software testing as an industry would have attracted more talent and helped in building more passion for the craft.

Test case pass percentage is a great way to fool stakeholders. People love to be fooled.

I personally can write test case documentation for any buggy product and make it look like a bug free product.

If all test case documents created so far were printed and burnt, we'd have fire for the next one thousand years.

If you rate testers based on how many test cases they write per day, you'd always find people who can meet the number you want them to achieve.

As someone said, "Testing at its best is, sampling". If you start writing and detailing the samples, you will have fewer samples than what you can have and you will never get to know about the product.

If X test cases documentation takes Y hours, the amount of time spent on reviewing it and getting to sign off is 10Y. So, if X goes to 10X, we have 100Y hours of work spent on test case documentation.

Some projects have great test case documents and no time to run them all.

If you do a lot of documentation, you cant ship software, you can definitely ship documents.

If you are hiring people who need detailed test scripts to test software, your hiring has ton of bugs in it.

Those business people who ask testers to write "how long will this test case take to execute" and make estimations of test cycle complete time, should be executed.

It is about Opportunity cost and Opportunity or Cost.

No user has ever bought a product because the product was developed with lots of test case documentation.

99.999999999% of test case documentation I have seen so far doesn't care what the users really want.

If testers read 1000000 words in a test case document the first time they were executing, they only read 10000 the next time and 1000 that next time and 100 for the next. Later, they don't need it.

Some people think test plan document = test case document.

The service most companies sell is test documentation, not testing.

All good testers I have met so far, treat other testers as intelligent as they are and don't punish humans with detailed test scripts.

Test cases don't assure repeatability of testing, at best it assures repeatability of testers getting bored.

Funny that expected result of a test case should ideally be, "Software should go kaboom" BUT it is mostly, "We should see a boat sailing smooth as the day is bright and clear and the waters are not turbulent".

Posts & Comments

Search this blog

Copyrights

Tester Tested! by Pradeep Soundararajan is licensed under Creative Commons. You must owe credits to Pradeep Soundararajan when you copy paste anything from here by mentioning the name and proper linking to the post. You are not allowed to edit any of the post without permission. For permissions, write to pradeep.srajan@gmail.com