Yesterday, I was in an interesting conversation with the
HR of a famous company, which has around thousand
employees locally. I asked them how can we improve their
testersâ life, what kind of augments can we provide.
They said, âWe have been operating for the last 2.5 decades
without testers. The developers test their own code.
Also, we have 99.9% employee satisfaction. That 0.1%
dissatisfaction is because they are not getting opportunities
to get promoted.â
It is not new to hear something about developers testing their
own code (which I disagree because it denies the opportunity
to look at the product from an out-of-the-box perspective), but
it was educating to know that there are companies like that
who do that for a long time.
How many of you have come across companies like that,
and what do you think about this whole thing?
Judging by the number of barely-usable apps I come across In Real Life, there must be a lot of companies like this. But any company that produces any sort of human-facing app that doesnât expose its product to testing is just storing up trouble for itself,
No matter how much the developers test their own code, all that guarantees is that the code produces expected outcomes from expected inputs. It takes no account of what users will do to the app when they encounter it, and how the app will respond. After all, Iâm sure Boeing were confident of the control systems in the 737 Max when the plane rolled out onto the runway for the first time.
One problem I see with developers testing their own code is the limited time available for them to test exhaustively several combinations. If you consider a reasonably-sized user-facing app. today, it has to be tested with multiple operating systems, browsers, devices, etc. Techniques like Pairwise Testing could help to some extent, but the complexity quickly grows because of the special situations to be considered.
Interesting topic! When I would join a new project as a Test Lead, I meet with the project manager to talk about testing (software testing is very well supported in our company).
Our conversation would cover the amount of testing required and the number of testers required.
The project manager would explore methods of reducing the time required to complete testing. I would typically respond with something like âall testing is optionalâ followed up with all the risks taken when testing is limited by time, people, collaboration, or information. It was always a good conversation and the PM rarely thought of testing as optional.
I agree with @robertday. Many companies choose to view testing as an activity to perform rather than a strategic or competitive competency. As a Tester, we can raise awareness around risks to add to the information pool that drives decisions. If a company still wants to take risks with their product, it is their choice. As Robert said, they are asking for trouble.
âWe donât need testersâ is certainly something that would flag up as a concern.
However, there is an alternative view. Maybe the organisation doesnât want testing restricted to a single role (the old âprogrammers program and testers testâ view). If testing is an activity that is truly shared around a team then could view the team members as entirely made up of âdevelopersâ. Some help with the development of the system by writing new code, some by writing new tests, some by exploring, some by improving infrastructure or some combination of all (and more).
In that view, maybe the organisation is happy to say âwe donât need testersâ - it doesnât necessarily mean âwe donât test (or test well)â.
Iâm talking generally here rather than about the specific example posted but itâs maybe a nice ideal to think of - where everyone thinks about testing (but you should still have specialists in testing who guide and educate).
Unfortunately, I donât have any proof to say if testers are needed or not. As an outsider, it looks like there are some companies which are doing well without testers and some which are doing badly despite having them. If it is indeed possible for companies to work well with zero or almost zero testers, then Iâd like to know their secret and what is the long term viability, especially if the company grows.
I heard that Microsoft has very few full time testers. Iâm not sure if they have many temp testers. It seems to be going okay for them. I donât see too many job postings for testers in Google and Facebook. OTOH, Amazon started posting large number of tester jobs recently. I donât know if that is partly or wholly due to the pandemic, or also due to realizing that testers are necessary for them.
IMO, to answer your question, we also need to think about the following questions.
What makes excellent testers?
Is it training alone or inherent quality/genetic luck? If it is only due to training, then we could train intelligent people/developers to do excellent testing. If it is only inherent quality/genetic luck, then we cannot produce people who do excellent testing. Then, weâd have to discover such testers.
If someone is an excellent developer, then is it guaranteed that they WILL become excellent at testing?
If yes, then we only need to train the excellent developers to do excellent testing. This wonât be scalable if there is a short supply of excellent developers. If no, then we need to hire testers separately for testing. Does excellence in backend development automatically mean that youâll be excellent in front end design and UX also, provided you tried hard and spent enough time on it? I doubt it. Similarly, would you be an excellent tester also? I donât know the answer to that.
If there is some genetic/luck that makes a great tester, I donât have it.
For certain Iâve learned a lot that contributes how I test that others could learn.
As I develop my programming and test automation skills, for sure I havenât had to forget what I know as a tester. But to make time to write code, I have had to consciously stop doing some of my good testing habits.
I think others have put it well. It isnât that developers canât or wonât test, in fact many of them are excellent at it. But we need to make time for testing, and time to invest in the learning for how to do testing well.
As I understand it, you donât need to call people Testers to invest in their testing skills and give them time to do testing. But⌠That is semanticâŚ
Keep in mind that this is a lose-lose discussion, i.e., you can never win that argument.
Also keep in mind that most developers are clueless about testing. Having said that, just because someone is called, âtesterâ, doesnât mean they have a clue.
This is still an interesting question that you need to answer for yourself. Let me ask you - with a 1000 person company - how would you check whether their customers face any problems with software?
Hint: The 99.9% is a smell.
Iâm in the donât need testers camp, though I think that like a lot of things today, too many people hear that as a black/white topic instead of recognizing the shades of grey. I believe everyone owns quality, and everyone should test, but not everyone is going to test to the same level. Just like not all team members are going to engineer, write code, etc at the same level - everyone has strengths and weaknesses, and having an SDET or someone with a test-forward mindset can definitely help balance out the skill sets.
Alan Page had a related post on this today as well:
@ipstefan - Thanks. There are some excellent points in the article. But, one might have to take classes on Rapid software testing to see the antidote to âwe donât need testersâ (see the end of the article)
I wish we could get some evidence from a company which has zero or few testers (compared to developers). I am really curious to know how they do it and how well it has worked over the years. Maybe it is possible to get rid of testers, but it is not possible to do it in every company. Do you know any companies which donât have testers?
@robertday - Without connections and insight into a company, its hard to tell why their app is barely usable. Perhaps developers can be taught how to test their own code well and also get some ideas on how to do better testing including user-like testing. As for Boeingâs problems, I wonder how we can tell if any of those problems was due to lack of testers/testing.
itâs maybe a nice ideal to think of - where everyone thinks about testing (but you should still have specialists in testing who guide and educate).
It would be a nice ideal if everyone thinks of a product with better Quality, not testing. Why only testing? What about UI/UX issues? What about build issues? What about product management issues? Donât they all contribute to product quality?
The danger is in people starting calculating how many testers are needed for a bunch of developers. I recently responded to a discussion in Twitter which approximated 2-3 testers for 7-9 developers. Well, what justifies these numbers? The no. of testers needed would be dependent on the extent of testing that needs to be done, not through hard-code budgeting saying âfor this many developers, we need this many testersâ.
What assurance is there that the developers would indeed listen to the testersâ recommendations on areas to test/explore/run automation on?
Sorry I missed whose ânice idealâ is this at the first place. Where did it come from? Is it part of Agile manifesto?
No company needs testers.
Need = require (something) because it is essential or very important rather than just desirable.
Companies can work without having testers. Unless the company gains their revenue from testing services.
Some companies can work even without having/paying for testing.
A company might not want to pay more for testing than for the impact of not testing.
A company might pay for bad testing thatâs causing more trouble and attracts more money badly spent on tools, hardware, contracts, receiving non-usable test information;
A company might not want problems revealed; as that can cause extra work for many people, decision taking, arguments and clarifications, triage of problems, prioritization of bugs of features, stakeholders expectation problems, bonuses not received, and so on.
A company might just deploy products and monitor - fix as triggered by a monitor check; so they would not directly test, but monitor and fix production bugs only;
A company might have all the testing externalized; so they donât actually need testers, - unpaid(beta releases) or paid(bug-bounties);
A company might switch the roles of a couple of people to test products, people that would never have the role of a tester;
etcâŚ
As people using products and as testers, we would like to think that companies want to provide exceptional quality products. Thatâs not the case most of the time.
Lots of companies have a low bar and a good-enough(no sales impact) quality.
The fact that mindsets do exist, is for me enough reason to support having a mix of people types on my team. Testing software today requires specialized tools, quality covers multiple disciplines such as UX, process and security. As does building software cover multiple disciplines. To assume one person can be equally good at using both tool types is just bizarre.
Around 2000 there was a discussion about testing in TestNet, the Dutch Special interest Group in Software Testing. Every way of organisation had its own cause. It lead to the following cycle:
no tester
a dedicated tester
a test department
a dedicated tester
no tester
There was a chance that the cycle would repeat it self.
No tester
When I started in IT, I was a software developer. I had to do all things: analysing, programming, testing, and coordinating. So long my customer was happy, my boss was happy.
A dedicated tester
I noticed that there were companies who needed dedicated testers. They lacked the knowledge and experience. As a test consultant I went to different companies and did my test job.
A test department
After a while I became an employee of a big company. They needed testers and also testers working in similar way. So I was one of the first employees of the new test department.
A dedicated tester
Years later I focused on agile testing. One company only needed an experienced tester, so they hired me.
No tester
Later on another company switched to DevOps. The developers had good grasp of testing. I was expected to program.
What I want to tell, is that the need for testers depends on the context. There is no universal yes or no for dedicated testers.
When I started working as a developer in the 1980s there was no such thing as a âtestâ role. Developers were responsible for checking the software produced by their project team (most I worked with were labelled âanalyst programmersâ which covered requirements through to deployment in my world). If you were lucky tech authors or maybe trainers might spot a bug or two before release and let you know. Fixing urgent bugs when customers spotted them frequently involved faxing detailed instructions for editing and compiling code to a user (big MIS solutions written in Oracle so source code was shipped and could be compiled on site), otherwise it waited maybe 6 months until the next update was sent out on tape.
Itâs still possible to function without testers but you need devs with a certain mindset - back in the 80s and 90s the code I worked on was extremely low in bugs but only because the devs working on it knew how much it would cost to write a new set of tapes to ship to every customer and were very conscious of budget restrictions so worked quickly and accurately (code reviews were only used for new members of the team and devs who didnât work to the high standard required moved on quickly - devs were in demand and you could pretty much walk into the first job you applied for if you were half decent back then). Today the quality of code that is sent to test isnât as great simply because thereâs that extra âguardian angelâ layer between the dev and the customer.
I can tell you with 100% certainty that both Google and MS employ a large number of contracted testers. Amazonâs ratio is the lowest of the 3 companies that you mentioned, so itâs interesting to me that you mentioned that they are hiring - Maybe a change in strategy?