Define operating and testing environments
It is very important to define which operating systems and on which browsers the application should be tested. Once you define the browsers on which the system should work, make sure you check all functionality on all browsers. If there is not enough time/budget, you can check the design and the main functionalities of the site with all browsers. Most of the cosmetic problems generally appear in Internet Explorer 6.0. We like to use IETester (http://www.my-debugbar.com/wiki/IETester/HomePage), the application supports all Internet Explorer versions.
For comparing the design of a site on different browsers, there is one tool named Adobe BrowserLab that works great. With it you can compare a web page in one browser next to a page in another browser or overlay the pages entirely. The tool supports the following browsers:
- Chrome 3.0 – Windows
- Firefox 2.0 – OS X
- Firefox 2.0 – windows
- Firefox 3.0 – OS X
- Firefox 3.0 – Windows
- Firefox 3.6 – OS X
- Firefox 3.6 – Windows
- Internet Explorer 6.0
- Internet Explorer 7.0
- Internet Explorer 8.0
- Safari 3.0 – OS. X
- Safari 4.0 – OS X
Make sure that your bug reports are easy to understand
The best testers have the most bug reports resolved. A good bug report is one that assists in resolving an issue. Ensure that your bug reports can easily be reproduced by making them as clear and concise as possible. Here are several steps that you can follow:
1. Reproducibility – inform the developers how often the bug appears
|Always||The defect appears at all times.|
|Sometimes||The defect does not appear every time.|
|Random||The defect occurs sporadically.|
|Not reproducible||The defect cannot be reproduced again.|
2. Severity – inform the developers of the scale of the bug.
|Block||When a bug stops the user from working with some aspect of the system. These bugs have the highest priority.|
|Crash||When an error page appears. Sometimes this happens when the developers forget instances of the system.|
|Major||When a bug has a major impact on the functionality of a large aspect of the software.|
|Minor||When a bug causes major harm to some piece of functionality, but does not impact many aspects of the software.|
|Tweak||There is no problem with the feature, but the way it is working should be slightly changed (tweaked).|
|Text||A problem with the text and/or labels of the software. Usually typing mistakes or labels that don’t match the specifications.|
|Feature||This is a new feature that should be implemented, in most cases it is not a bug. The tester can be asked to add such a report in order to inform the developers about a new feature that should be added to the software.|
3. Summary – summarize the bug with one sentence – as a title for your report. Be descriptive and concise.
4. Bug Description – this is the most important section.
Be sure to include:
- Location of bug in the software
- URL (if you are testing web pages)
- Testing browsers or environment
- Information about the bug – here you need to explain the input data you used and the sequence of steps you made to cause the bug. This point is quite important make sure that your instructions are clear and reproducible. Make sure that you use the same terminology as the developers.
- Screen shots with comments and explanations. Firefox has one wonderful Add-on “FireShot”, this Add-on can be found also for Internet Explorer.
These days, more and more people in the IT business work with clients or have coworkers that are not from their own country and who communicate in another language. No matter how well you learn to understand a language, there still can be misunderstandings that can lead to problems of all types. It helps to have a pre-planned method and agreed terminology to report bugs.
There must be bugs
Start to test with the idea that there should be bugs. There is not a system that does not have a few errors. This mindset will help you to be more focused on finding problems.
Test situations that should not be executed
Sometimes, due to a variety of reasons, users do not enter something as they are intended to, press buttons out of order, or otherwise misuse the software. It is important to try to account for these situations.
If you have a registration form to test, try doing things OTHER than fill out the form. It was built to accept data, so try not entering anything and pressing the button for registration, enter invalid data such as email that does not have the “@” symbol or very long zip code or name. Use boundary cases (inputs at or just beyond maximum and minimum limits) to attempt to receive errors. There are symbols that can break the database or break the request from the database if they are entered and saved in the system. Such examples are the percentage (%) symbol, inverted commas(“”), and two minuses (--) together.
If you have a combination of actions that need to be done one after another, change their sequence. Make sure that you have checked all situations that you can think of, according to the system you test.
Test real situations
The above tips should not turn the QA process into a highly critical and aggressive testing period. Do not test and report bugs for unrealistic situations. Make sure you have understood the specification for the application and do not tease the developers with unrealistic bugs.
Test like you are a regular user, a computer illiterate user.
Think about the users, question yourself. Is this system user friendly? Can you easily navigate the program? Is the text within the system clear and understandable? Are the error messages helpful? There are a lot of examples in your own personal life. Think about when you sit at home on your personal computer - which sites or programs do you prefer? Why? Which you do not like? Why? Usability is always the answer.
Keep written reports
Sometimes bugs are shared verbally with the developers. This can work against you. Make sure that you keep written documentation of all your discussions about issues or anything concerning a project. The best practice is to have reports on every issue you find. Sometimes when communicating bugs verbally, many testers complain that the developers take the credit for their work or that managers who calculate the productivity of a tester by the number of bugs he/she reports do not give full credit.
Work to become a Team
Communication with your team members is just as important as knowing good techniques for testing and is key for the successful achievement of a quality product. You need to be flexible. During your work you will meet junior developers that have never worked with testers or people who will disagree with your findings. Some developers just need to get used the fact that they have bugs in their programs. This is normal. You need to persuade them that a tester for a developer is not like a critic for an author. Help them understand that you are a team and you both want the same thing. Prove your statement with facts and knowledge of the system and specifications.
Gain new knowledge
Black box testing uses external descriptions of the software with no knowledge about the internal structure. If you want to become competitive and help further your career, you should take a peak at the source code and ask questions of the developers. For cosmetic issues, you can read and learn about HTML and CSS and report specific CSS styles/areas of a web page that need fixing. Some tools that can help are the Web Developer Toolbar and the Firefox Add-on, Firebug. Some knowledge about Databases also will be helpful, this way you can more clearly understand the processes in the system and the reasons why some bugs appear. With more knowledge of how the software works, you will speed up the developer's work and make yourself more efficient in the process.
Approving a high quality product is a hard and complicated process. Learn from your mistakes and from the bugs you found. Keep good communication with your coworkers, defend your position in a positive manner, keep learning, and continue testing.