Writing Bug Reports!!!

Writing Bug Reports!!!

================
I would like share couple points on writing bug reports with you all.
Bug Reports that say nothing ("It doesn't work!"); reports that make no sense; reports that don't give enough information; reports that give wrong information. Reports of problems that turn out to be user error; reports of problems that turn out to be the fault of somebody else's program; reports of problems that turn out to be network failures.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You can either show them in person, or give them careful and detailed instructions on how to make it fail. If they can make it fail, they will try to gather extra information until they know the cause. If they can't make it fail, they will have to ask you to gather that information for them.
In bug reports, try to make very clear what are actual facts ("I was at the computer and this happened") and what are speculations ("I think the problem might be this"). Leave out speculations if you want to, but don't leave out facts.
When you report a bug, you are doing so because you want the bug fixed. There is no point in swearing at the programmer or being deliberately unhelpful: it may be their fault and your problem, and you might be right to be angry with them, but the bug will get fixed faster if you help them by supplying all the information they need.

So remember below points while writing bug reports!!!

Logging Bugs:Few points to remember:

============================
1. Clearly mention repro steps (step by step don't assume anything) Give test data effectively
2. Actual Result/ Expected result: Divide into points rather than big sentences. Instead of only telling about the issue, stress on the impact it has caused or do some analysis and mention the root cause of the issue (as applicable), this is where we can do Value Addition.
3. Try to provide snapshots/video where ever applicable and mention file/folder name in repro steps.
4. Check spell before saving your message.
5. Don't use short cuts words in repro steps ex: Pls for please.. Immly for Immediately...
6. Don’t log bugs with multiple issues unless they are inter-related and caused because of one thing.
7. Don’t ignore as small issues, log them as low priority bugs, its upto them to fix/ not
8. If you are seeing any inconsistent issues, don’t neglect it, spend some time to find consistent repro. Still you can file bugs giving different scenarios where it likely repros
9. If you see any major issues on your machine, PLEASE check on some other machine as well, before logging it OR Send a mail to team ( If you get any such mails PLEASE try it out without fail (if not immly, at least some time before EOD) and send-in your observations. Confirm even if its not repro to you)
10. If you are not sure whether it’s a bug/ By Design, don’t keep with your self, and bring to my notice.

Check list when bug/s are fixed:

=======================
Few points to remember
Read whole bug ( all the comments in Scope, Attached mail threads if any, relevant linked bugs) and not just the Repro Steps and see all the issues mentioned/discussed are fixed
If the fix is 100%, close the message.
If it caused any new issues ( which are minor) , close it – log new messages for other issues.
If the fix caused major regressions, activate/reopen this one by clearly mentioning the impact of this fix.

Re-activating bug/s:

===============
1.Only in case of (Cross check on second machine, before re-activating any messages.)
A. If it fails directly as per the Repro steps
B. If it causes major regressions
2. But try to provide any extra info than given in the bug for better understanding to the Dev/ PM

3.If multiple issues are mentioned in the bug and if it fixed ONLY some issues , close this & open a new bug for the outstanding issue(s)

Link for more info:

=============
http://java.sun.com/developer/technicalArticles/bugreport_howto/

From
Subhash

Debugging using IE Developer Toolbar.

The Microsoft Internet Explorer Developer Toolbar provides a variety of tools for quickly creating, understanding, and troubleshooting Web pages. Down load Beta 2 Preview version from below link

http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

Note: Internet Explorer Developer Toolbar requires Internet Explorer 6.0 or later.

Overview
The Internet Explorer Developer Toolbar provides several features for exploring and understanding Web pages. These features enable you to:--

--Explore and modify the document object model (DOM) of a Web page.
--Locate and select specific elements on a Web page through a variety of techniques.
--Selectively disable Internet Explorer settings.
--View HTML object class names, ID's, and details such as link paths, tab index values, and
access keys.
-- Outline tables, table cells, images, or selected tags.
-- Validate HTML, CSS, WAI, and RSS Web feed links.
-- Display image dimensions, file sizes, path information, and alternate (ALT) text.
-- Immediately resize the browser window to a new resolution.
-- Selectively clear the browser cache and saved cookies. Choose from all objects or those
associated with a given domain.
-- Choose direct links to W3C specification references, the Internet Explorer team weblog (blog),
and other resources.
-- Display a fully featured design ruler to help accurately align and measure objects on your
pages. The Developer Toolbar can be pinned to the Internet Explorer browser window or
floated separately.

Automation testing tools…. comparative study

Introduction:

Automating testing GUI based applications entails carrying out few or all of the following tests (Web tests, Database tests, Image tests, Integration tests and Object tests) depending on their relevance.

This necessarily requires tools with abilities to record and playback, allow for data functions, recovering from errors, have facility to map objects, have an extensible language (with environment support) and above all – be easy to use.

Features Comparison:

It isn’t easy to recommend any ONE tool as the selection will have to be backed by a thorough understanding of the task at hand as well as other constraints such as cost, schedule etc. Apart from the technical abilities that need to be evaluated, the purchase decision must also be evaluated in terms of the long-term purpose it could serve. Following factors could be considered before reaching such a decision.

1) Price – If price is a constraint, then we have found that Visual Test, Robot and QARun tend to be at the more economic end of the scale. Apart from Visual Test, the other two are comparable to Silk and Win Runner in most areas.

2) Integrated with development environment – If price is not an issue and you want a comprehensive package that may require linking to development tools then Compuware and Rational may be preferred.

3) Web testing – for web testing we would tend to evaluate Win Runner (or QTP), Silk Test and Robot first in that order.

4) Regression testing – If the purpose of automation is also to assist with regression testing at a later stage, you will be creating huge regression packs for several projects possibly on various platforms. We would look at Silk Test, Win Runner and QARun in that order as these tools have superior facilities for maintaining scripts in the GUI MAP or similar facilities as well as baseline recovery systems. As

5) Customer Support – If you are going to require a lot of professional services support or helpdesk support then Mercury and Compuware are preferable choices.


Tool’s strengths and weaknesses:

Rational:
Strength: - Economical, Lots of supporting tools, good extensible language through VB, good data creation facilities, good online community.
Weakness: - Customer Support, language is a little basic and a bit confusing with tools breakdown e.g. Visual Test, Team Test, Test studio, Test Factory, etc.

Mercury:
Strength: - Possibly the most popular test tool, skill set available in plenty, good support, good online community, Good cross browser support.
Weakness: High cost.

Compuware:
Strength: - Strong professional services, good integration with development products, Economical.
Weakness: - Poor online community, Product breakdown

Segue:
Strength: - Good development language, good online community, recovery system.
Weakness: - Helpdesk, High cost.


Conclusion:

So which tool is best?

Well the winner is
1. Visual test
2. Robot
3. Win runner (or QTP)
NOTE: Quick test pro is easier to use and implement for both technical and non-technical testers in comparison to Win runner. QTP offers many features that are found in win runner, but are easier to use and QTP is economical.
4. Silk test
5. QA Run.

*** Test complete automation tool: is another option if cost is a big issue

An ideal tool should have the following characteristics:

1. As cheap as Visual Test,
2. Good data creation facilities as Robot,
3. Good cross browser and wizardry as Win Runner or QTP.
4. Flexible and powerful language as Silk Test and
5. A central repository and text facilities as QA Run.

------------------------------------ 0 ----------------------------------------