I was just reading an interesting article about the continuing need for testers (link below). If you disregard industries where regulatory issues pretty much define the requirement for testing (Defence, Aviation, Energy for instance) the nature of the role and the day to day activities have definitely changed over the years, with a much greater emphasis on streamlining the development process these days. This inevitably means that changes will always be prevalent throughout any development organisation. Big gains in efficiency can be made through initiatives such as #DevOps and #ContinuousDelivery but the quality of the end product is still the most important consideration. #QA continues to improve product quality by getting involved in the whole process from beginning to end and can act as a stabilising force through these periods of change. And from my own experience, having experienced QA professionals working on software almost never results in a reduction of product quality.
Part one of my @NSTC14 blog, published on the Borland website here:
(Part 2 coming next week)
Many people find it difficult to create a good bug report, so I’ve assembled a few tips to creating clear, concise bug reports that will not be rejected by the development team. Some of them may seem obvious but I’ve seen many bug reports over the years that do not contain the information required to reproduce the problem, so firstly, I’ll start with the basics
- Before creating the bug report, talk to the developer responsible for the area in question – it could actually be intended behaviour, or that you were simply doing something wrong (in which case consider that there could be a usability bug).
- Include the name, release, and if appropriate, specific build of the product you are reporting the bug against.
- Make sure you are assigning the bug to the correct component – if the assignation is incorrect the bug could be delayed or even rejected.
- Ensure you include the platform, platform version, and information about any third party software that may be applicable (for example, browsers, compilers, linkers).
- If the bug is being reported as part of an existing regression test suite, include a link to the test case in your test management tool (in the case of a manual test), or source control location (automated tests)
Onto the bug report itself – always be sure to include a short descriptive summary, and then create a full description for how to recreate the problem. Most bug tracking tools demand this in any case. Create a step by step guide to recreating the bug. In the reproduction instructions:
- Bear in mind that the developer looking at the bug may not be the original coder.
- Also bear in mind that in some cases (particularly for low severity bugs) it may be some weeks or months until a developer is able to prioritise and fix your bug.
- The more relevant information you can include in the RPI, the more likely it is that the issue will be fixed.
- Clearly state what the issue is and what the expected resolution is. Do not include information irrelevant to the RPI.
- If there is more than one issue, create a separate bug report for each (even if they are related). Otherwise it’s possible one issue will be fixed and the other forgotten.
- Identify and state the severity and impact of the issue. This may involve the developer who can suggest a workaround. Any workaround suggested may reduce the impact of the issue and therefore the severity.
- Consider using screenshots and videos to demonstrate the issue. There are various tools available to do this, such as Wink and Jing. Windows snipping tool (available from Windows Vista onwards) is useful for capturing a section of the screen to your clipboard. Windows problem recorder can record a series of steps and create an html file containing screenshots. If you are using automated test tools, such as @Borland SilkTest, you can automatically create screenshots in case of failing conditions (See here). When the developer is diagnosing the issue this can be vital in helping them identify the root cause.