Wednesday, October 14, 2015

Uncover the truth about Testing documents

Overview

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?

  1. 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.
  2. Writing a software test case is a simple matter when you understand how the system works, don’t make it a Ritual.
  3. When you write a test plan, please make sure that you cover more than just the basic SRS/Spec requirements.
  4. 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.
  5. If you write a test case with million steps, I guarantee this, No one will execute this test as expected from him.
  6. Sometimes we spend Hours on Hours to write test documents with the knowing that no one will use them.
  7. Ask yourself this, do you really perform your tests based on each step that was written in the test design?
  8. Be truthful to yourself, how many test cases did you marked as “Passed”, without the actual execution..?
  9. Many test documents, are written when the person who wrote them doesn't know how the system works.
  10. Be truthful to yourself, do you really know why there is a "case" when you need to write a "Test Case"..?
  11. 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.
  12. 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!  
  13. After a few months into a project, no one will know about the original test design that you prepared.
  14. How many test cases have you written when the answer to "Is it possible to test this..?" was No!
  15. How many test cases you've been written without a true intention to execute them?
  16. How many test cases are written based on a meaningful use case/client story?
  17. Every test plan/design will include a copy/paste data from older documents.
  18. How many test cases are written without knowing the expected results?
  19. At least 50% of all test plans are not signed off by the relevant owner.
  20. 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.
  21. Many test documents, are written without knowing the user needs.
  22. A Use case is not a test case, Test scenarios is not a test case.
  23. 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?
  24. It's a fact, no one love to write thousands of test scenarios.
  25. 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.
  26. 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..?"
  27. I always prefer a simple and self-explained test design, rather than a Hugh and complex document that no one can understand or use.
  28. 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.
  29. How many times you did, you complained during a project, that you put too much effort to write documents instead of actual testing…?
  30. 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.
  31. 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.
  32. No matter how hard you try, there always be a person which will fail to understand the idea behind some of your test scenarios.
  33. No matter how hard you try, you will always fail to update your test documents during a project that continues more than a monthJ.

No comments:

Post a Comment

My Presentations