November 08, 2016 8 Black Box Testing Techniques to Boost QA Success Rates Black box testing techniques offer development teams the opportunity to examine software without viewing the code. Our quality team shares best practices. Jeni Kyuchukova Black box testing techniques, also known as a type of behavioral testing, offer development teams the opportunity to examine software without necessitating a deep understanding of the code used to build it. The style of testing looks at the inputs and outputs of the software under test but does not examine the internal workings of the product. The code itself is treated as if it were hidden under a black box. By separating the user and developer perspectives, black box testing allows testers to more efficiently validate large bodies of code with a deep understanding of how it was built. Software testing: The complete guide Analyzing the current state of software testing and how teams must adapt. 1. Create Clear Bug Reports Good testers can be identified by their resolution rate. They 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 to boost black box testing techniques around bug reporting: Reproducibility – Inform the Developers How Often the Bug Appears Its frequency may impact the resolution priority. Reproducibility Definition 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. Severity – Identify the Scale of the Bug Severity Description 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. Summary – Describe the Bug in One Sentence Use this as a title for your report. Be descriptive and concise. What does the bug prevent users from doing? What risks will present if the bug is not addressed? Does the bug only present for groups with certain permission levels? These are the types of questions experienced testers ask. How are the needs of businesses testing software changing? Analyzing the current state of software testing and how teams must adapt. Bug Description – More Detail Leads to Rapid Resolution 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. Screenshots with comments and explanations. Firefox has one wonderful Add-on “FireShot”, this Add-on can be found also for Internet Explorer. Modern workforces are increasingly distributed. Especially in the technology sector, businesses work with clients or have coworkers in another country, or who speak another language in addition to the shared language. No matter how well you learn to understand a language, misunderstandings can arise leading to problems of all types. It helps to have a pre-planned method and agreed upon terminology to report bugs. How to lead a distributed development team Why businesses need remote Agile teams & questions to ask before starting. 2. Adopt the Mentality: There Must Be Bugs Start to test with the idea that there should be bugs. No system is perfect. This mindset will help you to be more focused and purposeful finding problems. 3. Don’t Just Test the “Happy Paths” Sometimes, due to a variety of reasons, users do not enter something as intended. They may press buttons out of order, or otherwise misuse the software. It is important to try to account for these situations in your test plan. 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. 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. 4. 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. Reporting unrealistic defects will only slow down the development process and frustrate the development team. 5. 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 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 do you avoid? Why? Usability is always the answer. 6. Keep Written Reports to Document Black Box Testing Techniques 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, they are forgotten and never fixed. This may lead to a production release annoying users. 7. Invest in a Cohesive 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 1) junior developers who have never worked with QAs or 2) 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. 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. 8. Always Seek to 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 the developers questions. For cosmetic issues, you can read and learn about HTML and CSS and report specific CSS styles/areas of a web page that should be fixed. 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. Using proxy tools like Charles and Fiddler can help you identify the root cause of a problem. With more working development knowledge, you will speed communication and efficiency of bug resolution. Approving a high-quality product is a complicated process. Learn from your mistakes and from the bugs you find. Maintain good communication with your coworkers, defend your position in a positive manner, keep learning and continue testing. Tags Quality AssuranceDevelopmentWeb Share Share on Facebook Share on LinkedIn Share on Twitter Share Share on Facebook Share on LinkedIn Share on Twitter