3 Considerations For Beginner Testers
Breakdown traditional QA silos and empower developers to own quality checks.
Tech is exploding, and it has been for some time with no clear indication of it slowing down. The demand for skilled people to join software development teams outpace those pursuing the industry. It’s also normal that the number of developers per team outnumbers the QA’s. That level of imbalance means that testers new to the space generally seek guidance and help from others testers, usually outside of their company.
Inexperienced QA’s joining a company as the first tester can sometimes leave them scratching their heads as to what they should do. Experienced QA’s already have that knowledge so, that transition as the first isn’t as daunting.
The internet opens us to an endless sea of information with no clear start or finish. I’ve compiled 3-considerations that beginner testers should keep in mind when starting as a QA engineer.
#1 Automation Is A Technical Tool
1.1
Automation is a hot topic, and I haven’t met a team that feels like they don’t need it, everyone wants automation. Automation eliminates the need to perform repetitive tasks manually. It’s consistent, so we know it’ll always follow the path we’ve defined. Let’s not forget speed, it’s undoubtedly fast and will click through and navigate a webpage faster than any human ever could (when it works).
1.2
Most beginner QA’s don’t have a coding background which can lead to badly written automation scripts. Left unchecked, those poorly written scripts may provide a false sense of stability. Automation is code, and the coding experts are the developers. If you’re new to writing automation scripts and have little or zero coding experience, I highly recommend you seek help and guidance from the devs.
Remember you operate as a team, and coding is a skill that the developers utilise everyday, so don’t be afraid to ask for help.
Going ‘Han Solo’ on the automation (even if you’re experienced) will eventually lead to an information gap, and when you’re away, the team needs to be able to understand any errors that may occur. So I would suggest getting the development team involved as early as possible.
#2 Dare To Be Different
2.1
I’m not about to start a motivational speech but you’re there for a reason. The team felt a need for you to be there to help them progress, and you proved your worth. Like any new team member, you bring a fresh perspective to the table. Capitalise on that right from the beginning. Share your ideas and be willing to ask those obvious questions if they’ll help with your development.
2.2
You may recall the mission statement at the beginning of the article: “Break down traditional QA silos and empower developers to own quality checks”. When I talk about traditional, I refer to the common method most teams have accustomed themselves to where they tend to funnel all of the testing through the QA. That rush you get from testing everything is exciting and a great way to learn, but figure out a way to integrate the involvement of the entire development team during the testing phases. For example, you want to avoid the “Ready for testing” dilemma that traditional practices can introduce. Build your testing knowledge and share that knowledge back with them.
2.3
It’s common that a new tester with no experienced guidance may turn towards the development team to ask, what they think you should do. Instead, do your research and bring that knowledge to them. Gather their input and combine it with your research so that you define your path and not vice versa. Help the team understand your intentions on where you plan to drive the improvements around testing.
2.4
The path to becoming a QA engineer isn’t as well defined compared to most frontend or backend developer roles. The tester’s role is a unique one, where it’s a mix of both technical and business understanding. You’ll help shape and define the testing standards within your team and grow along the way.
#3 Ask Questions To Avoid Making Assumptions
3.1
Your contribution to the team is an important one. When starting out you may eventually have to test something that isn’t clear. For example if you taken the time to read the details and review the designs, and you’re still not 100% that may lead to you making assumptions. You might assume that your lack of confidence is due to a lack of knowledge for the product you’re working with. A mistake like this could become prevalent at a later stage in time.
Avoid making this mistake early on and ask the questions that create uncertainty in your mind. Making that a habit from the beginning will help you down the line.
3.2
As a tester your knowledge of the product is valuable, but testing something means little when you don’t understand what it is you’re testing. For example, a developer might tell you that in order to test a feature, you simply run a request against some server and expect a 401 response. The problem with that example could mean the following: are there more scenarios you and the developer missed concerning testing? Where does that leave your confidence?
Asking questions will help you understand and can reveal problems overlooked before development.
Concluding
Testing is a fun and rewarding space to work. If I could sum up the 3 points above into a few snatch takeaways, it would be that you should be conscious of what you automate, it’s a tool to help you but automation alone isn’t a saving grace. Secondly, software testing has evolved and traditional testing practices are outdated, embrace that change to be ahead of the game. Lastly, ask questions to build your testing knowledge and confidence. Doing so will eventually enable you to teach those learnings back to the development team and raise the shared testing knowledge. Good Luck!
Become an active Medium member for unlimited access, register HERE! 👏🏽
