Hello! Today is the 6th day of Advent Calendar 2023, and my name is Ween, QA of データ化サービス.
I am grateful for the opportunity to write a blog and share with everyone the best practices that we used in my former company where I am also applying it here in Freee.
What is test cases?
A test case is a set of actions performed on a system to determine if it satisfies software requirements and functions correctly. It also works as a guideline, so the tester will not be lost and will be able to execute everything in order.
Am I ready to write test cases?
Before you can say that you are ready to write a testcases, you need to have the resources and knowledge or the scope of your testcases. You cannot write a testcases without having “source of truth”.
In Digitalization project, the “source of truth” are usually the PRD and FIGMA. PRD stands for (Product Requirements Document), it is a document containing all the requirements for a certain product while FIGMA is a design tool where the designer stores their designs and prototypes. We QAs are attending the PRD/FIGMA review to ask questions and clarify things. This will limit the change of requirements and unforeseen scenarios that will cause the delay of the project.
When the PRD and Figma have been finalized, we will begin writing the testcases. Our team allots at least one week for QAs to prepare the test documents required for testing because, in addition to writing the testcases, we need to have them reviewed by other QAs before transferring them to our testcase repository which is the testrail.
What are the best practices when writing testcases?
FAMILIARITY ON THE FEATURE. QA must have a thorough understanding of the upcoming functionality and be comfortable with it. We need to pinpoint every area that will get affected by the upcoming feature. Attending PRD, reviewing the Figma or design and asking Questions will help the QA to understand the upcoming feature better.
ALWAYS START FROM THE TOP. It's important to always remember to start at the top while writing test cases. By doing this, we can guarantee that every aspect is addressed and prevent the need for repeated validation.
UNDERSTANDABLE BY EVERYONE. It is very important that the written testcases is understandable and can be followed even by a non tech people.
INCLUDE EVERYTHING LISTED IN THE SOURCE OF TRUTH. QA should include all the scenarios listed in the PRD or FIGMA. This is to make sure that everything will get followed and covered during the testing.
THINK OUT OF THE BOX. As I previously stated, it is crucial to cover every situation that is stated in the reference, but it is also critical that QA be able to come up with additional scenarios that are out of the box. We must think of anything that can destroy the system or any possible areas that might get affected when introducing the new feature or improvements.
AVOID TOO MANY VALIDATIONS IN ONE LINE. Creating too many validations in one line will lead to many expected results as well. And in case that one of the validations fails, the whole line will be marked as fail.
DETAILED STEPS. We don’t usually add steps on our testcases but if ever that we will, we need to ensure that even a kid or a non tech people can follow the steps and execute the created testcases.
ALWAYS USE THE WORD “SHOULD” IN THE EXPECTED RESULT. By using should, we are enforcing and confirming that the expected outcomes "SHOULD" be the expected results and nothing else.
PEER REVIEW. Once QA has finished writing testcases, we should ask our other QAs to take a look at it because there may be certain scenarios that we overlooked and it is critical that it is discovered as early as drafting testcases.
There are still a lot more to add but I think these are the most common practices that we should always follow so we can write an effective testcases! The article 「スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動」 written by barus , QA engineer of 決済プロダクト will be published tomorrow. Let's keep good quality~
