The importance of testers and testing teams has been established time and again. An application’s or product’s success is largely attributed to efficient and effective testing techniques which forms the basis for valid bug exposure. Goes without saying that bugs are found based on the testers’ skills and knowledge, a keen eye and the dedication of the test teams.
A test team can comprise of individuals having varying skill levels, experience levels, expertise levels, different attitudes and different expectations/interests levels. All these different resources’ attributes need to be tapped rightly, also keeping in mind to fill in any skill gap if needed in order to maximize quality. They need to work cohesively together, follow the test processes and deliver the committed piece of work within schedule. This obviously necessitates the need for test management most often performed by an individual with the role of being a test lead.
There are a lot of skeptics with questions of the value of test automation. Their questioning is healthy for the test industry and it might flush out bad test automation.
But shouldn’t these same questions be raised about human testing (AKA Manual testing)? If these same skeptics judged human testing with the same level of scrutiny, might it improve human testing?
First, the common criticisms of test automation:
- Sure, you have a lot of automated checks in your automated regression check suite, but how many actually find bugs?
- It would take hours to write an automated check for that. A human could test it in a few seconds.
- Automated checks can’t adapt to minor change in the system under test. Therefore, the automated checks break all the time.
- We never get the ROI we expect with test automation. Plus, it’s difficult to measure ROI for test automation.
- We don’t need test automation. Our manual testers appear to be doing just fine.
A successful interview, often means, we get to take a higher step in the career ladder. Here are the answers to some of the reader-submitted questions.
What is the Best Moment in Your Testing Life?
Personal experience based question – an answer that best captures your moment of professional pride as a tester can be given. This could be when a product you tested is successfully live and you have a few of your friends and family using it or it could be when you found a critical issue and received appreciation or it could be when you signed off on your first project as a QA Manager etc. However, if you do not have that one moment, saying that you are generally content as a Tester and that you do not have one incident to mark it all – that is perfectly ok too.
On a lighter note: If you are somewhat of a tease, you can say that – you found a defect which made your least favorite developer work all night on fixing- and that made you smile in satisfaction. Just kidding!
In this interview, Stephen Blower describes his role as a performance tester and the challenges he faces in his industry.
What does your day job look like?
I’m very much at the coal face with hands on testing and coaching of a new recruit into testing who has no previous testing experience
When was the last time you actually tested something? What was it? Can you share your approach/thinking/methodology?
I perform testing every day, which was one of my reasons for changing jobs recently as in my previous role I didn’t actually get to do any testing at all. I work for a finance company so the type of testing I perform is anything from front end web site functionality to back-end transactions and card ordering processes. I don’t use scripts at all, my methodology is very much exploratory using Mind Maps when applicable, plus I do paired testing sessions regularly throughout the week.
How are you/do you/have you observed testing changing over your time in the industry?
This is a difficult question to answer as I haven’t seen much change from others I’ve worked with, as in scripts and strict processes tend to be the norm. It’s only when someone like myself comes along and tries to shake this up and try different approaches. The problem I have with answering this question is that being involved with the Context Driven Community it’s easy to think that others are aware of different testing approaches and many teams are changing, but in my reality this just isn’t true. Over the last 3 years I’ve worked in 3 separate places and each one approached testing from the traditional factory schooled approach and when I’ve started to introduce new and different ideas I have had strong resistance, more so from testers.