0

May be it seems an open question (or non-constructive according to stackoverflow standards) .... but I am asking if there's something rigid according to Software process standards addressing this topic ?

If there are one or more "Hard to find bugs" that need complex scenarios, extensive testing, very big or special data set to show up ... Is this the responsibility of the developer or the QA ?

  • 1
    There is no single "software process standard", there are numerous different processes for developing software. Much software is developed without any dedicated QA personnel at all. So there is no general answer. – JacquesB Sep 25 '16 at 8:25
  • 4
    The standard answer, which applies to most modern software development processes, is that software quality is the responsibility of everyone, including developer, QA, team leads or managers, business analysts, etc. The reasoning is that, if you take away that responsibility from any one participant, then it is possible for software defects to be introduced as a consequence of that. The proof should be considered self-evident to anyone who has done software development. (so, please don't say there's no general answer.) – rwong Sep 25 '16 at 8:42
  • 1
    Most hard to find bugs are non-issues. If it takes an intricate test scenario to make it occur, it is not likely to be a problem in real world scenarios. What is the question really? Whom to blame when such a bug does get back from the field? – Martin Maat Sep 25 '16 at 8:45
  • One question worth asking (in case of a hard-to-find bug), in addition to the "how likely to be a problem in real world scenario" (starting off with two assumptions, one without a determined attacker, another one with), is "what would be the worst possible impact from that bug". The two answers combined gives you an estimate of the risk of that bug. – rwong Sep 25 '16 at 8:55
  • 1
    see also: Responsibility to reproduce bugs – gnat Sep 25 '16 at 9:32
7

There is no single standard software development process with clear defined responsibility for everything:

  • On one side this is unfortunately, because it makes life harder. You have to organize everything in every project and agree on roles and responsibilities. If software is build for a customer, this could be part of the contract. And it will not always be so clear who is to blame for what, nor if there's anybody to blame at all.

  • On the other side, this is fortunate: every project is somewhat unique, and you have the freedom to organize things as best suits its needs, and experiment innovative approaches.

So who is to blame ?

  • The customer could blame the project manager
  • The project manager might blame the quality assurance guy for not having found it, or the developper for having worked carelessly
  • The quality assurance engineer could blame the customer because nobody told him about the real test scenario, or didn't provide representative test data. The customer might blame in return the quality assurance guy, because he never asked or he didn't check representativity of data. So quality engineer will finally blame software developper for his bad quality.
  • The software developer could blame the quality engineer because he didn't verify well enough. He could blame the architect or he analyst, for not having mentioned some specific circumstances (if he'd known, he would have prevent it from happening). The business analyst could blame the customer, and so on...
  • In the end, everybody could blame everybody else, and it'll be up to the judge to settle the case

But wait a moment.. judge ? case ? Well, ... I hope that before arriving to such an unsatisfying end all the parties will realize that they are on the same boat !

Quality is a shared responsibility. So in the end there's no use blaming each other. Everybody has to contribute to come to an acceptable outcome.

The only one who could be blamed in the end is the project manager. Because it's his responsibility to make people work together. And he/she should ensure that quality assurance is properly organized above and across the organizational boundaries. He has plenty of ways to do so, starting with the setup of the project life cycle (e.g. agile vs.waterfall), the organization of the stakeholders involvement, and the choice of the validation approach (e.g.TDD or traditional V-model validation), and facilitating team throughout the project.

  • was just about to post an answer along these lines. Who's responsible pretty much equates to Who can I blame for this disaster. bad just plain bad ! – Newtopian Oct 13 '16 at 14:26
3

If there are one or more "Hard to find bugs" that need complex scenarios, extensive testing, very big or special data set to show up ... Is this the responsibility of the developer or the QA ?

It is the responsibility of the whole software team.

  • Developers should test their own code, in order to deliver the highest quality code possible.
  • If you have a separate QA team, it is their job to find bugs that the developers were not aware of.

With respect to delivering bugs to the customer, it doesn't matter whether they are easy to find or hard to find. both groups are responsible.

0

As developer is on you to begin, to create clean, decoupled code that makes little chance for "hard" bugs.

Also, you are the one who created the program and you are the one who knows how it works and should know how to test. And you should include testing of every unit in the way that only the developer can know how to test every little piece.

So, I say the developer is the outmost responsible for everything that is in that code, and you should never rely on a tester to find your bugs.

That being said, when you add testers to the mix, their responsibility is to catch anything that the developer may have missed, but, as developer, you are still responsible, the QA team is there just for assurance, but no developer should rely on them.

So, bottom line, you as developer is responsible for each bug, and if you are a QA you are responsible for catching what the developer did miss.
If a lot of bugs passed to the production environment both sides should feel the acid of their responsibilities.

0

Different organizations view the roles of testers and developers differently. In general, a tester verifies that the system conforms to its specification and fulfils its requirements. A developer builds the system and performs maintenance.

Typically, a tester should not pass a finding to a developer without a reproducible description of how the system's behaviour differs from their expectations. Then there can be a discussion on the basis of that description whether this behaviour is a defect or actually by design, whether that design makes sense, whether it should be kept or changed. However, a tester only deals with the behaviour of the system. They don't judge between right/wrong behaviour, and do not deal with causes of that behaviour.

If there is a decision to fix the observed behaviour, a developer will have to track down the cause of this behaviour, for example by observing the program with a debugger or by analysing log files. While developers can use the source code, they do not usually have a QA mindset and training.

All of this means that while you can't find bugs without a developer, letting a developer hunt for a bug without a good idea of what to look for is probably a less-than-ideal use of resources. Ideally, a tester should have a go at it first. After all, the code itself may be perfect if the cause of the problem was during requirements analysis, or if the cause is in the developer's understanding of the problem domain. A developer might be “blind” to such causes.

So while testers bring unique skills and a valuable point of view, they may not have the ability to reproduce any reported behaviour. A developer probably has a better understanding of the system, may see possible circumstances that could hide the problem from a tester, or can help making the behaviour more easily reproducible. E.g. concurrency bugs are unlikely to be reproducible with a black-box approach, but can often be provoked with a well-placed sleep(1) in the code. If a tester feels they may be on to something but lack the knowledge or skills to pursue it successfully, they should obviously rope in others who do – including developers.

To summarize, the responsibility for reproducing some behaviour tends to lie with QA. Of course testers and developers should cooperate where necessary. A given organization may have formal or informal policies how this should be done, or even use a different definition for “tester” and “developer” roles.

protected by gnat Sep 26 '16 at 8:58

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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