Happy Anniversary! Testing at Etain One Year In
October 2, 2019

I’ve been at Etain for a year now, so I thought I’d write a post with some of my observations on software testing here, how I’ve settled in, how it compares to other roles I’ve had and where I think we’re going.
 
Disclaimer: No one asked me to do this. I haven’t been asked to propagandize or sell anything. I’m just going to share my thoughts and reflections.
 
Spoiler: There are no dark revelations and no Snowden-style whistles to blow!

R.E.S.P.E.C.T - You Know What QA Means to Me


I’ve been a tester since 2013 (Jeez, that’s scary to type!) and have friends in testing at many, many companies around Belfast and beyond. If there’s one thing I have come to realise it’s that testing is different at every company.
 
I have a friend at one company whose main job is running automated test scripts and raising bug reports based on the outcomes. Another friend of mine was their company’s first ever tester and built their testing strategy, processes and selected their test tools from scratch. I’ve seen companies that believe testing is at the heart of pleasing their clients and some which see it as a contractual obligation and even some which see it as optional!
 
In this industry, clients often think they can save money by shaving testing time. As a tester this is kind of offensive (it’s basically saying our job is unnecessary) and annoying because it never actually works.
 
There IS a minimum basic quality beneath which no company would ever release a product, sure. If a software solution which is released from development falls beneath this quality, it will be rejected by the product owner and project manager because everyone has a QA radar, just not one as finely tuned as a tester’s.
 
Everyone can review a movie, but film critics have a broader, deeper wealth of experience to base their criticism on, so their opinion is more valued. Software is the same, everyone has an opinion, but testers are experts at software criticism.
 
So you can shave testing time, and avoid buying ‘The Room’ of software. Congratulations. That doesn’t mean what you end up with is good, it just means it’s not awful. When this average product gets to the client, they won’t be pleased because they don’t want ‘just fine’ they want Oscar-worthy. So whatever time and money they saved by shaving time off FAT testing they will end up paying for by extending UAT.
 
Thankfully, I can say that Etain sees testing as an integral part of delivering a good product.
 
I have yet to see a project that doesn’t have testing included as part of delivery and we are always keen to stress the importance of testing to clients.
 
One way in which I can see this in action is the importance of test estimates. Shortly after I started our Test Manager, gave a presentation on how to estimate the test effort required for a project. Why? Because testers are required to provide this to Project Managers and sales in order to accurately sell and plan their projects. This impressed me for two reasons.
 
First, I have never been asked to estimate how much testing would be required for a project before coming to Etain, so the idea that my input would be wanted made me feel like my professional opinion was respected.
 
Second, I had no idea HOW to estimate test effort (and I’m still learning!) so I was glad to be given the training.
 
I can say that at Etain testing as a profession is respected and that I, as an individual tester with professional experience, feel respected.

Dōmo arigatō, Tester Roboto

Like many other software companies in Belfast, Etain has an ongoing process of onboarding test automation.
 
When I joined a year ago, a collaboration between a senior member of the development team and our senior tester, to bring in testing using Selenium with NUnit on one of our biggest projects was underway. This was successful, and we created a functioning test suite for that project.  It was intended to be the beginning of an ongoing process whereby the development team would create a library of components during development and the testers would then create test suites alongside development using these components.
 
Unfortunately, this process slowed down due to losing that driving member of the development team. The software testers continued to train up using selenium and C# to write test cases, but no model of test automation was implemented company-wide without development support.
 
Thankfully, this was a temporary slowdown. Due to a commitment to implement a DevOps methodology company-wide there is new impetus for bringing in Continuous Integration and Continuous Delivery and this will require an expansion of test automation.
 
Recently, one of Etain’s Technical Architects led a knowledge sharing session on Selenium and writing unit tests which was heavily attended by the test team and I don’t see these sorts of initiatives slowing down.
 
Therefore, although in its early stages, the intention at Etain is to rapidly build up its test automation capacity and I look forward to adapting to this new environment.
 
In fact, I have reason to believe that in the future the role of testers at Etain will become even more important.  As part of the transition to a more DevOps focused methodology, and the expansion of test automation as part of creating CICD processes, testers will increasingly need to be quality tsars required to know the client’s requirements as well as the BAs and enforce quality processes at each stage of the software development life-cycle to meet them.
 
As automation replaces a greater share of the work testers now do manually, testers will be free to be more reactive and more experimental.
 

Bob Beck

Bob Beck

Quality Assurance Engineer
Jurassic Park Enthusiast

Return to blog

We're Hiring

Interested and want to know more?Send us an email