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 ?
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 ?
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.
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.
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.
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.
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.
