Four Lessons I Learned As A Solo Tester
By Eduardo Fischer
So, you just started your new job at a growing company and you are the first tester they’ve hired. You are, for the moment, solely responsible for paving the path of quality for this business, and even though you’re new, it seems like everyone is already counting on you to do the work just right. I’ve been in this position not once but twice and it is a lot of responsibility, but it is also really rewarding.
I would like to share some tips to follow and traps to avoid that I learned from experience. They will be especially useful if you are creating testing processes and workflow. Even if you aren’t required to do that, this guidance might just help you become a better tester.
Don’t Isolate Yourself: Communicate Often
I am mostly a shy guy and used to work as a developer. So my first mistake when I started implementing processes as a test engineer was that I didn’t communicate enough. As a developer I focused mostly on getting my tasks and features done and for that reason concentrated on coding. Communication is essential to understanding the features you are tasked with developing, but I feared that if I faced constant interruptions it could really decrease my productivity.
As a tester, I no longer have the option of isolating myself at my desk and focusing solely on the tasks assigned to me without discussing those tasks with project managers, developers, designers, and all others involved in the project. Developers will often skip testing to make tight deadlines (ironically, skipping testing will cost them time later when bugs turn up), while designers might overlook things like accessibility for those with color-blindness. Even though everyone is on tight deadlines and small budgets, I still have to report bugs, ask why some issue was marked as closed when I’ve noticed a recurrence, interrogate questionable business decisions, and more.
So you will need to learn how to communicate with everyone on the team... and everyone will have a different preferred method of communicating. Some developers might like chat messages over Slack as to not interrupt their “flow,” while others may prefer a quick conversation next to the coffee machine. But everyone is different and to communicate with efficiency you will have to adjust accordingly.
Don’t Be A Lifeguard: Make Everyone Use A Lifejacket
On my first job as a tester, I initially thought that testing and assuring quality was solely the responsibility of the QA team. I could not have been more wrong. Whenever a new feature or prototype was ready for testing, I would report bugs and then keep up with the project to see if they were fixed. But I didn’t take the more critical step of suggesting improvements in the development process so that fewer bugs would be generated. Helping the developers with tools and heuristics for testing was perhaps the most effective route I found to ensure quality and more thoroughly tested features.
When we think of ourselves as lifeguards of quality, it might give us a little bit of pride and sense of importance. But when we share the responsibility of testing with developers, project managers, and other members of the team, quality rises to a level beyond what we could do on our own.
Use Automated Testing... Wisely
I helped create this type of technical debt in one of my jobs as a solo tester. A certain project was of critical importance, but it didn’t have any unit tests at the time. As a temporary solution, I tested the business logic via an API. At first it was an adequate solution. The project was too complex to test manually with any level of completeness, and since there were no unit tests, the API testing added a minimal but necessary safety net for the project.
As a beginner in test engineering, I was happy with the result. It made me feel important to be the lifeguard of such an important feature. But relying on only one method of testing cost us dearly later. Since the API testing turned up critical bugs without much maintenance (at least not at first), adding unit tests was not considered priority. I share some blame for this result: my temporary solution became the standard solution and I didn’t push enough for those unit tests to be written. As explained in my second tip, I was a lifeguard and didn’t attempt to make the developers use their lifejackets. To be fair to myself, however, development management or tech leads might also have pushed for unit tests or more thorough integration testing.
As a result, every time that a feature grew in size and complexity, so did my API tests, and it didn’t take long for test execution and refactoring to become complex and time-demanding. After a while, though, I had reinforcements: an experienced QA lead joined our team and with his advocacy the team decided to leave business logic to unit tests and unit tests only, and to abandon the approach of using API testing as the sole method. It didn’t solve all problems in one day, but at least our technical debt stopped growing.
Automation testing can add a safety net, especially for projects that cannot be tested manually with rigor. But take your time and create a really good automation strategy with your team’s input and approval.
You Can’t Test Everything: Make The Best Use Of Your Time
Having to work on one, two or three different projects at the same time is not unusual for a tester. You can wind up with three different deadlines and three different priorities to the business. So it is not uncommon to wonder what's best: Focus on a high impact project with a far-off deadline or a low-impact project with a looming deadline? Sometimes there is no easy answer.
So my tip is to verify, on a weekly basis, which project is the most important. When in doubt, focus on that project. Few things are worse for a tester than to spend hours and hours on a low impact project, only for it to be delayed, changed, or cancelled while the most important project has its deadline moved up.
Time is your most important resource. Since you can never verify that a feature is bug free, don’t bother with testing it ad infinitum. There is never enough time to test everything, so be efficient with your time. Test what’s important, the most common paths, critical paths, happy paths, but be efficient with your time. Techniques like boundary testing and equivalence partitioning can help you reduce the number of test cases and still keep the software to the same standard of quality. Being a good tester is not only about what to test but what not to test.
Amber Pollack-Berti, Are we there yet? Driving quality & tackling automation debt
John Ferguson Smart, A Test Pyramid Heresy: a fresh look at test automation strategies
Eduardo Fischer is a quality assurance engineer who focuses on API and UI test automation with occasional forays into load and mutation testing. He discovered his passion for testing during his time as a backend developer and eventually made testing his fulltime job. His hobbies are developing Alexa skills and making models for his 3D printer. You can find him on LinkedIn: https://www.linkedin.com/mwlite/in/eduardo-fischer-dos-santos