7 Habits of a Successful Software Tester
As I’ve been in the software testing industry for some time now, I’ve noticed a few habits that will separate an ‘okay’ software testing…
As I’ve been in the software testing industry for some time now, I’ve noticed a few habits that will separate an ‘okay’ software testing from a ‘great’ software tester. These seven habits are the most important, but it’s not an exhaustive list. There are plenty more habits that can make a software tester ‘great.’
Who am I to come up with this list? Well, a little about my background. I come from a military background. I’ve spent five years in the submarine force for the US Navy, and then after college, I started my career as an avionic engineer for H-60 helicopters. I’ve gone on from there and transitioned to website software testing and automation. I’ve worked with numerous automation programming languages, including Java, C#, Python, and JS. I’ve persuaded multiple certifications from ISTQB (ASTQB).
I believe there’s a lot of information that we can learn between the public and private sectors of the industry. Of course, both sectors do things differently, but overall, the concepts are still fundamentally similar.
So, based on my experiences, here are my 7 Habits for a successful software tester.
Focus on the Customer
Regardless of your company, you ‘work’ for the customer as a software tester. A software tester’s primary goal is to provide the best experience for the customer, such as workflows, UI/UX, accessibility, and performance. Many companies have personas to describe their customers, and it’s helpful to think about these personas while planning new work (features and epics) or when thinking about ways to test an application.
Questioning Mindset
While testing applications, we as software testers shouldn’t assume something is right. If something doesn’t look right, dig into it, check if the functionality is correct, ask questions, etc. As I listed above, always ask yourself if the customer would like this. Happy paths are the easiest to test, but when we put on our detective hats and with a questioning attitude, we can develop some creative and out of box testing that the team didn’t think about during planning.
Data-driven
A common problem, especially in automation, is that automation engineers tend to automate and forget. Even though we as testers don’t have to test something manually doesn’t mean we don’t need to monitor it. There are many ways to monitor automation, such as dashboards or reports. Depending on your test run cycle, you’ll need to watch these to see how things fail. Seeing and understanding these issues provides data points for determining reoccurring themes.
For example — I once had a test that would fail roughly every fourth run. After seeing a consistent failure pattern, I diagnosed that the failure happened when we ran the automation on a particular VM that didn’t have the same resources available as the other ones. Knowing that the VM didn’t have the right resources allocated, we were able to resolve the issue.
Software testers also need to understand how users use the application. Data of user interaction can also drive different testing scenarios. For example, knowing the number of users for a particular part of the application can help drive performance testing requirements. Likewise, the percentage of users who use one specific browser can drive different cross-browser initiatives.
Continued Education
Technology is constantly evolving; therefore, software testers need to grow. There are a lot of ways to continue your growth in software testing.
Certifications — Considering software testing isn’t a degree, certifications are a great way to learn foundational skills for testing and then move to more complex skills.
Online Courses — There are many courses online that software testing can take, like Udemy, Skillshare, or Coursera. Test Automation University is a great way to learn new skills if you're looking for a free option.
Teaching is a great way to pass along information you know to others (software testers or developers). The more developers know proper testing techniques, the more they can test their code before it reaches you. Also, even though you may be teaching, there are still opportunities to learn.
Practice — With all these additional ways to learn new skills, it will be a waste of time if testing skills aren’t improved. There are many different ways to practice; set up your framework and automate testing websites, or you could look for projects on GitHub that need testing help. The possibilities are endless on ways to practice.
Documentation
Documentation takes many forms. When it comes to testers, I’m not necessarily referring to a google doc or confluence page; I’m referring to a tester's notes.
Different types of testing documentation:
Accurately describe a bug or defect, and were the steps to reproduce understandable with minimal gaps between each step?
How thorough were the tester’s notes on the Jira card?
Did a tester give enough information to perform a test in TestRail or any other test management software?
Comments in automation code are also documentation.
Documentation isn’t just for your benefit; it’s for the person who comes behind you that may not have been around while the feature, testing, or automation was in progress.
There are a few rules I follow when I document:
Write for the future you, not the present you
Write at a 3rd-grade reading level (don’t assume someone’s reading level — we all have different backgrounds)
Create test steps for each automation test (I like to do this because it allows someone to understand what the automation is doing without having to go into the repository and navigate different functions to determine the scope of testing — I’m looking at brand new testers and product owners)
Steadfastness
There will come a time in a software tester's professional career when testing a feature and deadlines clash. You’ll have your team, product, or management try to push the work quickly and skip testing to meet a deadline. This is where you need to hold your ground, evaluate the risks involved and say we can’t push this along without testing, or if the risk is super low, allow the work to go through but test immediately after that. Software testers are seen as a roadblock when it comes to meeting releases on time, but I challenge each tester to have a retro and bring up ways work can get in the hands of testers in a more timely manner. The question is rarely asked why did a card take so long to develop (waiting for UI/UX designs, not properly scooped… etc.).
Ask Questions!
The best way to learn the application your testing, especially as someone new to a company, is don’t be afraid to ask questions. It’s more detrimental to the team if you don’t ask questions.