What is software testing?
Software testing is a process to evaluate the functionality of a software application to determine whether the developed software meets the specified requirements or not. Furthermore, it finds bugs to ensure delivering bug-free software.
Software testing can be done by manual or automated testing with appropriate approaches including black-box, white-box, or gray-box testing. Testing can be done on several levels like unit testing, integration testing, system testing, and user acceptance testing.
Software testing challenges
The complete testing to verify if the software meets all requirements might take a lot of effort, especially when it’s done without effective techniques. In this article, we’d like to share some effective techniques for software testing activities including analyzing test requirements, defining test cases, and reporting bugs found.
Analyzing test requirements
What is a test requirement? Why is it important? And how to analyze test requirements?
A test requirement is a statement of what should be tested in the Application Under Test (AUT). Without test requirements, it’s hard to tell your testing is complete, and the software meets all requirements.
Test requirement analysis is nothing but answering the question “What should be tested in detail?”. To answer this question systematically, it’s important to apply the following procedure to find all possible test requirements.
How to break down test requirements?
- Understand product documents or AUT.
- Break down the application to the smallest functionalities (Functional Breakdown Structure - FBS).
- For each smallest functionality, list out test requirements for the following types:
- Functional: At least 1 happy path test requirement.
- Look and Feel: At least 1 test requirement per screen.
- Boundary: Special and important input data that can cause problems to the AUT.
- Negative: Cases to verify the unintended behaviors of the AUT.
Let’s look at a typical example
If you are requested to test the below product list page of an e-commerce website like below. Applying the above steps, what would be your test requirements breakdown?
A good approach is to divide and conquer. You might want to break down the page into smaller components and then write test requirements for each component. Your breakdown may look like this.
Now, you can go on finding test requirements and organize them in a table with a hierarchy like below. It will help you verify if all functionalities are covered with your test requirements or not.
Use a spreadsheet to document these test requirements as it is the most flexible tool to create your testing traceability matrix.
Designing test cases
A test case is a single executable test that a tester carries out to verify a well-defined test requirement or test objective. You can think of a test case as a set of step-by-step instructions to check if something that performs as being expected.
A test case can be:
- Positive: To verify intended behaviors.
- Negative: To verify unintended behaviors.
- Combination: To verify system behaviors (could be intended or unintended) using complex (combined) test scenarios.
It usually contains:
- ID.
- Test case summary (Test objective).
- Test steps.
- Expected result.
Here are a few examples of test cases for the above Product list page.
Reporting bugs
Another important aspect of testing is to report bugs. A bug report should have a summary, description, steps to reproduce, expected result, observed result, and severity. A good bug report should have a clear and concise summary that developers can understand and know what to fix rather than reading the whole report.
Bug report elements
If you’re interested in writing a good bug report, here are some tips for your reference:
- Bug Summary:
- Follow this formula: [Observed result] + [Expected result] + [Steps] + [Location].
- Depending on the context of the bug, either the action or location can be omitted.
Take a look at this example: An error message displays when a user logins with a valid account at the Login page.
In this example, the problem is “An error message displays”, the step is “user logins with a valid account”, and the location is “the Login page”.
Another example: Help page instead of the Product Details page opens when clicking on the ‘Here’ link at the Welcome page.
- Bug description: There are specific rules to optimize the bug description:
- Describe the contrast between the expected and actual results.
- Describe the main steps to reproduce and emphasize bug impacts.
- With a complex bug, don’t forget to describe the OS, browser version, and use screenshots if needed.
Here is an example:
At the Product section of the Welcome page, when clicking on the ‘Here’ link, the Product Details Page should open. In this case, the Help Page opens unexpectedly.
- Steps to reproduce:
- Remember to write minimal steps to reproduce the bug. These minimal steps should contain test data, be numbered starting from 1, and provide pre-condition steps if any.
- Use verbs to tell what needs to be checked in the last step (observe, read, compare, listen, etc.).
See an example of good vs. bad steps:
- Expected results:
- Describe what should happen.
- Suggest possible solutions for fixing the bug if possible.
- List all possible behaviors.
- Avoid using ambiguous words like properly, correctly, clearly, etc.
- Observed results:
- Describe exactly what you see.
- Take screenshots or screencasts to better describe the observed results.
Here are a few examples of good and bad results description:
Tips to report bugs
To effectively report bugs, take notice of these useful tips as well:
- Don’t forget to explain both the bug symptoms and effects. For instance, “Nothing happens instead of a product is saved to the shopping cart when clicking the 'Buy Now' button on the Product details page. After that, the user can not check out any products”.
- Mention the exact environment where a bug occurs to avoid the developer’s wrong effort in reproducing. For instance, in the bug description, you can mention “This bug only happens on Windows 10 Pro - Firefox”.
- Focus on symptoms of the bug instead, if the bug summary has a limited length. For instance, “An error pop-up displays instead of a file is downloaded when clicking on the Download link on 'My Scoopons' page with Firefox browser” should be changed to “An error pop-up displays when trying to download the file”.
Conclusion
We hope that the above techniques will be useful for you in planning and executing your testing yet ensuring to pass the quality of software releases. From this, you will be able to sharpen your software testing skills quickly.
Thank you for your interest in our sharing!
