Suraj May 11, 2012, 00:25:33

On larger SW prjcoets the testers are often organized in a separate team. Reasons are:b7 Test bed can consist of expensive HW equipment, testing tools sometimes require expensive licenses. It would be too expensive to make all that equipment available to each (or most) of the developers. So, the test bed is centralised and used by several prjcoets.b7 Skills needed for setting the test bed and using test tools can differ from the skills that an average developer has. Therefore you are better off with a skilled testing team.b7 Developers tend to be subjective towards their own code. It is good to get an independent view from a tester.b7 Developers are usually familiar only with their part of SW and sometimes the parts that directly interact with it. So they can write unit tests for their code and sometimes even make some integration tests, but that’s it. You also need complete integration tests (especially if you have a system which involves several servers, clients etc.) , performance tests, reliability tests and long-run tests. Developers usually have no time, knowledge and resources to execute this kind of tests.Testing is usually done on a release e.g. on a weekly or monthly basis (or when a project manager decides to start a testing cycle). I am not refering to usual unit tests that are done regularly by the developers. To broaden this view, customers can also be viewed as testers and they need to have a way to register the issues they found.Having the above in mind, I would like to comment your views on issue management system:b7 bbTo prove you have tested the application?ab Yes, partially use the bug tracking system to automatically create a part of test report (e.g. create a list of solved and unresolved issues). This would inform all involved parties about issues that were tested and what are the results. It is not only the tester and the developer that need to know what is going on, as you suggested.b7 bbTo remember the issue for later resolution?ab Yes. It can happen that you (as a developer) get several issue requests in a single day and you simply can not deal with all of them at once. And again, it is not only the tester and a developer that need to know about an issue. Also the customers can see that some issue is already known (and maybe planned for a solution) which can significantly diminish the time they spend about the issue (see the example below).b7 bbNo, when the issue resolution can wait is not important and you do not have to register it. This is not an issue but a feature request.ab I think it is Ok to use the same system for bugs AND for feature requests. Somebody else (e.g. a customer, a product manager etc.) can also decide how important an issue really is and if it should be marked as a bug or a feature request. So, as a tester, you should also register issues that you think have lower priority.b7 bbTo create release notes? No, release notes should contain a list of new or changed functionality and instructions for usage. Not a list of resolved issues. The readers of the release notes are not interested in specific bugs. They want to know if the new functionality is included. They expect issues from the previous release to be resolved.ab Well, sometimes the readers need to know which bugs were solved. How can you expect that all issues are solved with a new release? E.g. we had an issue with a piece of Java code. At the beginning it was not clear if the problem is in our code or some 3rd party library we used or in JVM itself. Pretty soon we found that issue described in Java SE issue tracking system and stopped working on the issue. In one of the next releases the issue was solved and we could see that in the release notes. In fact, I think that most of the popular libraries, frameworks and platforms have a lot of known issues and in lots of cases they are not solved in the next release.b7 bbThea0resolution of the buga0willa0alsoa0include a unit test .a0This testa0willa0faila0when thea0problema0occurs thea0second time.ab This is true only for the bugs that can be tested with a unit test. That is not always the case.To conclude: I think it is better to fix without tracking all the bugs that are found by the developers (or by the testers that are closely connected to the development team), especially if the functionality has not yet been released to customers. In other cases it is better to track also. Without an issue management system all you have is e-mail, excel sheets or post-it memos. Which, in my experience, don’t work for larger prjcoets.a0