3 workplaces you must know about, as a Test Engineer
I have a way to go in regards to experiencing all the workplace types there are, but I generally believe these 3 are the ones that are quite prominent for the test engineers, analysts and automation geeks of the world. It might be that these types are not necessarily unique to testing and I would encourage you to write about your own experiences in that regard.
Below I put down some of my experiences in navigating the jungle gym of testing surrounding the challenges presented by these workplace types.
- The First
Being the first tester in an organisation is a rare and unique opportunity to create your niche as a tester but can also be overwhelming and intimidating depending on the work culture and industry. Below are some of the initial steps to focus on -
- Understanding the business flows in the organisation i.e., what is generating the dollars. This includes anything customer-facing or business operational functions. Note — Don’t try to understand everything in one go, and break it up into categories.
- Based on the key business workflows, write up test cases early on and if possible automate them straight off the bat. (I do believe that being able to automate should be a part of every tester’s skillset in this particular situation. If you don't have the skillset, I do encourage you to develop it as you go through these improvement iterations.)
- Plug these into your CI/CD processes and get them running every day.
- Iterate through these 3 steps on an ongoing basis and you will have taken away the bottleneck and productivity challenges associated with your role.
- Manage your time effectively and avoid running testing for multiple projects at the same time. Say No to protect your time and the quality of your work.
- Experimentation is key. Try new approaches that work for your teams rather than pulling theory from courses or certifications. Make it your own and bring your experience version of ISTQB concepts.
“Success is the sum of small efforts, repeated day in and day out.”
— Robert Collier
- The One & Only
As an extension to the above type, at some point in your career, you will find yourself being the only tester in the team or the company. This is commonplace in startups/smaller workplaces. Here are some things to remember in addition to the above —
- Focus & refocus the team on the concept of shared responsibility for quality. As the sole tester, you will become a roadblock for delivery if the team does not internalise this and turn you into a one-man army. Trust me there are no benefits in going John Rambo in testing.
- While taking an automation-first approach, mix it up with risk-based testing practices. This will allow you to increase the velocity of delivery while ensuring the key revenue streams/technology ecosystems are protected.
- Keep documentation as light as possible — Think lean templates and processes. A 20-page test plan is a big no-no if you value your time.
- Plan your calendar availability well. — Prebook heads down and think time and decline meetings without a clear agenda. (This is just prudent advice that I have been given everywhere.)
- As time goes on work on business cases to expand the team. Smaller companies will not invest much in testing in their early years, but with growth comes an opportunity to scale and it is key to keep a close eye on the team or the company’s pulse.
“Knowing trees, I understand the meaning of patience.
Knowing grass, I can appreciate persistence.”
― Hal Borland
3. The Goliath
These are the large enterprises and the corporate giants with multimillion-dollar budgets to run testing across the organisation. Multiple teams, standardised processes and tooling, the works. This can be a challenge for the testers who are autonomous and come from smaller works places where experimentation and adaptability are easier.
- Understand that in larger organisations, the tight and bureaucratic process replaces the void left by the fabric of trust that comes from leaner organisations. As an organisation grows, testing processes will tend to become heavier and prescriptive which is OK. Process adoption can be slow if there is a lack of experience in modern testing practices. Although there are exceptions to this, the industry you work in will largely influence how you test and deliver. This tends to be true in safety and regulatory environments.
- Respect and get familiar with the existing practices before making a case to challenge them. All challenges must be supported with metrics to help steer process improvement initiatives. A process might feel medieval in its inherent nature but might be responsible for creating considerable efficiencies in other areas of the business. Recognising what needs shifting and what doesn't take a bit of experience but it is not hard.
- Use the opportunity to leverage budgets to influence tooling choices and learn these platforms as they will add to your skill set. Assess tool upgrades to look at ongoing improvements and their impacts on established processes. Just because a tool was introduced 10 years ago, does not eliminate the possibility of bringing in a more modern one, if the cost and disruptions are justified.
Your main challenge will be to keep the simple things simple and prevent the complex from getting complicated.
”The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency.
The second is that automation applied to an inefficient operation will magnify the inefficiency”.
– Bill Gates
Now, that was a quick rundown of the workplaces I have experienced and my takeaways from them. I do believe a lot of these are generally transferrable to other professions in technology and if you have similar experiences I would love to hear them.
Thank you for reading.
Happy days!
Useful links
I’d like to acknowledge the Traditional Owners of the land on which I live and work. For me, it is the Wurundjeri Willum people and I pay my respects to their Elders past and present.
I am a Melbourne-based Engineering Manager with a specialisation in Quality and Platforms Engineering. I am a volunteer Firefighter with CFA and dog father to a 3-year-old Cavapoo.
