Most Effective Ways to Do Acceptance Testing
Acceptance Test can be defined as a method of checking a previously well defined “contract” between the Client and the Developer. Acceptance tests are useful because they capture users requirement and provide an overview of how “done” a requirement is.
Focusing on acceptance criteria only is not an effective way of testing a requirement. Finding more bugs and improving the app will be limited. Testers need to test beyond the acceptance criteria and the reason is that, sometimes, acceptance criteria leave out some vital aspect of a system to be checked while testing.
My name is Fagbohungbe Oluwatobi and I have over 4 years’ experience in Software Testing. I will share with you some of the things I do or put into consideration while I test a system for acceptability.
Ask questions:
The first thing I look out for in a task/ticket is the acceptance criteria. I read the AC carefully and ensure I understand how to carry out the test before I begin my test, therefore, one should be able to clearly define and decide what should be tested, what the expected result should be, and what testing technique must be applied. When I have clearly figured out, it will boost my confidence.
User Interface:
Sometimes, picking tasks/tickets on test management tool like Jira does not include acceptance criteria that cover UI, neither will you see attached mockups. As a tester, I don’t leave out this aspect while testing as I always take into consideration the user interface of any screen I’m testing. Whether the task/ticket includes UI test or not, I always commit myself to testing UI. UI Test should be done on the different screen (mobile, IPad, Laptop, and Monitor) and operating systems (Android, Windows, iOS, Blackberry etc.) and the reason is that there are instances where a button or a UI design may appear differently on a different screen and OS.
Users Perspective:
As a tester, you must always test from the end users point of view. No task/ticket or requirement or acceptance criteria will tell you to test like an end user. This is one way to identify a good tester. They test like an end user and not as a product owner or developer. I always ask myself how will the end user interact with the requirement I am about to test.
Test to Break or Fail:
The primary reason for testing is not to move a task/ticket to “done” but to find bugs. Don’t stop your testing where the acceptance criteria stop. Take some steps further and test beyond what is required. Look for bugs within and outside the test acceptance criteria.
Suggestions and Improvements:
A good tester will always provide suggestions and improvement feedback. Even when acceptance criteria passes, still look for ways to improve the application under test and make it better.
Response Time:
Functional requirement test usually doesn’t request we test for app response time but this is another aspect I don’t leave out while testing. Even though there are tools like JMeter that carry out a performance test, I usually use my discretion to check for how fast an app respond to a click action. It is always important to also check the response time of an App under different networks such as WiFi, Edge, 3G, 4G etc.
Team Communication and Collaboration:
Testers need to understand that application under test is a combined effort of different stakeholders (PM’s, Developers, Testers etc.) and there should be constant collaboration with all these stakeholders. Collaboration shouldn’t stop at your department or team members close to you but must cut across all departments in your organization the application interacts with.
Keep reviewing:
You can’t have too much of a good thing. Just because certain testing methods have worked in the past doesn’t mean they always will. Testing can be better. I always look out for new tools and testing approaches that can improve what I currently have or do.
Report Bugs Immediately:
Reporting bugs immediately help PMs to prioritize tasks/tickets and assign them to a developer. It also speeds up the development process. Storing bugs on a notepad and then reporting them at your convenience is one out of many software testers bad habits to avoid. I report bugs immediately after I find one.
In conclusion, the most effective way of testing a requirement or ticket should involve different testing approaches and techniques. For example, when I pick up a task/ticket I always ask questions, put UI into consideration while testing, test from the end user perspective, put up a test to break mentality, suggest improvement and suggestions where applicable, look out for app response time, collaborate with the entire team, report bugs immediately and keep reviewing my testing process.
