Knowledge of Monkey Test (Quality Assurance of System Development)
# What is monkey test?
Don’t worry about the specified requirement, just run the application and check the operation.
In short, try to move it freely.
# background
I did a monkey test for quality assurance in a certain development.
This is my second time to do monkey test.
So I don’t think I’m a good tester by any means, but I’ll write down what I thought about it.
# Tips: move with the intention of breaking
I think developers tend to unconsciously turn a blind eye to weaknesses in their applications. But testers do the opposite. Try to be as mean and unreasonable as possible to find the flaw.
I think it goes without saying that this is the most basic of basics.
# Tip: see from a beginner’s point of view, a user’s point of view
It’s better to act like a user who knows nothing about the system.
After all, the user sees only the application in front of them, not the back of the system.
On the other hand, I think it’s an anti-pattern to see it for system reasons.
Even if you don’t have to think, “This UI looks unfriendly, but it’s probably difficult to make because of the library.”
Even if you think about it, you don’t have to convince yourself to deter you from reporting.
# Tip: Even if you find a bug, don’t look at the code to find out why
You don’t have to look at the code when you find a bug.
Even if you’re a developer and can read the code.
Finding other bugs makes more sense if you have time to read the code.
I’ll leave it up to the developers to figure out the cause.
Of course it depends.
# Tip: Use code reading to find weaknesses
I was involved in code reviews as well as monkey tests, so I had read the code to some extent. Use this experience to find weak spots in your application.
If there is a point where the operation seems suspicious, the monkey test will focus on moving that part.
# Tip: Don’t be shy about stacking tickets
Testing doesn’t work if you think, “I’m too busy with development right now, so I don’t feel comfortable posting bug tickets. Let’s not do that.”
First, find as many bugs as you can find, and then prioritize them from there.
``Know the bug but can’t fix it in time’’ is better than ``no bug at all’’.
This is because as long as you recognize the problem in the project, you can consider future solutions.
Even if the application in question is no longer being updated, the reported bugs will allow the developers to take note of it in further development.
# Tip: test with multiple people
Even if one person thinks that the test has been completed, other bugs and defects may appear when another person sees it.
We need multiple perspectives.
# Tip: be careful with embeds
One fix in development causes another bug.
Try again to operate the peripheral functions that have been corrected.
# Reflection: I want to find bugs early
I thought I had passed the test once, but in fact I didn’t.
I tried another day and started finding another bug.
The longer it is discovered, the slower it will be corrected.
I want to find as many bugs as possible in the first half of the test period.
# Reflection: Test hard-to-test parts properly
We tend to avoid testing parts that are difficult to operate or troublesome to prepare.
Be aware of any tests you’re avoiding. And test it properly.
# thoughts
- During the test, I had feelings such as “Is it really okay to report such trivial points?” and “Am I saying something strange?” However, when in doubt, I decided to devote myself to the application itself.
- No programming, no expertise required, just run the application and make a mistake and it will work. It felt a little strange.
# Chat member recruitment
If you have any questions, concerns, or consultations, please use the LINE open chat.
https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ
https://twitter.com/Yuma Inaura
