8 Common Excuses in Software Testing

Excuses are common in the workplace. They seem to be more common in tech companies. If they weren’t, Dilbert would have been out of print a long time ago. But excuses inside tech companies who don’t test their software? In that case, they can be something of an epidemic.

And what are some of those excuses? Here are a few we’ve heard over the years:

1. “It’s working fine on staging.” – Applications always seem to work differently on staging than they do in production, don’t they? This leads many companies to only test before a major launch. What changes can happen in the time an app goes from staging to the real-world? Anything and everything! Users can access the app on different browsers and operating systems, or in the case of mobile apps, they are likely to use an app on a variety of devices, carriers and in disperse locations. In other words, a lot can change from staging to production, so there’s no excuse for not testing “in the wild.”

2. “We didn’t have enough time to test.” – This excuse is common within companies that tend to view software development as an assembly-line process, with testing being the final stage or “last line of defense.” The problem here is that when projects fall behind – which they almost always do – testing is done hastily at best, or worse, not at all. Ideally, the testing team is involved throughout the entire SDLC, but that’s a topic for another day. By the way, if you’re a tester, and you find yourself in this situation, this is actually a very valid excuse, but I digress…

3. “It’s okay, we’re a startup.” – Being lean and agile (and likely resource constrained) doesn’t give you the excuse to skip testing. If anything, startups should be more concerned about testing and quality, as they are making first impressions and/or trying to disrupt an entire industry. Poor quality will help them achieve neither. In our view, startup status should never be used as an excuse for not testing properly.

4. “It’s in beta, users will find the bugs.” – If that’s your excuse, rest easy knowing that users will indeed find the bugs. But will they report them to you in an easy to understand bug report? Will they effectively communicate the severity, frequency and steps to re-produce? The answer to that question is probably “no.” We see many companies use beta as an excuse for poor quality and as a substitute for professional testing – don’t be one of them.

5. “We don’t have enough money.” – Lack of budget is certainly an excuse for not doing lots of things in the tech world. But if your company has made it all the way from ideation to development to launch, then chances are there are enough funds kicking around for at least some formal testing.

6. “We haven’t made any major changes.” - Many companies do a fine job of testing for a major launch, but fail to regression test new versions. Truth is, any code change – no matter how insignificant it might appear to be – can have a major impact on an application.

7. “I didn’t think hackers would target us.” – Just because you’re not a major banking institution or a government agency doesn’t mean you shouldn’t be testing the security of your software. The motives of hackers are changing every day, and it’s only a matter of time before they find a reason to target YOU.

8. “They’re using it wrong.” – When in doubt, blame the users :) As the saying goes, if a user can’t use it, then it doesn’t work. You might understand the application, but that’s not an excuse to forgo usability testing.

What excuses have you heard for a lack of testing? Be sure to let us know in the comment section.

Essential Guide to Mobile App Testing

Comments

  1. says

    This may be due to tedious manual testing which can be considerably reduced using a test automation tool. Of course manual testing provides more accuracy sometime but some factors like bug detection, database management, etc. can be easily executed using a test software.
    Test Automation Tool

  2. P. Fard says

    I am not sure why testers have to provide excuses. I think to get around this, defects should really be the responsibility of the entire team rather than only QA or testing team. Further, projects need to involve all the stakeholders early in the software release and have test cases developed as requirements are gathered and developers are developing code. This way as each module is completed by the development team, it can be easily tested by the testers or even better, it can be automated by the testing team. These automated tests will be used as regression suite of tests for subsequent releases. This will enforce a more frequent validation of the code. If after this effort, a defect is found in production, the entire team is responsible for it and not only the testers.

  3. Mihai Ionita says

    - “We missed the release date because we underestimated the risk of new technology. New technology generates new problems and needs more time needed to fix the problems.”
    - “How hard can it be?! The code is just being ported…”
    - “Lessons learned discussion is for the ‘weak’!”
    - “If it works on Windows, it works on Linux! (for a Java application)” – Later, on Linux the app did not even start!

  4. essian says

    Thanks @Mark Snyder. I like the concept that if people are prepared to pay more for something they will look after it better, it’s refreshingly human.

  5. Clare says

    I’ve heard many (some are variations on those mentioned above)

    -It doesn’t happen on my machine
    -I can’t replicate it
    -It’s a feature
    -Where there’s a lack of QA professionals (and my personal most disliked response) ‘Anyone can test’ – usually in a cross functional agile team

    The reason for me disliking the last one the most is that, although having worked in agile teams for the last 4-5 years and can therefore see the benefit of cross functional teams, the fundamental problem for me is that developers will always check their code meets the requirement-e.g. it does x, y, z. Testers will always ask ‘What if’, and naturally try to break it/try alternative routes through the item under test-it’s a different approach that, in my view cannot be taught

  6. Raghu says

    if we plan proper there is no excuses,
    may be above many thing people call them as excuses. I can say as that is truth,
    many project budget not good to for resources. and some cases not get the time required.

    I can say that if application working for all happy path scenarios then there is no harm.
    if application fail in the happy path cases then defiantly testing team must take responsibility.
    Some time it happen only specific case application fail that will not be reportable. if people call that is missed by testing team or development team will not looks good.

    it is not a blaming game. it is a team work so there is no place for excuses. all are responsible for application failure.

    this may be any case.

  7. Cyberience says

    My Friends, Strong user requirements are an Illusion of blame, something and someone to blame, Agile development fits more closely to developments, and having your QA team as part of the Agile cycle with what I call the Agile Triad, QA Meet user, User Meet Developer, Developer meet QA. and each cycle, will evolve the project to completion where all can accept the floors and compromises of a phase 1 release, and continue to what all agree is an acceptable final release when the budget tops or other project takes the priority, and at this stage, it is bug fixing stages where QA validate the Reported bugs, and pass to developers for Fixing or to Release management for future improvements. At which time, you might consider updating the specs. This is reality. don’t through all the marketing crap in with specs that don’t meet the reality of the problem to solve.
    Here is another reality check, All software that has ever kept to the Original Specifications, (SRS) has never reached final production or been on time.

  8. @Jag says

    Another excuse “just launch the feature in production, the developers have tested it.”. Then when QA test he feature they find blocking bug.

  9. Faisal says

    @ Raj –

    So what was the responsibility of developers? To code it so bad and held testers responsible for not finding all the garbage they produced? If we put all the responsibility on testers and let developers code as badly they can to achieve coding dead-lines, then testers will be busy in finding out bugs and making sure that the happy paths are correctly executed till the last day. They’ll never get a chance to execute alternate/complex scenarios and find out real-time issues.

    So Quality is everyone’s responsibility i.e. developers have to code it properly and unit test it using some well thought unit test cases then testers job will be to make sure everything is working fine by executing all sorts of scenarios.

  10. says

    Well,

    I hear about these excuses from many testers though they are not the reasons. One more baseless excuse is “developer did a very bad job” .. Well, it is the duty of the tseter to find all the bugs if it was not coded properly

  11. says

    That one above is really common, the developers use that to cover up for their laziness/lack of motivation and all the small but user friendly features are left for “Phase 2″ it’s happening to us as we develop our B2C online business platform…most annoying.
    Even though it’s been clearly agreed to in the development document.
    It’s like you have to give them infinite time or suffer a clunky & bugsy app…

  12. Dr. Tony Prensa, PMP says

    Another excuse I usually hear is “it is a missed requirement, we’ll include it in the next release”.

  13. Mark Snyder says

    Essian – That, sadly, is the difference between a tester and a Quality Assurance professional. Too many organizations want the latter, but are only willing to pay for the former. Oh by the way, those are also the same organizations that are also not willing to invest the time in putting together accurate requirements or documentation at an adequate level of detail for “testers” to successfully execute in a repeatable fashion.

  14. essian says

    We weren’t spoon fed a requirement that specified that scenario and we had neither the brains nor the balls to work it out for ourselves.

    The ethos is that we’re not responsible for testing the product, we’re responsible for testing the requirements.

    I just can’t understand how that approach can be considered acceptable or worth paying for. I’d be interested to hear others’ opinions on this….

  15. Pallavi says

    “The developers have tested the code enough… We don’t need testers to test the application!”

Leave a Reply

Your email address will not be published. Required fields are marked *