Not that you don't know.
Truth About Test Plan Documents
- 98% of test plan documents that are created are not updated, maintained or cared beyond sign off.
- The first 5 pages of a test plan document contains history that doesn't interest even those whose names are mentioned in it.
- Scope of testing section is the most funniest part of the whole document. Some times when testers report serious problems, some people cite it as out of scope. Hey, its still in the product.
- Customers worldwide could have saved millions of dollars if their vendors didn't care about creating test plan documents.
- 4 years into a project, nobody knows about the test plan document.
- No matter how stupid or intelligent the test plan document is, testers still write the test case they want to write.
- As an offshore services company, writing test plan documents are a cool way of billing customers without actually doing testing.
- Every stakeholder feels a false sense of achievement the moment they have a test plan document irrespective of whether they actually have a test plan.
- The cost of reviewing a document that nobody is going to use it is really high.
- Those who think they are not ready to test because the test plan document is not ready aren't testers by any means.
- A simple maintainable test plan document is far superior than a detailed test plan document.
- A mind map is worth a thousand good test plan documents.
- Test Plan Document is a Document, not necessarily a test plan.
- 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.
- Businessmen love test case documentation. Testers hate it. Businessmen hire testers to write documentation. Testers trade their time for money, end up writing documentation for money.
- 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".
Just that, I know.