Top 10 Acceptance Testing Strategies Which Lead To Failures


3 m read


Functional Testing, Mobile Application Testing, Usability Testing

failure and successSo here is a top 10 failing reasons list given to your attention.

  1. Absence of collaboration. The discussion of the requirements at some point may be even more important that the tests themselves. Lots of input has to be provided by all the involved, whether they are the business people, management, testers, etc. Everybody needs to do his part in order for everyone to succeed. Otherwise you may be dealing with consequences of the so called ‘telephone game’. The rules of it are built in a way that nobody wins. Such examples as: developers who are writing acceptance tests on their own, testers are expected to handle like everything AT-related, business people are dictating tests with no feedback whatsoever. Ideas of managing the issue: making special specification workshops, collaborative work on specifications.
  2. Focusing on the ‘how’ without the ‘what’. Specifications have to be both clear and understandable. An often occasion are test describing how the issue should be fixed, rather than describing the issue itself. Such attitude leads to case duplication, confusion, etc. Such cases are of an extremely low level and value. They are also hard in long term maintenance.
  3. Tests that can not be used as live documentation. Agile Acceptance Testing tends to be full of benefits. The largest of them is that a readable for humans specification of the whole system is being constructed. Thus the specifications are being automated to a huge degree and we are confident in its synchronization with the code. Thus solving the huge ‘trust only the running code’ issue. And all these bonuses can be compromised if documentation is not used as live.
  4. Acceptance tests are in no way a complete regression suite. AT are basically an explanation of the things the system can or can not do. If one is specifying way too much and is trying to cover all the edges possible such an activity may lead to difficulties in the understandability of the cases and an effect very similar to the so called  ‘paralysis by analysis’.
  5. Focus on tools. Teams need to be focusing on business specifications and finding appropriate tools only afterward. The tool has to be chosen for the job, not vice versa. Everybody has their favorite tools that are capable of covering much, yet no tool is perfect. Never forget that.
  6. Forgetting the fact that AT is a value added activity. AT is not exactly QA. It’s more about specifications and understanding the ‘what has to be done’ part. Teams that are giving Acceptance Testing a big QA part are often assigning it to junior specialists which is wrong in dozens of cases. Don’t do that.
  7. Improper maintenance of the test Code. Tests themselves and the code used to automate them is often underestimated and considered to be of less value then the development code. Thus less specialists are given for the entire process. Such lack of people may lead to devastating results like complete abandoning of entire full suits of tests.
  8. Team members as well as objectives are not lined up. This one is more of a management issue. Yet it is of high importance. If business analysts will only deliver specifications, the developers will only be shipping the system and the testers will only be busy ensuring quality everybody will be going their separate ways and less team effort will be but in releasing a fine quality product.
  9. Absence of management buy-in. If you want the AT to succeed the business has to take active participation.
  10. Understanding of the skills required to succeed.  A software testing team can not consist of just everybody willing. Introduction of Acceptance Testing often is requiring drastic changes in the current flow of things and the approach to specifications. Lots has to be invested in software testing master classes and trainings for the entire team. The proper tools need to be mastered, the resistance to changes has to be managed. Your team needs to be prepared.
Ensure the smooth functionality of your software projects by hiring experienced and highly qualified QA engineers and software testers. Get in touch below.


We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy