Hello everyone, I 'm Pontsuyo, a soccer lover ! I was originally on the development team, but I was recently transferred to the testing team and have been spending my days completing tests.
Meanwhile, during a meeting
Captain HAPPY: "Pontsuyo, do you want to try test design?" Pontsuyo: "I'd love to do that! (I'm looking forward to it! I wonder what it'll involve!)" I readily agreed, and this article begins with that.
The fact that I accepted the job without knowing what test design was or what kind of work it was was the beginning of the hellish and turbulent days that followed.
So, to avoid going through hell like Pontsuyo , I'm going to write this advice article for people like Pontsuyo who have some development experience but are new to test design !!!
P.S. I feel refreshed after having overcome the mental barriers of hell! I definitely couldn't have overcome it alone, so I'm really grateful to the three captains for supporting me!
Steps to complete the test
Below is the flow I went through this time! I will list my experiences following this flow and some advice for my fellow players!
Hearing
This is the phase where we hold interviews with the PM to organize the test requirements.
Advice to fellow tribesmen
- Be careful not to miss anything important
During the meeting with the PM, important words were being thrown around in the conversation, but I thought we were just discussing something and almost missed it. However, because I had heard it was Captain Ponjuice, I was able to notice it when I checked again, take notes, and incorporate it into the design. It's important for everyone to remember that they are currently thinking about requirements!!
- I can visualize it
I was able to visualize what I was talking about based on my development experience as program code, such as "I wonder if this code would be used for that requirement." I think my development experience was very useful in the interview process because I was able to visualize it!
Test Design
Test design is the phase where the information that came up during the interviews is confirmed, implemented, and compared with the specifications.
Advice for fellow tribesmen
- Prevent deterioration of confirmation
I had included points in the case that did not need to be checked. Because I was passively checking, points that were not mentioned were missed. Through this case, I realized that it is important to go and find information yourself, like a reporter! If you are passive, you will lose!
How to tell people
Quality deteriorates like a "game of telephone," so it's important to make sure that what was communicated is communicated without any discrepancies. There were cases where this confirmation was neglected or overlooked, so as I mentioned earlier about the deterioration of confirmation, if you are passive, you will lose!!!
If you don't understand, ask and rely on others
When it came time to do the test design, Pontsuyo, who had only ever seen test cases, was nervous. What made him nervous?
I had no idea what to do with the test design. In the end, I was able to complete it with the help of Captain HAPPY and Captain Ponjuice. Captain Ponjuice gave me a lot of advice during the test design.
Rely, listen, and say thank you!!!
- I was able to read and understand the DB design document.
Since I had studied databases during development, I was able to translate the database design documents into test designs.
Test case creation
After the test design and review were completed, we created a case for testing. At this point, we finally came to a case that we had seen in testing. I
would like to introduce some of the difficulties we faced and the benefits of testing instead of development.
Advice for fellow tribesmen
- Write in words that anyone can understand!
In this case, I used a phrase that only I could understand, so someone pointed out to me, "What language is this?"... The endings were all over the place and there was no sense of cohesion, so the quality was poor... Don't forget that someone other than you will be conducting the test!!!
- The value of test design documents
Even after reviewing the specifications, there were several points where I didn't understand what the expected values were. Since I started from the test design document, I often had to review the test design document.
I can't understand it even if I look at the specifications, so I write the test design document at the hearing stage!!! Test design documents are the best!!!
- Please ask for third-party verification!
In this phase, I received cooperation from the three captains. Captain Happy taught me the flow, Captain Ponjuice pointed out omissions, and Captain Red Hair gave me detailed feedback, which helped me complete the project. If I had done it on my own, it would have been a test case that only I could understand, but with the help of the three captains, it became a test case that anyone can understand. It's
impossible to create a perfect test case the first time!!! Let's ask for a review!
What we were able to make use of during testing
- I was able to imagine the possible things that were not allowed
Because I have worked on similar projects before, I was able to incorporate anticipated NG cases in advance! I was able to create test cases this time taking into account boundary values and uneven distribution of defects!
Test digestion
Advice for fellow tribesmen
3 With the help of the captain, I was able to create a high-quality test case, but looking at it from the perspective of what it would have been like if it had been my case before the correction, I got some suggestions that I'd like to share!
・It may be obvious, but don't use phrases that only you can understand! ・Easy-to-read test cases are also easy for others to test, including yourself ・When conducting testing, don't forget that it is the last bastion before delivery
In other words, the best way to improve quality is to create something that everyone can agree on, rather than creating something that others will see and interpret differently!
Summary
This was my first time implementing test design, and I'll write a summary of what I noticed from two perspectives: the differences in testing from the perspective of a test executor and a test designer!!
From the perspective of the tester
- Don't underestimate test design
Since I had only digested the information, I thought I would just create a case.
However, when I tried to create a test case based on the information given to me by the PM, I realized that in order to create a case, you need to understand the system specifications , have development knowledge , and have wording skills to create a case that anyone can understand. In fact, a test case is made up of a number of things!
Creating test cases really broadens your perspective!
From the perspective of a test designer who actually went there
The test case is yourself
I thought that test cases were created for the purpose of testing and improving system quality, but I realized that when creating a test case, you don't know what it can and can't do! This suggested that test cases are created to understand the current state of the system!
From this suggestion, I strongly felt that creating test cases is similar to analyzing yourself! Creating test cases allows you to analyze yourself deeply!
Finally
By being involved in the test design, I think I was able to learn what I had thought about tests and what tests should be like. I learned the importance of confirmation and how scary it is to be passive. There were many points of criticism in this project, and I had many failures and thoughts, but I think that the fact that I was able to see it through will be a great asset, as well as something to reflect on. I would like to follow the example of the three captains, who supported me when I was still inexperienced, and use this to help me grow in the future.