12

I have experience of working with a team where developers didn't want to do manual testing because they considered it to be wasting of their time - QA work (especially manual testing) doesn't improve their development skills and knowledge.

What should a Scrum Master do in such a situation?

19
  • 16
    personally, I'd buy a set of adult diapers and gift wrap them to the people who need to put on their big child panties. (but that's why I no longer lead a team). The team is paid to get the job done; the company doesn't exist to advance their skills and knowledge. There are plenty of candidates out there who are clever enough to use the opportunity to develop tests to advance their skills. – Mark C. Wallace Dec 17 '20 at 19:52
  • 18
    @Daniel Then they have a point. Automate your testing! Repeated "manual" testing is counterproductive and in most cases just doesn't work. – nvogel Dec 18 '20 at 13:16
  • 3
    Devs can choose as long as the company exists; if the devs are busy improving their skills to do necessary tasks 1) costs will escalate 2) technical debt will accumulate, 3) company goes out of business and 3) devs will jump ship for a new company - which is the signal they've been sending all along. – Mark C. Wallace Dec 18 '20 at 14:23
  • 2
    Fire them, and hire some adults instead. – alephzero Dec 18 '20 at 15:05
  • 3
    My instinctive answer to the title was "then they're not developers". But the actual question is what you should do, and the honest answer is: Nothing except take it up with the boss. This is not withing your scope as Scrum Master. Your developers refuse to do the job they are being paid to do. That's an HR/legal issue. – Tom Dec 19 '20 at 8:24
18

Hiring and Personnel Management are Organizational Problems

Testing is a Design and Programming Concern

Modern TDD and BDD are architectural and programming concerns. In fact, I'd go so far as to say that any developer who hasn't embraced best-practice techniques like test-first design, continuous integration, DevOps pipelines, and so forth isn't really well-suited for most modern software projects.

Separate Technical Roles Aren't Permitted in Scrum

Even if you discount my statement above as personal or professional bias, from a Scrum perspective there are no "Programmer" or "Quality Assurance" roles on a Scrum Team. Everyone but the Scrum Master and the Product Owner is simply a [Product] Developer. In fact, the 2020 Scrum Guide explicitly states:

The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.

While the Scrum Team is certainly free to self-manage the team's workflows, treating programming and testing as separate concerns is generally a framework implementation smell. It simply doesn't lend itself to Scrum's collaborative model of whole-team product responsibility.

Point Out the Elephant in the Room

The X in the X/Y problem you describe is the organization's leadership and hiring practices. If the organization is hiring, encouraging, or retaining I-shaped people rather than T-shaped people, they are not actively supporting the Scrum framework.

Scrum won't magically turn a collection of individual contributors into a cohesive team that collaboratively self-manages; it simply provides a framework for talented and motivated people to apply their skills to a shared objective. This may be a good topic for your next Sprint Retrospective, but continuing problems with the skills or composition of the Scrum Team that can't be resolved internally should be made visible to senior leadership. Setting the right "tone at the top" for both company culture and personnel management are part of senior leadership's core responsibilities, so ensure that they have the information they need to make informed business decisions.

7
  • 11
    The elephant in the room may be that testing has always been low status (e.g., reflected in pay scales or what less skilled developers are relegated to). Perhaps address that in your answer? – Peter Mortensen Dec 18 '20 at 14:56
  • 3
    @PeterMortensen That falls under "tone at the top," company culture, and personnel management. If the company's leaders chooses to undervalue testing, automation, or T-shaped people, then they are responsible for the consequences. In other words, if executive decisions lead to a broken process, the executives get to keep both halves! – Todd A. Jacobs Dec 18 '20 at 16:13
  • 4
    The whole "Separate Technical Roles Aren't Permitted in Scrum" has always seemed the maddest part of scrum. Testing and developing are two different skillsets, automated testing is perhaps a halfway house, but even then, designing test scenarios is a skill in itself. Human progress is built on specialisation and trying to get everyone to be able to do all jobs is a bad idea [None of this applies to a general "make sure your code works as far as you can see" and unit tests but finding the weird corner cases is the sign of a good tester] – Richard Tingle Dec 18 '20 at 18:29
  • 3
    "Separate Technical Roles Aren't Permitted in Scrum" I think you misunderstood that part. What that means is that from the point of view of scrum rituals developers and testers are considered equals. They have same scrum responsibilities, which set them apart from the Scrum Master or Product Owner. Not having dedicated testers on a scrum team in any serious project is a pure madness. – Andrew Savinykh Dec 19 '20 at 8:57
  • 2
    Nothing about Scrum stops you having specialists on a team. It's just that a cross-functional team has a collective responsibility to deliver, to self-organise and to work out who is best placed to do what. – nvogel Dec 19 '20 at 10:18
17

Testing should not mean executing tests (I expect that's what you mean by manual testing). The main business of testing comes in designing, developing and curating automated tests, analysing and understanding defects and fixing them. These are absolutely "development" tasks because development can't be complete without testing. Doing these testing activities does improve developers' skills and knowledge and ultimately makes their lives easier because it's generally quicker to debug a problem when you have code that reproduces the issue than if you have to rely only on someone else's description of a problem. I wonder if the concern you are describing is due to insufficient test automation. Maybe you should encourage the development team to build a better test automation framework.

12
  • No, I mean performing the work of manual-QA engineers. It's not economically feasible to use automated testing in small projects (less than half a year), in such projects manual testing is used, for example, a list of test cases in an Excel file, and these tests are performed manually. Also not every type of testing can be automated - usability testing, look and feel testing, documentation testing, etc. – Daniel Dec 18 '20 at 13:12
  • 7
    What you say doesn't accord with my experience. In projects whether small or large, automated testing will save time and give better quality results. Usability and user experience should be validated by customers, not developers. – nvogel Dec 18 '20 at 13:18
  • 2
    But you said that the developers don't think they should do testing. Developers can (and should) also write tests and it must be quicker to write them once and run them on demand than for the developers to execute such tests "manually". As regards the commercial customer relationship, it makes little sense to me even to get into that kind of discussion with the customer. – nvogel Dec 18 '20 at 14:22
  • 2
    @Daniel "How can you automate testing if a customer disagrees to pay for expensive automated-QA engineers (only for inexpensive manual testers)?" By not giving them the option. They're paying for the product you're producing, not how you're going about producing it. – nick012000 Dec 19 '20 at 10:22
  • 1
    @Daniel "expensive automated-QA engineers" as opposed to spending money on expensive developers doing what you're calling "manual testing"? Ultimately, you're paying for testing or you're delivering an untested product that's priced accordingly and costs you reputationally too: if you invested in getting your developers to engage in automated testing patterns you would save money overall. A QA test engineer would be ideal, on top, but sure. Developers writing automated tests is still better than developers "manually testing" and is arguably key skill development, answering their complaint. – taswyn Dec 19 '20 at 18:23
13

There is, almost certainly, a mismatch in expectations here. First, if you are practicing Scrum, the Scrum team is responsible for delivering an increment that meets the definition of done. There are no subteams - no such thing as the developer and tester from the perspective of who is responsible for the increment of work being done.

Next, there needs to be a clear definition of done that also makes clear what level of quality is expected from the work. If quality is separated structurally from development, it only makes the task of creating a working product harder.

Finally, is anyone actually committed to using Scrum? Did the team commit? If leadership made the decision, are they following through or is it a checkmark on someone's yearly plan? I've seen way too many scrum implementations where the real goal was for everyone to collectively agree they were practicing Scrum to meet some OKR while at the same time, changing nothing.

Now, there is a separate concern here - is the developer worried that working in this way will negatively impact his career? Whether he is right or wrong, if he is sincerely worried, then it is a valid concern. This is more of a coaching conversation. This is not about what Scrum says to do, but helping him be comfortable in his workplace. There are a lot of possible solutions to this, depending on his exact worries, but one might be for him to go on a few interviews and mention that in his current role, he is expected to work with test and chip in to get the increment of the product to a done state by the end of the sprint and see how that goes with the interviewers. This may help him feel like this change is a benefit, not a hindrance.

4
  • Not having subteams in scrum doesn't mean that everyone does everything. A developer, tester, designer etc. ara members of the team, and each one is responsible for their part of their work. – Davor Dec 18 '20 at 14:22
  • You are correct. People will still have their specialties. However, they are all, as a whole team, responsible for delivering an increment of the product that meets the definition of done. If the current way of working is ineffective at doing so, then the team needs to figure out how to adapt. There is no reason those people can't support each other. Thousands of teams around the world do it. – Daniel Dec 18 '20 at 15:59
  • There is no such thing as collective responsibility, that's nonsense made up by scrum salesmen. We are not paid as a group, we are all paid individually, and if I do my part and someone else in the team doesn't, I do not give a damn, I want my salary. We have managers for a reason. – Davor Dec 20 '20 at 16:51
  • There are a lot of models for how to run businesses and teams. I've worked as a software engineer, Scrum Master, product owner, manager, and coach on teams that have a collective sense of responsibility. From an existence-proof standpoint, they exist and work because I've been on them. If your organization doesn't want to do that or the people on your teams don't want to, then you will have a very hard time with Scrum and I wouldn't recommend it. – Daniel Dec 21 '20 at 1:53
9

Your question itself raises several questions. If the developers are responding like this to the business need to test, there is probably a bigger problem.

The other answers here assume that you have a properly functioning scrum environment with automated tests, continuous delivery, and all the other modern hallmarks. Based on your question, I suspect the opposite.

From my personal experience, when you don't have a modern environment, you are stuck doing things the old way:

  1. Testing is done manually, by reading a set of descriptions and then chugging them in to the keyboard while watching for deviations.
  2. Programmers can indeed do that work. However, they will see that as a poor use of resources since almost anyone can do that work. If anyone can do it, why are you paying them? Yes, they should be happy to have a job. However, this sort of work would worry them because you aren't using the skills you're paying for.
  3. This can turn into a feedback loop. It takes so much time to do manual testing that you don't have time to fix the real problem - and build a modern environment.

My suggestion is to talk to your programmers. They might already understand the problem, but you aren't asking the right questions.

10
  • 2
    +1 for the last sentence, which conveys tremendous insight. – Mark C. Wallace Dec 18 '20 at 15:54
  • 1
    "*since almost anyone can do that work"" I think that's the false perception which needs addressing. It's like the old joke about "$1 for tightening a bolt, $99 for knowing which bolt to tighten". The devs have a deep knowledge of the code base which makes this easy for them. It isn't easy for someone fresh to come in and learn how to do it though. – Graham Dec 19 '20 at 9:39
  • @Graham you're ignoring the context where "almost anyone" describes people running the steps described in a test scenario. And indeed, if you have instructions like "Open this, then click here, then type that" pretty much anybody should be able to do that. Or need very little training to get there. – VLAZ Dec 19 '20 at 12:38
  • @VLAZ True; but if you've got that then you should probably be looking at automating it and doing away with humans altogether. More usually, testing involves some kind of test harness, and that needs a bit of knowledge. The other factor is that the inevitable bugs need to be fixed too, and if the coder is also doing testing then the turnaround time on them is much reduced. – Graham Dec 19 '20 at 13:43
  • @Graham testing should be black box in the first place, that's another reason why developers suck as testers, they rely on their knowledge of the codebase and usually don't perform the same steps as a regular user would. – Davor Dec 22 '20 at 10:59
3

A simple operational solution is to require developers to check in their unit tests along with the code. No unit tests, no code review. No documentation, no code review.

This does not address the cultural issues, though.

1

Tell them to shape up or ship out

It really is that simple. Every dev I know (and I include myself!) hates testing. But every good dev recognises the need for it, because we all make mistakes. And anyone not yet skilled enough to recognise the need for it, pretty much by definition, is more likely to need it.

It's no-one's idea of a good time, sure. But it's necessary.

Tell them to adjust their expectations from the job

QA work (especially manual testing) doesn't improve their development skills and knowledge.

Since when was that something you were guaranteed? If you do get that, great. But often you just have to get the job done.

3
  • 1
    That's a great advice on how to lose all your developers and destroy your company. – Davor Dec 22 '20 at 10:59
  • @Davor I've worked for automotive and defence companies that require their engineers to do exactly this. It's part of the development process. I haven't seen Ford (for one example of where I've previously worked) having any problems attracting and retaining engineers because they thought testing was beneath them. If you think you know better than Ford, by all means tell them how to run an engineering company. – Graham Dec 22 '20 at 18:30
  • Ah yes, government work, known for it's high quality of engineering. Also, this has nothing to do with something being "beneath" or "above" anything, it's simply developer not wanting to do what isn't their job. – Davor Dec 23 '20 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.