We all know test is big part of our life, from our gym(physical strength) to our life(mental strength)we are all testing, pushing limits for both ourself and indispensable softwares from smartwatches to siri.
But how to be a good tester especially for our job? I will try to touch the brittle points of testing with this article.
1- End-user Perspective
As i said, we are all testers here and there. But to do manual or automation testing, there is a trigger point.
How end-user will think and interact?
I know there are types of negative testing like adhoc to simulate this kind of behaviours, but its heavy word to say testing is just negative testing. If we are going to do negative testing all the time, then JMeter doesnt need think time. But we are thinking right? Before clicking purchase or delete button. Or we are not angry or tired all the time.
Thats being said, we should think for different kind of purposes, consumers in rush, calm or aged. Or intended breakers like me. Our application should serve all of them. Of course there will be target clients like im using Vercel easily because i have experience with hosting and im dark-mode addict.
TL&DR; Think out of the box while doing especially manual testing. Combine your instinct and experience.
2- Strong Coding Knowledge
Must for automation, not for manual, but i think there is a sweet-spot there. If we did white-box testing or worked with devs before, we will know where to hit in manual too.
So i wont say coding knowledge is not necessary for manual testing. But why its so important?
Probably all of us have experience with OOP, what it means and how strong is it. Not just devs need it. OOP will save us a lot of time and help with maintainability, i remember i was too lazy to write .click() for buttons and wrote a utility method for just clicking. Of course then improved it for Actions class or JS Executor but you got the idea behind it. 1 secs will add up to minutes and minutes add up to hours. You know the rest.
And we are all temporary,(mortal bodies)even companies is not eternal. We will be replaced by someone. I love to be remembered as tidy person. There is a saying in our country:
You should like your work first.
I love writing clean, robust and scalable code. And whatever language you use, use language with its all power and libraries.(Like Lombok/Serenity BDD for Java)
3- Debug Skills
Again, you are free to complain we are not devs. But hear me out, as bug makers, if we cant properly deal with defects, we cannot find any bug.
Maybe it means devs are not making mistakes, not really. They are there.
Most of the companies doesnt even write Unit/Integration Test. Maybe you can participate in that area, but we are humans, even AI cannot write perfect code for now. We have a mental health and as a multi-task person i can assure you there will be missing points when function finishes. Deadlines, personal or family issues, environmental blockers. I'm not Laplaces Devil to calculate all the possibilites what is causing bugs one by one. And we dont need to.
Let me tighten my topic with this. A.K.A. Nightmare: Flaky Test.
Docker solved the problem its working in my machine, but how about flaky tests? Why we cannot 100% solve them?
Decreasing flaky test count should be our goal. Not removing it. As a manual tester in worlds biggest hosting company, a lot of functions adding and going-on. Even with integration test, some areas may not be covered and UI will change eventually. Then ElementNotFound, StaleElement, TimeOut will come to the stage.
I know tests wear-out. But even if we update all of them, still UI is one of the most interchangeable part of the application. Without having proper debug skills to see where we are doing wrong, why our code exploded and how can we prevent that in the future with combining strong coding knowledge, its too hard to reduce flaky test.
Thats why testers evaluating/prefs TypeScript nowadays, one word: Static Typing. We are debugging ourselves while writing our code and we will find our mistakes while writing, not in Runtime.
Couple of tips about reducing Flaky Test:
Always assume the DOM is dynamic.
Don’t rely on fixed delays like Thread.Sleep
Prefer By Locators Over WebElement References
WebElement references go stale on DOM updates, By locators re-fetch elements on demand.
Race Condition Handle with attempts
Retry the operation if it fails due to timing issues.
Please feel free to criticize me, thank you for reading!
