I have more than 13 years of experience in the software industry, during this time I participate in many major projects that produce test documentation (STP/D/R) which included thousands of test scenarios/cases for each major project.
Based on my experience I will tell that testing documentation is a major part in every large project that combined with testing efforts, now when Said, I want to add some facts and personal humor that uncovers the truth about test documentation.
What is the truth that we know as software testers?
- The world is divided into two types of testers, the first type will tell you that they test any software without a preliminary test documentation, the second type will tell you that they cannot. If you belong to the second type, find a new occupation.
- Writing a software test case is a simple matter when you understand how the system works, don’t make it a Ritual.
- When you write a test plan, please make sure that you cover more than just the basic SRS/Spec requirements.
- In any case that you need to explain the obvious steps of a test case, then you failed to write it in the first place.
- If you write a test case with million steps, I guarantee this, No one will execute this test as expected from him.
- Sometimes we spend Hours on Hours to write test documents with the knowing that no one will use them.
- Ask yourself this, do you really perform your tests based on each step that was written in the test design?
- Be truthful to yourself, how many test cases did you marked as “Passed”, without the actual execution..?
- Many test documents, are written when the person who wrote them doesn't know how the system works.
- Be truthful to yourself, do you really know why there is a "case" when you need to write a "Test Case"..?
- There is a simple algorithm for test documents, I it takes 20H to write a simple doc, the review will take 20H*10, the algorithm changed to 20H*100 if the person that wrote it doesn’t know how to explain the idea behind it.
- Some testers as the assumption that they perform a better job when they write a large test case document, based on my experience they wrong! The number of test cases that you write will never indicate about your quality!
- After a few months into a project, no one will know about the original test design that you prepared.
- How many test cases have you written when the answer to "Is it possible to test this..?" was No!
- How many test cases you've been written without a true intention to execute them?
- How many test cases are written based on a meaningful use case/client story?
- Every test plan/design will include a copy/paste data from older documents.
- How many test cases are written without knowing the expected results?
- At least 50% of all test plans are not signed off by the relevant owner.
- Ask yourself this, how many bugs are found based on a specific test case, and how many bugs are found without a dedicated test case…? I promise you that the results are not decisive.
- Many test documents, are written without knowing the user needs.
- A Use case is not a test case, Test scenarios is not a test case.
- There are always two options to write a test case, option 1 write it in a way that will make sense to anyone who read it, Option 2: write it as you want it, what is your preferred way?
- It's a fact, no one love to write thousands of test scenarios.
- Remember that there is a great testing method that called “Exploratory”, embrace it, I promise you that you can save hours over hours in writing test cases.
- In many cases, the person that should approve your test design, will fail to answer the question of "What is the business case behind this software..?"
- I always prefer a simple and self-explained test design, rather than a Hugh and complex document that no one can understand or use.
- Remember to write all the test cases that matters, never reduce your cases because that you think that there isn’t enough time to test them.
- How many times you did, you complained during a project, that you put too much effort to write documents instead of actual testing…?
- Everyone can write a test case with inputs that are match the Spec requirements, your job is to write a test case that can question it.
- You will never have the time to execute all the test cases that you write, if you know your job you should know how to prioritize them.
- No matter how hard you try, there always be a person which will fail to understand the idea behind some of your test scenarios.
- No matter how hard you try, you will always fail to update your test documents during a project that continues more than a monthJ.