We sit down with Ken Talbot, an experienced Test Lead who gives back to the Testing community. Ken has been in Testing for around 10 years, so he discusses tips to get into Testing, the challenges you may face and how to embrace shift left. Let’s delve in to find out some of Ken’s top tips…
Hey Ken, can you please introduce yourself and give us a brief overview of your current role…
Hey! I’m a test lead at MoneySupermaket Group. I sit across the Insurance and Money comparison teams, but my role allows me the freedom to do a lot more, like recruitment and having an active involvement in the tech community!
I can see from your LinkedIn, you have been in testing for around 10 years now working in multiple large businesses. From your experience what are some common types of testing that newcomers should be familiar with?
First and foremost, simply approaching applications with a curious and critical eye is the best technique to have. Open up the dev console and have a look at what’s happening, download browser extensions like bug magnet and try things out. Play around with the basic functions of apps on your phone. You’ll be surprised (and shocked) at what you’ll find. Another essential area of testing that newcomers should get experience with is accessibility. This is one of the only elements of software that can exclude entire demographics from using applications. It also has government legislation to make sure it’s done right, so you can wield this knowledge with authority.
What are the key challenges that newcomers might face when starting with software testing?
For me, the perceived technical level is the largest issue. Exclusionary recruitment language and some organisations’ poor understanding of the test role mean that new testers may become daunted by their own skillset. I have known people transition into a promising test career, only to become overwhelmed by what they feel is expected of them. The truth is, you don’t need to be technical to be a good tester. As long as you’re willing to learn and communicate with your team, you can become a great tester without writing a single line of code.
What are some common test automation anti-patterns that teams should be aware of?
Here’s a fun collection of anti-patterns I have personally come up against. There are many more that others have had to endure and yet more out there to research:
- Trying to automate every aspect of testing
- Focussing all your automation strategy in the UI
- Aiming for 100% coverage regardless of ‘what’ is being tested
- Relying on post-development auditing tools to tell you the state of non functional requirements
- Using automation to tell you that your app is working in production
- Implementing a BDD framework like Cucumber without knowing why it’s valuable
- Test automation is just for testers
- Poorly designed, poorly planned or non-existent unit testing
Can you provide examples of fragile test automation practices and their negative consequences?
Pushing all your automation into the UI is something that I’ve been trying to combat in recent years. UI automation is often the first technical tool a tester adds to their skillset and it’s usually the only form of automation actively avoided by software engineers within a team. As such, teams place a lot of emphasis on complex UI suites that are designed, written and maintained by testers. Because these suites can be complex and time consuming, other layers of testing are neglected or ignored entirely. The end result is a lot of delivery confidence riding on the very end of the process. If bugs are caught by these tests, they are caught far too late. Additionally, the constant maintenance this automation requires is an anchor around the neck of the tester and the team as a whole.
What is the impact of not maintaining test automation scripts over time, and why is it considered an anti-pattern?
Well, I’d argue that if you’re not maintaining your tests and they are still passing, that in itself is a problem. Applications naturally change and iterate over time. As you make changes, the underlying tests change as well. No automation is truly resilient to change, nor should it be. The automation task should run parallel to the dev task in a constant cycle of iteration.
What is the concept of “Shift Left” testing in software development?
Shift left as a core concept involves spreading a previously bottlenecked discipline across the SDLC to increase awareness and applied knowledge as early as is valuable. This is usually attributed to testing and is often incorrectly linked to early automation. My take on shift left is all about the tester themselves. Having a presence in discussions, asking the right questions and being exposed to the dev work as early as hypothesis. We want to spread knowledge of testing throughout the team and throughout the dev cycle, but first we need to actually be part of that cycle.
Can you provide examples of how defects found earlier in the development process can save time and resources?
First of all, you are not going to find every defect all the time, no matter how much automation or how much exploratory testing you do. That said, when defects get as far as production, you are presenting your users with unexpected functionality, which can be unpleasant and damaging to both user and application owner. I have personally seen fundamental business logic make it as far as the release stage in a broken state. This grinds everything to a halt depending on the size and priority of the work. If something that does not have an easy solution is found late in the process, the time and effort to restart that work ripples through the whole team. If you’re a tester, you need to rethink your whole strategy. If you’re a dev, you need to switch context back to that work that you thought was complete. It can be demoralising and incur time and value cost for your organisation.
What are the potential challenges or barriers teams might face when adopting Shift Left testing, and how can they overcome them?
Resistance to change. A lot of organisations are used to working in a certain way, software engineers in particular are comfortable with existing processes. A gradual, planned approach is needed to ease everyone in. As a tester, manage your social and critical distance and put yourself forward as a subject matter expert and a supportive persona. Ask how your skills can be used at each stage and teach developers how to use your tools. Shift left is a buzz phrase and you can’t just do it, it’s a mindset.
Any advice for someone moving into a Testing Career?
Even though you don’t have to be, prepare to be afraid. Afraid that you aren’t good enough. Afraid that everyone is smarter than you. Afraid that you cannot possibly learn enough to be competent as a tester. Anyone can be a tester, most of us already are and just don’t know it. Some of the best testers I’ve ever hired and worked with had never seen a line of code before moving into this career. If you are willing to take a small part of your day to learn at least one new thing, you will flourish. Also, intimidation can be removed by communication,. Talk to your team, ask questions, you’ll be surprised how forthcoming everyone in the tech industry is. Everyone wants to help, everyone wants you to succeed.
If you are looking for a role in Testing check out our Live Vacancies or if you are looking for Candidate Resources look no further!
