Do organizations prefer tools over skills? What does it really mean when they say they want to focus on quality? Let’s find out.
One of my recent interests has been to understand what an organization really means when they say they want to focus on Quality. Do they mean:
– Better process quality?
– Better tools and frameworks?
– Better people to do testing?
It’s very rare that they mean all the above when they really should mean that.
More often than not, the focus really is on test tools and frameworks and not as much on multi-skilled testers who can contribute more to the organization than just the technical knowledge of setting up testing tools and frameworks.
Table of Contents:
Tools Over Skills – Are we Missing The Point?
Testing Tools over Tester’s Skills
To help identify what an organization really needs, I have listed some common roles related to quality as well as a few pointers on where they add real value in an organization.
Manual testers
These are testers whose primary skills are in manually testing your product or application. Their focus is largely on click and test methods. The manual-test-only approach is best suited in the following cases:
- Applications under test (AUT) are very small and lightweight, with a high degree of stability
- Smoke and regression testing new changes with respect to already existing functionality takes less time
- Strong involvement of manual testers in requirements gathering and development processes
- Testers have insight and influence over what is covered in unit and integration tests written by developers
This basically means that manual testing will be beneficial where the functionality is very small. However, as the application/product complexity increases, manual testing alone will result in some challenges such as the following:
- More testers will be added to the ever-increasing testing needs of large projects, which in turn increases organizational costs
- Higher cost and time overhead resulting from repeated testing of already developed functionality
- Increased risk of not testing functionality that has been around for a while with the assumption that new functionality has not broken it
- Decreased motivation and growing lethargy in testers to repeatedly test the same functionality
To address some of these issues, teams start automating test cases with the help of a variety of tools/frameworks.
Test Automation Engineers
These are testers who have a strong focus on testing tools. They are highly interested in test automation using different tools and frameworks. Organizations refer to them by different names: Common titles include “Software Developer in Test”, “Technical QA”, “Test Automation Engineer”, etc. In a lot of cases, these are developers who are hired to write tests. Test automation engineers will add the most value when they work in collaboration with manual testers to ensure:
- Reduced load on manual test efforts by automating new and already existing functionalities
- Most test cases are covered either through manual or automated tests
As with the manual-test-only approach, having a test automation team that focuses only on writing tests comes with its own set of challenges, that are as follows:
- Entry barrier to being a developer in order to write functional test automation code
- Maintain overhead for a large number of tests that get created over time
- Concentrated knowledge of test automation within the team
- Lack of focus on overall test strategy
While test automation in collaboration with manual testing is good, having siloed teams approaching two different types of testing will result in testers not being poly-skilled and will increase hiring costs since two different roles will be needed for the same function.
Poly-skilled testers
These are testers who will be able to help with differing testing needs on different teams and whose focus is not on one particular vertical of testing. Their skills lie in their ability to understand the AUT and almost all factors that influence the quality of that application. They have the technical knowledge to understand development code, are capable of setting up tools and frameworks and are able to address the varying quality needs of a team. That means several things:
- Ability to drive robust test practices, which include but is not limited to focusing on various aspects of testing such as performance, usability, and security, the ability to influence the way quality is approached within the team and also across the organization, selection of testing frameworks based on a number of factors (that are not covered here), test maintenance, defect management, CI/CD practices around functional and integrations tests, and so forth
- Ability to understand an application on multiple levels. This includes the ability to prioritize what gets automated and what gets manually tested based on a variety of factors, such as, business priorities, dynamics of the AUT, effort vs ROI on automating functionality vs manually testing, and so forth
- Ability to understand metrics and influence changes in the dev/testing approach based on trend analyses
Based on the above broad classifications, I want to revisit my original question: What does your organization really mean when they say they want to focus on quality? If the answer is ‘Let’s get some tools and some developers to write tests in those tools…’, then they are missing the point.
A good quality product is one where testing has happened along with development. If the organization is looking at testing as an afterthought or as something that needs to be done as only a final gate check, then no set of tools or tests will be able to solve quality issues that will be seen in the product.
Conclusion
In conclusion, what is required is a deeper understanding of the meaning of building quality into the product. This kind of understanding comes with someone who approaches quality in a systematic way.
Tools and frameworks are meant to achieve testing goals. Poly-skilled testers will use a combination of all three – people, processes, tools, and additionally, their experience – to ensure that quality is not treated as a siloed function but instead, is integrated across the software development lifecycle.
About the author: Roopa Ranganath is an experienced Quality Lead and Agile coach with significant experience in test automation. She has led several teams in testing (manual, automated and performance) and has a proven track record of reducing the cost of delivery. She is passionate about how organizations approach quality and has enabled mid and large-size teams to transform their test practices from waterfall to Agile.
Let us know what you think. Post your feedback and queries in the comments section below. We would love to hear from you.
Good one, yes we need involvement from manual qa when Test automation engineers are automating as they are doing things to help manual qa.. So manual qa is like client to them
So coordination between them is very much needed and quality has to be put from everyone involved in sdlc
@Roopa Ranganath. Thank you for your reply. You have written this line,
“If the testers on the team don’t have experience testing secure applications, then an expert will be able to help. It is then possible for the team to learn from the expert.”..
So my question is don’t you think that in such an organization, an expert in security testing is more worthwhile then a poly skilled tester? he will be paid more. and will be of much value in the
bank.
you can say that a poly skilled tester will learn security testing from that expert and after few months this expert is not needed ? Why? because the poly skilled tester can now do security testing
himself. That means now this poly skilled tester has become kind of “expert” in security testing.
Now there is a good chance, that this poly skilled tester gets interested in security testing career and pursue that field full time. He will get new job offers based on his security testing
expertise. His demand as a security testing expert will increase not as a poly skilled tester. For long years ahead, he cannot just remain poly skilled… he has to become an expert in either
security, performance or functional automation. Because each of these fields demands full time focus, research and there are lot of challenges in each of them.
you can take an example of MBBS doctors as poly skilled. they know every thing about medicine. But when case is serious in any particular field , such as a cardiac case or brain problem, they
always refer to the specialist doctos. Now my question is …who is paid more ? MBBS or specialist ? you know the answer for this.
another point is that MBBS doctors do not remain MBBS for ever, they tend to become specialist in one field when they grow in their careers. because that is what they should do. They cannot remain
MBBS forever and people will always trust a specialist more than an MBBS doctor. Similary companies need and trust experts more than poly skilled testers.
In short my point is that poly skilled testers are good but after a certain set of years, a poly skilled tester should also become an expert in any one field if he wants to remain in demand. A poly
skilled tester can identify gaps like this that “hey this application is slow, it needs performance testing” but who will do that performance testing? . That will be an expert. Who will be paid
more than that poly skilled tester.
Be the jack of all i.e. get to know about everything related to testing in start of your career (become poly skilled) but become the master of one as well in coming years. (i.e become an expert
either in security , performance or functional automation).
I respect your opinion in this article, but based on my own experience, I am writing my opinion. Experts will remain more in demand than just a poly skilled tester.
Nice Article. My question is , how much years of experience is necessary before becoming a poly skilled tester?
You said that poly skilled testers should focus on performance, usability, and security. In my opinion, performance testing and security testing both needs high degree of expertise…
Plus how would a poly skilled tester will focus on all of these things at once? Full manual testing, security testing , performance testing, plus test automaton plus test maintenance, defect management, CI/CD practices ….. I don’t think a beginner level tester can handle all these things. It takes years to get the deep level knowledge of each of these things.
Reply me if I am wrong.
Regards,
Saad
Saad – thank you.
‘how much years of experience is necessary before becoming a poly skilled tester?’
>> There is no right number for this. Test experience varies depending on products, applications, domains, etc. Good testers are able to apply previous learnings in addition to learning new skills/techniques with every product/project/application they test.
‘how would a poly skilled tester focus on all of these things at once?’
I agree completely with you – it’s not possible for one tester to focus on all aspects of testing (manual, automation, security, performance, etc.). However, it is possible for testers to identify gaps in testing and ensure that any gaps are addressed. Areas such as security, performance, and load testing are specialized areas of quality and require concentrated efforts on them depending on the AUT. It is possible to recognize which application needs more testing in a particular area over another. For example, a banking application will need concentrated efforts on security testing. If the testers on the team don’t have experience testing secure applications, then an expert will be able to help. It is then possible for the team to learn from the expert. While poly-skilled testers won’t be able to do all kinds of testing single-handedly on the team, they should be able to identify gaps in testing and ensure that those are addressed.
Hope this helps!
Roopa
Excellent article. I think it is up to the individual’s drive and his/her superiors as to whether they become a poly skilled tester. Some will after 5 years. Some may never. Do we include technical writing as a desirable skill? I think we should.
Thanks for the highly motivated article
I strongly agree with this point of view. I think it is not enough to do only manual testing or only automated testing and it should be a combination of both. I also think that being a good tester means having a very good understanding of both the businesses / user perspective and the solution itself. Unfortunately, companies tend to separate the two and this happens for several reasons and I would highlight costs and technical background. Often, good manual testers don’t have a technical background, and it would be a company investment to train them for automation and companies are not always willing to do so, mostly because they can find a junior dev to handle that, who will probably need less or no training. It could work on the short term, but I really think that on the long run the good testers will leave this type of company and search another one that gives them the possibility to grow professionally, and those developers, if they cannot switch to development , they will also look for other opportunities. So, on the long run nobody gains anything from this approach.
Ami – great observations!
A lot of companies have not evolved their way of thinking about testing. Either it’s developers who become automation experts or it’s manual testers who are not encouraged to get more technical automation knowledge or skills.
@Saad,
I believe that you and I are talking about the same things but in different contexts :-).
I’m a strong proponent of gaining expertise in security, performance, or any other specific domains of testing. I’m also a strong believer that paired programming (especially wrt test automation) will help us better our skills. Pairing with an expert will help us get more context around the AUT but will NOT make us an expert immediately. Expertise will have to be gained over time with concentrated efforts on gaining specialized training and skills in areas such as security testing.
My article references a more basic problem that we are facing in the industry – there is confusion around what testers should be doing. As Ami highlights in her comments, there is a rising belief that testers (in general) can be skilled in manual testing and that you need to be a developer to do test automation. My article highlights that this belief is not true and that testers can be poly-skilled at various levels. Taking this one step forward, I believe that poly-skilled testers will be able to gain mastery in areas that interest them and they will become experts in those areas – this is what you also reference in your comments which I completely agree with.