Ttdfjt

Question

I'm in a software development team where we are two developers often working on different things, but no dedicated QA team member.

Our support person sometimes handles testing or we try to test each others work, or our manager does it.

This is the only place I've worked that doesn't have a dedicated QA team member. I've found QA to be extremely beneficial and think it can help us but I must justify why.

The reasons I can think of are:

QA is being done by developers, taking time away from development.

No one person has the responsibility of domain knowledge of all our
UI and other systems.

A dedicated QA who has chosen that as a career
actually wants to do it, and be good at it.

A skilled QA will have knowledge of writing automated tests

What reasons am I missing?

Quite simply, QA are cheaper than developers and are more skilled than developers at QA. It's like asking why do you hire an accountant to manage your accounting instead of getting your developers to do it instead. Developers are ill suited to the job of QA in the same way that they're ill suited to Accounting. — Jul 25 at 0:24
@Stephen Disagree with "more skilled than developers". I think what you mean is that they haven't been inducted into the insane groupthink that we impose on developers called "architecture" and "coding standards", which allows them to interact with the software in a very different mentality from a developer. — Jul 25 at 1:45
@Aron So they're more capable than developers at doing the job they're being asked to do (QA). It doesn't matter what the reasons for it are, QA specialists are better at doing QA tasks than developers, whose primary task is development. — Jul 25 at 2:50
If two developers need a dedicated QA, y'all better both be goldenchild's and writing some very choice code that does things like launch space shuttles. I'll assume you aren't and that you don't, so good luck convincing your manager that a full 1/3 of your workforce should be ancillary. "justification" is the most important word in the post; if health and safety, or the company's reputation, aren't endangered if it's bad code, the only thing that justifies hiring more people is the prospect of making more money. — Jul 25 at 13:58

Kate Paulk♦Kate Paulk 25.8k6 gold badges43 silver badges90 bronze badges · Accepted Answer · 2019-07-24 12:06:15Z

First I would rephrase your reasons:

Testing being done by developers is good at the unit test level. A dedicated QA is likely to have more skill in finding and exploiting situations the developers didn't realize could be problematic (but customers can and will find).

A skilled QA will quickly gain knowledge of the entire application domain and then apply it to find situations that the developers with their deep but narrow expertise (which is necessary) can miss.

A dedicated QA who has chosen that as a career actually wants to do it, and be good at it. (I wouldn't change this at all - but I would add that it's not rare for developers to resent the need to constantly test and retest when they'd rather be coding).

A skilled QA may have knowledge of writing automated tests.

A few other reasons you can add:

The person who wrote the code is often blind to its limitations because they are too familiar with it. Skilled testers know how to work to avoid allowing familiarity to blind them to problems.

Skilled testers will deliberately do the wrong thing with the software. This can expose major problems developers would not think to test (personally, I've lost track of the number of times I've been able to force software into a state developers would have thought could never happen).

Skilled testers will try to find and test every way to use the feature being tested. They won't find all of them, but that's only because every sufficiently complex piece of software has an infinite number of paths through it. I once tracked down a problem that only occurred at the end of something more than 50 steps.

Skilled testers can help developers choose useful scenarios to automate in unit tests or other automated tests.

Skilled testers can find problems with requirements documents and/or user stories before coding starts, saving time and money by avoiding rework.

If you're having to make an argument to management, you will want to focus on time/money savings. To do this you will need to do some digging into whatever tool you use to report issues and note the proportion of them (preferably an average over a specific time period) that you think would have been caught prior to release if you'd had a dedicated tester. If you have any numbers relating to the amount of time it took to fix those problems (again, an average per quarter or per month works), use them, and compare against the time that your team needed to fix problems that you found before you released. You can then make the argument that the difference is time your team could have been working on new functionality which is more profitable for the company than bug fixing.

You touched on it, but maybe you want to add this angle specifically as it may speak to management's view: Being good at developing takes time and "brain capacity" and thus money. The same holds for testing. The skills are separate and most people can improve in either areas for all of their professional life. Time spent by developers trying to get better at testing isn't time spent developing or getting better at developing. Hiring a QA person means they already have the skills and instead of wasting money (time = money) on developers learning how to test, you save that money. — Jul 24 at 20:00
To me the #1 reason is the problem of the developer being blind to the errors because he sees the code he wanted to write, not the code he wrote. — Jul 24 at 22:30
I'd put a little more emphasis on the If you're having to make an argument to management, you will want to focus on time/money savings. part. If management is not technical at all, they may just hear "we want you to hire someone who will do part of our job for us* — Jul 25 at 4:32
+1, but here is one more crucial one: QA is a separate set of eyes (and mind) reading the specs and flushing out unsaid assumptions - which might be different from what developer assumed. — Jul 26 at 18:15

score 13 · Accepted Answer · 2019-07-25 08:02:39Z

13

There is also a different mindset that a tester (or a dedicated QA) would bring to the team: developer "builds things", tester "breaks things".
(When speaking of a "break things" mindset: Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.)

A tester is dedicated to finding out new information about the thing they are testing, information that might be hidden from everyone (including the developers that made the thing) until it is subjected to a test.

edited Jul 25 at 8:02

answered Jul 24 at 11:33

Mate Mrše

5923 silver badges26 bronze badges

4

This is a very common misconception, that can quickly fall apart with some thought. Testers didn't write It so they didn't break It, they tend to not change the program/code they are testing. So there's quite no way to break anything. Unlike a physical object that can be broken by dropping it or using it in an unexpected way, software can only be broken by those who created it. Testers just find places that are broken and report them. Sometimes, it isn't even actual breakage so much as something that doesn't work the way customers expect or want it to work.

– Mobile QA
Jul 24 at 17:50

1

@MobileQA one could argue that little Bobby D. Tables actually broke the database. It stopped functioning in an case. I think a good tester will go beyond just finding broken things. At the very least I'd expect them to find things that might be working, but are unsafe in the sense they won't resist abuse, whether naive or intentional. This is different from most developers that focus on the happy path (can I achieve specs if I use my code properly, knowing exactly how it works) and don't necessarily attack the specs either.

– ptyx
Jul 24 at 22:58

1

@MobileQA I was speaking more of a "break things" mindset. Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.

– Mate Mrše
Jul 25 at 6:37

2

Unfortunately though, the "breaking things" way of describing a tester's perspective has a bad tendency of leading to even more illogical words and behaviors. For example, "We could ship this faster if those testers would stop breaking everything." We break assumptions, or as Michael Bolton often says, "We break illusions about the software". That is our mindset, but if we aren't clear in the way we discuss it, people can easily fall into illogical blame games, "shooting the messenger", etc., etc.

– c32hedge
Jul 25 at 17:16

4

Also see developsense.com/blog/2015/02/… for Michael Bolton's much better explanation than I could put in a comment :)

– c32hedge
Jul 25 at 17:17

|
show 3 more comments

CherreeCherree 1,1246 silver badges10 bronze badges · Accepted Answer · 2019-07-24 14:56:05Z

Like many of the other roles (particularly in smaller teams) a dedicated person performing that role probably isn't actually necessary and may even be a point of inefficiency in some situations. That said just like with any other specialization in software development, having expertise, interest, and dedicated time to focus on a particular problem area will often enable the dedicated person to either bring their experience to bear on the problem or add insight when coaching their team to take on this mindset or the activities as part of their work.

Many development teams where I work are experimenting with either no-QA models or using QA much in the same way you might an agile coach. There's a lot of value to be added when you encourage a team to follow practices that result in higher quality outcomes whether or not you're doing testing yourself.

Curt J. SampsonCurt J. Sampson 1713 bronze badges · Accepted Answer · 2019-07-25 04:11:53Z

I'm going to take a slightly different focus on this question; my
answer is: A dedicated QA team member isn't necessary, but a
dedicated QA role is a good idea.

Consider a situation where you have a dedicated QA team member but he
does a poor job (or doesn't do his job at all). In this case, you've
got a particular solution in place, but the problem isn't being
solved. You would need to move "up a level" and focus on the actual
problem, rather than the details of a particular attempted solution.

Good QA is indeed extremely beneficial. If the problem is that you
feel in your current project that you don't have good enough QA, you
(and especially your management) should look at both how you might
move some resources from elsewhere to QA and how you might add
additional resources to the project for doing QA. Adding a dedicated
QA person to the team is certainly one way of doing the latter, but
not the only way.

Here are some other solutions you could consider:

Set aside one or two days a week for an existing developer
(probably the one who's most interested in QA) to work specifically
on that, rather than on developing new features.

Hire a new developer with a lot of expertise in QA, and have him do
the above for part of the week and development for the rest of the
week.

Hire a QA person who's learned a bit about development and is
interested in learning more, have him spend some time on QA and
some time on development. (Ensure you allocate some time and
resources to training him in development!)

Bring an expert from elsewhere your organization into the project
part-time to work on QA, especially on training full-time members
of your project in QA.

You may choose to use a mix of these solutions over time, and move
"focus on QA" around the time over time as well.

There are two advantages to these sorts of solutions:

You have more flexibility in terms of resources because you don't
have a certain amount of work hours that can be used for QA only
and isn't useful elsewhere. Being able to devote a "fraction" of a
person to QA means that your manager doesn't have to face the
decision of "I need to spend a lot or nothing at all," and risk
ending up with the latter.

The QA knowledge tends to spread through the team, rather than
being concentrated in one place, both reducing the bus factor and,
more importantly, ensuring that developers are writing code and
developing systems designed to support QA processes, rather than
hinder them.

Regardless of who's doing it, during the time someone is focusing on
QA he should not be thinking just "today I do manual tests of the
system rather than coding," but "today I'm focusing on where we have
quality issues and what we can change throughout the development
process to mitigate these." This could include:

Studying QA to improve her skills at it, testing and trying out QA
tools, and so on.

Developing tools and systems to help automate tests, at any level
(unit to customer acceptance).

Analyzing current and past QA issues, and figuring out the most
effective place to change systems to mitigate those issues. This
could range from changing something developers are doing to
changing part of the release process.

Training other developers in QA viewpoint and process, so that they
tend to produce fewer problems for QA to catch and make systems
where QA problems are easier to catch.

What I describe here is really a specific use of a more general agile
principle that applies to DBAs, release engineers and all similar
roles: everyone involved with the development team is a "developer"
and should be allowed, even encouraged, to learn more about things
outside their area of specialization so they can contribute in
multiple ways to the project. (In other words, avoid "siloing." or
having someone involved with your development team who's not supposed
to work on development.) To do this you make specialists roles,
rather than people, so that the the QA specialist "puts on her QA hat"
rather than being "just the QA specialist."

To summarize: rather than making your dedicated QA, make it a role,
and have someone dedicate time to that role. It doesn't have to be a
lot of time (certainly not full time in a project with only two
developers), but you need to ensure you remove pressure to work on
anything else during the time dedicated to that role.

One further note, your issue that "No one person has the
responsibility of domain knowledge of all our UI and other systems"
also is bad, though that sounds to me as if it's a customer role
rather than a developer role. Agile has similar solutions for this,
too, though I won't get into them here.

TheLucklessTheLuckless 1212 bronze badges · Accepted Answer · 2019-07-24 15:43:15Z

Dedicated QA as a distinct element from the direct programmers achieves two critical things for software development:

It helps distance testing from coding, thereby reducing bias.
- Smart programmers don't make bugs, all programmers like to assume they're smart, therefore programmers don't make bugs... Combine this with deadlines that programmers are driven meet, and you have a very nasty snowballing cycle where lots of little things are "Overlooked" with the idea they'll be quietly fixed 'some time later'.

Keeping QA as independent from Programming helps reduce the temptation to gloss over QA because the manpower resources are 'needed for code'.
- By keeping a core team with a focus on QA as their primary job, they can maintain the freedom to actually test and explore the software, and dedicate time to long term QA development. When trying to have core programmers do the QA work along side development, then it is far easier to let the QA side slide and risk a snowballing nightmare.
- However even then it is far too easy to allow QA to fall into "Rubber Stamp Mode" if they are understaffed and not allowed enough time between code 'completion' and release. Understaffed and under-supported QA teams are also a road to the snowballing nightmare.

Beyond that a good QA serves as a check and balance process to both design and code. They help highlight issues earlier in the process, thereby saving a project time and money.

In my career I've seen half-hour meetings between QA and the Business Analyst team spot and help correct a flaw that would have accounted for months of development time.

score 2 · Accepted Answer · 2019-07-25 14:12:45Z

I would like to argue that a dedicated QA member is NOT necessary.

A very good developer is a also very good tester. Yes, you need to learn and practise switching between building, breaking and a user-centric mindset when validating that the software built works as expected.

The last four years I worked with three teams (of four developers) that had no dedicated testers. I functioned as their outside Testing Coach. They build better quality software then my current team which has three testers and three developers.

Keep in mind I am not against dedicated testers at all, but there are risks in handovers to dedicated QA-members. Mainly that quality is not a whole team approach. QA lags behind. Developer-QA issue ping-pong. Context switching. Crappy test automation. QA shortcuts under release time pressure.

There is some literature about this aswell, like in his book "The Clean Coder" Robert C. Martin writes:

QA should find nothing

Therefore, when you release your software you should expect QA to find
no problems. It is unprofessional in the extreme to purposely send
code that you know to be faulty to QA. And what code do you know to be
faulty? Any code you aren't certain about!

Alan and Brent discussed this on their podcast and came up with the following Modern Testing princible, which also suggest that dedicated testers might not have a future:

We expand testing abilities and knowhow across the team; understanding
that this may reduce (or eliminate) the need for a dedicated testing
specialist.

https://www.angryweasel.com/ABTesting/modern-testing-principles/

Niels, with respect I disagree with your point.This may be true for very mature organizations where Developers & testers are mostly on same level in both skills set but not in general mid to small size organizations where testers are not too technical and developers lack the domain knowledge and in general testing skills. — Jul 27 at 15:23
@VishalAggarwal Fine, I have this discussion all the time with people. You have to experience a good Agile team with 100% test automation and decision making based on data to be really convinced. Still I think you can teach developers and in mature organisation have no more testers at all. Development teams should practise technical excellence, testing is a big part of that, but i truly think you do not need a separate role for it, nor special skills: less.works/less/technical-excellence/index.html — Jul 27 at 18:00

AnandAnand 5244 silver badges16 bronze badges · Accepted Answer · 2019-07-26 11:15:04Z

As per my observation, the dedicated QA will help the below process:

1) QA can help the dev team to capture the different failure scenarios and breaking of the system.

2) If QA is a most senior person working with the junior dev team then he can guide the team to build the project or process.

3) Since dev team is working in different modules in a bit and byte of the pieces, QA can find the problem in the integration of the components and system.

4) If QA is the product specialist then it will help the dev team to get the info quickly instead of waiting from the business team or product owner

bobsburnerbobsburner 272 bronze badges · Accepted Answer · 2019-07-25 12:31:10Z

To avoid restating what other answers have, this'll be brief.

Developers usually cost more than QA people for the same amount of their time.

QA and development can be done in parallel, if there's a separate team.

Reporting defects in a way that's informative, and can be reproduced, is a skill in itself. Many developers are not skilled at this.

When testing/debugging your own software, you have an idea of how it works internally. The target user does not. This makes self-testing a little unrealistic, especially for defects in the documentation.

Most good QA people I know are more expensive then the developers they work with. You would expect good developers are better at reporting defects, because they know which information they need to fix it. The you cannot test your own work is such an old-fashioned argument. — Jul 25 at 14:22
Old-fashoned in what way? I meant that your mindset, and approach are different when defect-checking something you made. Developers knowing how to fix something, and explaining/documenting that are different things. (IME, programming skills and communication skills are inversely correlated in people) — Jul 25 at 14:32

o.m.o.m. 2961 silver badge4 bronze badges · Accepted Answer · 2019-07-26 10:58:38Z

For your team size, a dedicated QA member is probably not appropriate.

Doing the various aspects of QA well requires the proper skills, and in a sufficiently large team it might make sense to have specialists. But with just three "IT guys," counting the two devs and one tester, this isn't the case.

If you have dedicated QA, you need a "senior QA guy" who can talk to "senior devs" and "senior architects" as a peer when it comes to budgets, timetables. and priorities. That's not just a job title, it is also a question of pay scales and influence within the company structure. A lone tester is just a tester, not a certified test manager or department head or whatever.
- This becomes especially relevant if you want the QA to check on the work of the devs. That means you are creating a somewhat adversarial situation. Then the QA cannot report to the dev manager, it must be a direct report to someone higher up in the chain.

If you tell one out of three that he or she "is the QA part of the team," then you tell the other two that they're not. They will test less and deliver more badly-tested code instead. And if the lone tester has a vacation or a sick day, you have a problem.

I believe that test automation is a job for the devs on the team, possibly in cooperation with the test analyst if you have such a specialist. Having the devs also do the manual testing is a great incentive to automate what can be automated, instead of ignoring it as other people's problem.

c1ph4c1ph4 63 bronze badges · Accepted Answer · 2019-08-01 16:38:48Z

If you're doing serious business in IT I think it's better to let your code check from a specialist in the QA field. Otherwise you risk delivering broken software to your clients which will result in a negative feedback loop (deliver bad software -> anger your clients -> you get less new clients -> you deliver bad software -> ...).

Plus, if you're using SCRUM as project management when developing your software, there is no QA tester role anymore. Testers are just part of the dev team and regarded as such (which in IMHO is very good and just logical). This should be a standard but it'll take some time for the industry to get to this point.

Yeah, and of course there is this "devs build, testers break things" thing. :-)

Kate Paulk♦Kate Paulk 25.8k6 gold badges43 silver badges90 bronze badges · Accepted Answer · 2019-07-24 12:06:15Z

First I would rephrase your reasons:

Testing being done by developers is good at the unit test level. A dedicated QA is likely to have more skill in finding and exploiting situations the developers didn't realize could be problematic (but customers can and will find).

A skilled QA will quickly gain knowledge of the entire application domain and then apply it to find situations that the developers with their deep but narrow expertise (which is necessary) can miss.

A dedicated QA who has chosen that as a career actually wants to do it, and be good at it. (I wouldn't change this at all - but I would add that it's not rare for developers to resent the need to constantly test and retest when they'd rather be coding).

A skilled QA may have knowledge of writing automated tests.

A few other reasons you can add:

The person who wrote the code is often blind to its limitations because they are too familiar with it. Skilled testers know how to work to avoid allowing familiarity to blind them to problems.

Skilled testers will deliberately do the wrong thing with the software. This can expose major problems developers would not think to test (personally, I've lost track of the number of times I've been able to force software into a state developers would have thought could never happen).

Skilled testers will try to find and test every way to use the feature being tested. They won't find all of them, but that's only because every sufficiently complex piece of software has an infinite number of paths through it. I once tracked down a problem that only occurred at the end of something more than 50 steps.

Skilled testers can help developers choose useful scenarios to automate in unit tests or other automated tests.

Skilled testers can find problems with requirements documents and/or user stories before coding starts, saving time and money by avoiding rework.

If you're having to make an argument to management, you will want to focus on time/money savings. To do this you will need to do some digging into whatever tool you use to report issues and note the proportion of them (preferably an average over a specific time period) that you think would have been caught prior to release if you'd had a dedicated tester. If you have any numbers relating to the amount of time it took to fix those problems (again, an average per quarter or per month works), use them, and compare against the time that your team needed to fix problems that you found before you released. You can then make the argument that the difference is time your team could have been working on new functionality which is more profitable for the company than bug fixing.

You touched on it, but maybe you want to add this angle specifically as it may speak to management's view: Being good at developing takes time and "brain capacity" and thus money. The same holds for testing. The skills are separate and most people can improve in either areas for all of their professional life. Time spent by developers trying to get better at testing isn't time spent developing or getting better at developing. Hiring a QA person means they already have the skills and instead of wasting money (time = money) on developers learning how to test, you save that money. — Jul 24 at 20:00
To me the #1 reason is the problem of the developer being blind to the errors because he sees the code he wanted to write, not the code he wrote. — Jul 24 at 22:30
I'd put a little more emphasis on the If you're having to make an argument to management, you will want to focus on time/money savings. part. If management is not technical at all, they may just hear "we want you to hire someone who will do part of our job for us* — Jul 25 at 4:32
+1, but here is one more crucial one: QA is a separate set of eyes (and mind) reading the specs and flushing out unsaid assumptions - which might be different from what developer assumed. — Jul 26 at 18:15

score 13 · Accepted Answer · 2019-07-25 08:02:39Z

13

There is also a different mindset that a tester (or a dedicated QA) would bring to the team: developer "builds things", tester "breaks things".
(When speaking of a "break things" mindset: Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.)

A tester is dedicated to finding out new information about the thing they are testing, information that might be hidden from everyone (including the developers that made the thing) until it is subjected to a test.

edited Jul 25 at 8:02

answered Jul 24 at 11:33

Mate Mrše

5923 silver badges26 bronze badges

4

This is a very common misconception, that can quickly fall apart with some thought. Testers didn't write It so they didn't break It, they tend to not change the program/code they are testing. So there's quite no way to break anything. Unlike a physical object that can be broken by dropping it or using it in an unexpected way, software can only be broken by those who created it. Testers just find places that are broken and report them. Sometimes, it isn't even actual breakage so much as something that doesn't work the way customers expect or want it to work.

– Mobile QA
Jul 24 at 17:50

1

@MobileQA one could argue that little Bobby D. Tables actually broke the database. It stopped functioning in an case. I think a good tester will go beyond just finding broken things. At the very least I'd expect them to find things that might be working, but are unsafe in the sense they won't resist abuse, whether naive or intentional. This is different from most developers that focus on the happy path (can I achieve specs if I use my code properly, knowing exactly how it works) and don't necessarily attack the specs either.

– ptyx
Jul 24 at 22:58

1

@MobileQA I was speaking more of a "break things" mindset. Of course, no one is trying to literally break the software, it is just about approaching it from another perspective.

– Mate Mrše
Jul 25 at 6:37

2

Unfortunately though, the "breaking things" way of describing a tester's perspective has a bad tendency of leading to even more illogical words and behaviors. For example, "We could ship this faster if those testers would stop breaking everything." We break assumptions, or as Michael Bolton often says, "We break illusions about the software". That is our mindset, but if we aren't clear in the way we discuss it, people can easily fall into illogical blame games, "shooting the messenger", etc., etc.

– c32hedge
Jul 25 at 17:16

4

Also see developsense.com/blog/2015/02/… for Michael Bolton's much better explanation than I could put in a comment :)

– c32hedge
Jul 25 at 17:17

|
show 3 more comments

CherreeCherree 1,1246 silver badges10 bronze badges · Accepted Answer · 2019-07-24 14:56:05Z

Like many of the other roles (particularly in smaller teams) a dedicated person performing that role probably isn't actually necessary and may even be a point of inefficiency in some situations. That said just like with any other specialization in software development, having expertise, interest, and dedicated time to focus on a particular problem area will often enable the dedicated person to either bring their experience to bear on the problem or add insight when coaching their team to take on this mindset or the activities as part of their work.

Many development teams where I work are experimenting with either no-QA models or using QA much in the same way you might an agile coach. There's a lot of value to be added when you encourage a team to follow practices that result in higher quality outcomes whether or not you're doing testing yourself.

Curt J. SampsonCurt J. Sampson 1713 bronze badges · Accepted Answer · 2019-07-25 04:11:53Z

I'm going to take a slightly different focus on this question; my
answer is: A dedicated QA team member isn't necessary, but a
dedicated QA role is a good idea.

Consider a situation where you have a dedicated QA team member but he
does a poor job (or doesn't do his job at all). In this case, you've
got a particular solution in place, but the problem isn't being
solved. You would need to move "up a level" and focus on the actual
problem, rather than the details of a particular attempted solution.

Good QA is indeed extremely beneficial. If the problem is that you
feel in your current project that you don't have good enough QA, you
(and especially your management) should look at both how you might
move some resources from elsewhere to QA and how you might add
additional resources to the project for doing QA. Adding a dedicated
QA person to the team is certainly one way of doing the latter, but
not the only way.

Here are some other solutions you could consider:

Set aside one or two days a week for an existing developer
(probably the one who's most interested in QA) to work specifically
on that, rather than on developing new features.

Hire a new developer with a lot of expertise in QA, and have him do
the above for part of the week and development for the rest of the
week.

Hire a QA person who's learned a bit about development and is
interested in learning more, have him spend some time on QA and
some time on development. (Ensure you allocate some time and
resources to training him in development!)

Bring an expert from elsewhere your organization into the project
part-time to work on QA, especially on training full-time members
of your project in QA.

You may choose to use a mix of these solutions over time, and move
"focus on QA" around the time over time as well.

There are two advantages to these sorts of solutions:

You have more flexibility in terms of resources because you don't
have a certain amount of work hours that can be used for QA only
and isn't useful elsewhere. Being able to devote a "fraction" of a
person to QA means that your manager doesn't have to face the
decision of "I need to spend a lot or nothing at all," and risk
ending up with the latter.

The QA knowledge tends to spread through the team, rather than
being concentrated in one place, both reducing the bus factor and,
more importantly, ensuring that developers are writing code and
developing systems designed to support QA processes, rather than
hinder them.

Regardless of who's doing it, during the time someone is focusing on
QA he should not be thinking just "today I do manual tests of the
system rather than coding," but "today I'm focusing on where we have
quality issues and what we can change throughout the development
process to mitigate these." This could include:

Studying QA to improve her skills at it, testing and trying out QA
tools, and so on.

Developing tools and systems to help automate tests, at any level
(unit to customer acceptance).

Analyzing current and past QA issues, and figuring out the most
effective place to change systems to mitigate those issues. This
could range from changing something developers are doing to
changing part of the release process.

Training other developers in QA viewpoint and process, so that they
tend to produce fewer problems for QA to catch and make systems
where QA problems are easier to catch.

What I describe here is really a specific use of a more general agile
principle that applies to DBAs, release engineers and all similar
roles: everyone involved with the development team is a "developer"
and should be allowed, even encouraged, to learn more about things
outside their area of specialization so they can contribute in
multiple ways to the project. (In other words, avoid "siloing." or
having someone involved with your development team who's not supposed
to work on development.) To do this you make specialists roles,
rather than people, so that the the QA specialist "puts on her QA hat"
rather than being "just the QA specialist."

To summarize: rather than making your dedicated QA, make it a role,
and have someone dedicate time to that role. It doesn't have to be a
lot of time (certainly not full time in a project with only two
developers), but you need to ensure you remove pressure to work on
anything else during the time dedicated to that role.

One further note, your issue that "No one person has the
responsibility of domain knowledge of all our UI and other systems"
also is bad, though that sounds to me as if it's a customer role
rather than a developer role. Agile has similar solutions for this,
too, though I won't get into them here.

TheLucklessTheLuckless 1212 bronze badges · Accepted Answer · 2019-07-24 15:43:15Z

Dedicated QA as a distinct element from the direct programmers achieves two critical things for software development:

It helps distance testing from coding, thereby reducing bias.
- Smart programmers don't make bugs, all programmers like to assume they're smart, therefore programmers don't make bugs... Combine this with deadlines that programmers are driven meet, and you have a very nasty snowballing cycle where lots of little things are "Overlooked" with the idea they'll be quietly fixed 'some time later'.

Keeping QA as independent from Programming helps reduce the temptation to gloss over QA because the manpower resources are 'needed for code'.
- By keeping a core team with a focus on QA as their primary job, they can maintain the freedom to actually test and explore the software, and dedicate time to long term QA development. When trying to have core programmers do the QA work along side development, then it is far easier to let the QA side slide and risk a snowballing nightmare.
- However even then it is far too easy to allow QA to fall into "Rubber Stamp Mode" if they are understaffed and not allowed enough time between code 'completion' and release. Understaffed and under-supported QA teams are also a road to the snowballing nightmare.

Beyond that a good QA serves as a check and balance process to both design and code. They help highlight issues earlier in the process, thereby saving a project time and money.

In my career I've seen half-hour meetings between QA and the Business Analyst team spot and help correct a flaw that would have accounted for months of development time.

score 2 · Accepted Answer · 2019-07-25 14:12:45Z

I would like to argue that a dedicated QA member is NOT necessary.

A very good developer is a also very good tester. Yes, you need to learn and practise switching between building, breaking and a user-centric mindset when validating that the software built works as expected.

The last four years I worked with three teams (of four developers) that had no dedicated testers. I functioned as their outside Testing Coach. They build better quality software then my current team which has three testers and three developers.

Keep in mind I am not against dedicated testers at all, but there are risks in handovers to dedicated QA-members. Mainly that quality is not a whole team approach. QA lags behind. Developer-QA issue ping-pong. Context switching. Crappy test automation. QA shortcuts under release time pressure.

There is some literature about this aswell, like in his book "The Clean Coder" Robert C. Martin writes:

QA should find nothing

Therefore, when you release your software you should expect QA to find
no problems. It is unprofessional in the extreme to purposely send
code that you know to be faulty to QA. And what code do you know to be
faulty? Any code you aren't certain about!

Alan and Brent discussed this on their podcast and came up with the following Modern Testing princible, which also suggest that dedicated testers might not have a future:

We expand testing abilities and knowhow across the team; understanding
that this may reduce (or eliminate) the need for a dedicated testing
specialist.

https://www.angryweasel.com/ABTesting/modern-testing-principles/

Niels, with respect I disagree with your point.This may be true for very mature organizations where Developers & testers are mostly on same level in both skills set but not in general mid to small size organizations where testers are not too technical and developers lack the domain knowledge and in general testing skills. — Jul 27 at 15:23
@VishalAggarwal Fine, I have this discussion all the time with people. You have to experience a good Agile team with 100% test automation and decision making based on data to be really convinced. Still I think you can teach developers and in mature organisation have no more testers at all. Development teams should practise technical excellence, testing is a big part of that, but i truly think you do not need a separate role for it, nor special skills: less.works/less/technical-excellence/index.html — Jul 27 at 18:00

AnandAnand 5244 silver badges16 bronze badges · Accepted Answer · 2019-07-26 11:15:04Z

As per my observation, the dedicated QA will help the below process:

1) QA can help the dev team to capture the different failure scenarios and breaking of the system.

2) If QA is a most senior person working with the junior dev team then he can guide the team to build the project or process.

3) Since dev team is working in different modules in a bit and byte of the pieces, QA can find the problem in the integration of the components and system.

4) If QA is the product specialist then it will help the dev team to get the info quickly instead of waiting from the business team or product owner

bobsburnerbobsburner 272 bronze badges · Accepted Answer · 2019-07-25 12:31:10Z

To avoid restating what other answers have, this'll be brief.

Developers usually cost more than QA people for the same amount of their time.

QA and development can be done in parallel, if there's a separate team.

Reporting defects in a way that's informative, and can be reproduced, is a skill in itself. Many developers are not skilled at this.

When testing/debugging your own software, you have an idea of how it works internally. The target user does not. This makes self-testing a little unrealistic, especially for defects in the documentation.

Most good QA people I know are more expensive then the developers they work with. You would expect good developers are better at reporting defects, because they know which information they need to fix it. The you cannot test your own work is such an old-fashioned argument. — Jul 25 at 14:22
Old-fashoned in what way? I meant that your mindset, and approach are different when defect-checking something you made. Developers knowing how to fix something, and explaining/documenting that are different things. (IME, programming skills and communication skills are inversely correlated in people) — Jul 25 at 14:32

o.m.o.m. 2961 silver badge4 bronze badges · Accepted Answer · 2019-07-26 10:58:38Z

For your team size, a dedicated QA member is probably not appropriate.

Doing the various aspects of QA well requires the proper skills, and in a sufficiently large team it might make sense to have specialists. But with just three "IT guys," counting the two devs and one tester, this isn't the case.

If you have dedicated QA, you need a "senior QA guy" who can talk to "senior devs" and "senior architects" as a peer when it comes to budgets, timetables. and priorities. That's not just a job title, it is also a question of pay scales and influence within the company structure. A lone tester is just a tester, not a certified test manager or department head or whatever.
- This becomes especially relevant if you want the QA to check on the work of the devs. That means you are creating a somewhat adversarial situation. Then the QA cannot report to the dev manager, it must be a direct report to someone higher up in the chain.

If you tell one out of three that he or she "is the QA part of the team," then you tell the other two that they're not. They will test less and deliver more badly-tested code instead. And if the lone tester has a vacation or a sick day, you have a problem.

I believe that test automation is a job for the devs on the team, possibly in cooperation with the test analyst if you have such a specialist. Having the devs also do the manual testing is a great incentive to automate what can be automated, instead of ignoring it as other people's problem.

c1ph4c1ph4 63 bronze badges · Accepted Answer · 2019-08-01 16:38:48Z

If you're doing serious business in IT I think it's better to let your code check from a specialist in the QA field. Otherwise you risk delivering broken software to your clients which will result in a negative feedback loop (deliver bad software -> anger your clients -> you get less new clients -> you deliver bad software -> ...).

Plus, if you're using SCRUM as project management when developing your software, there is no QA tester role anymore. Testers are just part of the dev team and regarded as such (which in IMHO is very good and just logical). This should be a standard but it'll take some time for the industry to get to this point.

Yeah, and of course there is this "devs build, testers break things" thing. :-)

搜尋此網誌

Ttdfjt

10 Answers
10

Your Answer

Post as a guest

10 Answers
10

10 Answers
10

Post as a guest

Popular posts from this blog

Grendel Contents Story Scholarship Depictions Notes References Navigation menu10.1093/notesj/gjn112Berserkeree

10 Answers 10

Your Answer

Sign up or log in

Post as a guest

Post as a guest

10 Answers 10

10 Answers 10

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Popular posts from this blog

Grendel Contents Story Scholarship Depictions Notes References Navigation menu10.1093/notesj/gjn112Berserkeree

10 Answers
10

10 Answers
10

10 Answers
10