I saw this question pop up on Slack and I thought it would be excellent to transfer to The Club as Iāve seen variants of it come up frequently.
How would you sell yourself when someone asks why do we need a tester when they have full stack developers who can dev and test? apart from regular answers like different pair of eyes, testers having different approach to that of a developer, identifying bugs being main priority for a tester etcā¦
The replies on Slack were:
Depending on the devsā level of testing skill, I would either sell myself as a quality coach or just become a developer.
When Iām doing development work Iām in a different mindset then testing; it takes mental effort to switch gears
Being a Quality Advocate, not simply a tester - pushing for quality across the board, asking questions, ensuring good definitions, testing as a user etc
Exploratory testing, not simply acceptance testing or checking boxes
Different mindset and role reduces cognitive bias (check it works as I expect, vs. what happens when I do this?, will this break it?)
Iāve seen some really great developers in my time who were very skilled at exploratory testing so I lean towards the quality coach response myself.
When I hear ādevelopers can testā, I assume they are comfortable doing manual exploratory testing, creating test automation and integrating that into a CI/CD pipeline.
If the developers can do this, and the business hasnāt suffered, they might not need a dedicated tester. But if the business notices bugs in production, then it might be beneficial to seek help to find better ways to test.
At first I can see bringing in quality coaches to help. These coaches can help the developers be more effective in their manual testing and their test automation. As the business needs grow, other testing specialists might be needed such as improving performance and accessibility.
My main point is that the driving force for this decision should be the needs of the business.
I do not have enough information about the context or the product, project, stakeholders so I would like to know about how things are working on a daily basis and at their worst times;
I would also ask what are some of their problems of users, of stakeholders, of release timelines & confidence, of current testing costs, of refactoring/patching product code, of law/regulations/standards, of demands/requests, claims/marketing/support, etcā¦
I would also then mention what a tester actually does: find threats to the quality of the product - through technical empirical investigations on behalf of the stakeholders. Some examples might be usefulā¦
Why do we need a tester? is like asking 'Why do we need someone to find problems to the quality of the product? I canāt answer for the person askingā¦
Iād say "All depends on what you mean by ātestingā. If all you mean by ātestingā is āmaking sure all the buttons do what they say they shouldā, then fine, you donāt need testers.
But if you want to find risks to the integrity and acceptability of your product before end users - who may vote with their feet and/or wallets - then you need testers.
And when (I say when, because it will happen) some embarrassing bug crops up, and everyone on the Net is laughing at your product, and you ask āWhy didnāt we pick this up in testing?ā, unless you have testers, youāll have to understand that you, yourself, is included in the āweā in that question."
We donāt need testers or testing. I tell project managers that testing is optional.
Testing is an information collection and reporting activity. If a project can develop a product or deploy a product without the information that testing provides, they should do so. That is a project management decision.
However, continuing without knowing the behavior of the product, the performance of the product, or the value to the business of the product incurs a great deal of risk. If a project manager decides to accept that risk, then testing is not needed.
I have not had one project manager turn away the services of a testing team when I explore risk with them.
As always: It depends. Without reasonably sufficient information & context this question is impossible (or at least hard) to answer.
Iād usually respond with āI donāt know, you tell me.ā ā If they assume (presume?) that testers are not needed, I may suggest to send them on a long (paid!) holiday, say 3 or more months. In most situations that is long enough to see whether testers are needed or not. If they seem to be extra bold I might even suggest to fire the testers and then see what happens.
Sometimes it helps to figure out a) if testers have found bug in the past and b) in that case what bugs they have found.
In the (unlikely) case that the testers didnāt find anything, well maybe they are not needed that much. But even then having testers may have a psychological effect on other developers in the team to be carful in order to not produce bugs.
This question should be answered on two levels - 1. team and 2. the industry as a whole.
At a team level, itās welcome if developers want to test. As long as they are clear it doesnāt involve code. The challenge is to be able to demonstrate to the developer how you can find bugs that he/she wouldnāt. I also think itās fine to be able to influence developers on how to test. It would have been nice if teams who do this, also explain testing on their blogs or public talks. In most cases, in these teams, testing is some variation of automation.
At the industry level, this is a tired question. Is there a single blog, talk, book which shows a developer testing? If not, why do we keep having this tired discussion? To me, this is often promoted by testers who are advocates of coaching, not developers.
There are a few examples of devs explaining testing. The Ruby community is particularly good at this, because of their focus on test first. Brian Marick shows how to test in his book, Everyday scripting. There are others who are also good like Sandi Metz and Russ Olsen. However, they are all very code focused. They still make the good point that they ask a lot of questions and there is a back and forth to find a good solution.
@seasidetesting " I might even suggest to fire the testers and then see what happens."
They did this in my last role. The day after I left, the company posted online to say āClick here for a virtual tour of our new city centre offices!ā
Of course, no-one had thought to actually test the link first.
Nice Question! Actually many people have this question in their mind that though we have developers in qa testing companies who used to develop the softwares, Arenāt they always striving to release software that meets their customerās requirements?
Let me tell you that even with the most diligent of developers, software testing and developing are two different disciplines and it can be tricky to look objectively at the work whilst developing it. This demonstrates that having members of the Development and Software Testing team in qa testing companies verify that the product is being built correctly and that it meets customer specifications, helps to eliminate issues before it reaches the customer.
Developer may be biased with the fact that he has developed it, so may not test some areas as heās confident enough that he has developed it bug free. However, tester will check the same from his/her doubtful eyes. As a software should be tested in a neutral way to have unbiased testing results. This can be done only by a third person (not developer himself).
The points below shows the significance of testing for a reliable and easy to use software product:
The testing is important since it discovers defects/bugs before the delivery to the client, which guarantees the quality of the software.
It makes the software more reliable and easy to use.
Thoroughly tested software ensures reliable and high-performance software operation.
Testing is not about just validating that system is performing what it is supposed to, but importantly it is also about assuring that the system is not performing what it is not supposed to perform. A tester delicately does that and does it better.
Also, Testing helps developers and testers to compare actual and expected results in order to improve quality. If the software production happens without testing it, it could be useless or sometimes dangerous for customers.
So, a tester should wear a unique hat that protects the reliability of the software and makes it safe to use in real-life scenarios.
Conclusion: Testing a functionality at different levels and requirement is the reason a tester is set up in qa testing companies instead of a developer.
Without reasonably sufficient information & context this question is impossible (or at least hard) to answer.