9 October 2017

4 symptoms of bad software testing that will kill your digital transformation

Share

Digital tranformations are a confluence of new ideas, grand plans, modern business models, high hopes and, often, very poor delivery and implementation. This was the evidence collected after the CDO Conclave:
Whether you are spending millions or billions on a digital transformation, presumably the end goal is all three of the outcomes given in the infographic above. While I admit that the list of reasons for falling short of digital transformation targets is endless, the one problem that keeps reoccurring in my discussions with senior IT professionals is the continued reliance on old technologies and methodologies while delivering new applications.

Why is software testing important for digital transformations?

Because it is the final checkpoint before you let the world into your domain to sample your wares (read: applications). Everyone can agree that building, implementing, using, achieving things at speed is a critical, non-negotiable outcome of digital transformations.

But of what use is such speed if the process / application / eco-system that you are building doesn't allow users to do what they need to be able to do? Speed without quality is like a Dreamliner that spends more time in the hangar than it does flying.

Software testing is that validator which ensures that your applications' users or customers are amazed by the speed at which they can now perform a task AND satisfied that they can actually complete that task every time, all the time.

Now that we are on the same page, you may have a problem on your hands if you can identify with any of these four symptoms.

Want to see how our cloud testing tools are being used to cut testing time to hours or minutes?


Symptom 1. "Our customers report the bugs immediately and then we fix them"

I don't know whether to laugh or cry when I hear this line, and I hear it A LOT! Let me ask you this: would you buy a new car that had never been driven on a public road? So why do you expect your customers to love, or even buy, your application when you ship it to them riddled with bugs?

They might perform the task of your software testing team once out of goodwill, but you'll soon lose them as they become increasingly frustrated by your ability to give them something that works first time and every time.

I am quite confident that this line of thinking is aligned to the "we're always in beta" mindset. The fact that you are still building or continuously enhancing your application does not give you the right to treat your users and customers like a crowd-sourced testing team. By engaging in such amateur-hour practices you are setting yourself up for insanely high customer churn and poor reviews.

The same rules apply for subject matter experts (SMEs) from the business (ie. your non-IT colleagues). They should not be forced into conducting functional software testing after being duped into thinking that UAT has started early! We see this practice so much in medium and large enterprises that we built a calculator that helps you understand the real financial and productivity cost of manual-only testing using people from the business.

Go on, calculate your burn rate now.

Symptom 2. End-User / customer churn is increasing as you transition away from legacy applications

If you are experiencing this symptom, in short, you are probably hurting because you are losing money. And I am very confident in assuming that "losing money" was not a digital transformation goal when you set out to revitalise your IT landscape!

Customer success consultant from Sixteen Ventures, Lincoln Murphy, hit the proverbial nail on the head:
There are only two reasons for customer churn, and only one is even slightly acceptable and that is something Happened to or with the customer. The other (far more common) reason for churn is that the customer did not achieve their desired outcome.
Lincoln Murphy
Lincoln breaks down desired outcomes into required outcomes and user experience. The list of reasons that stop users from achieving required outcomes, Lincoln says, can be summarised by the following:
  • Your product is missing critical functionality required to do the thing they need to do
  • There are bugs and other stability / usability / access issues keeping the customer from doing what they need to do
  • The customer had a bad implementation / configuration / setup
  • The customer hasn’t adopted your product and isn’t using it (for whatever reason)
  • You have a poor (from absent to overwhelming) onboarding experience
You have probably worked out that the first three reasons all point to issues with software testing. These are issues that a good software testing strategy, matched with the right software testing frameworks and software testing tools can easily overcome.

Customer churn for any reason is a silent killer. We all know that acquiring new users takes more effort and costs more money than retaining existing users. Consider this, if your application has 100 customers at the start of the year and only has a 5% monthly churn rate, you will be left with a mere 48 of the original 100 customers when the year ends. Ouch! Do you still think it is ok to use your paying customers as an outsourced software testing team?

If one intervention of yours can negate 60% of potential issues that lead to customer churn, why wouldn't you take that step?

Symptom 3. Your helpdesk or technical support costs are rising

Let's be honest, transitioning users from one version of an application to a new version is going to be painful. Your support teams will have to answer a lot of questions and undertake what will seem like over-generous hand-holding. These are necessary and very important elements of digital transformation journeys for applications teams.

However, this increase in effort should only be temporary. The volume of support events should decrease as users become familiar with their new environments and comfortable in the knowledge that the application still allows them to achieve desired outcomes, but a lot faster and with an array of cool new features. If the increase in support costs does not decline, then you have a problem.

If your team is not guilty of the mindset described in Symptom 1 and your technical support costs are rising then your software testing program may be ineffective at finding bugs before your users find them. Not only will this overwhelm your technical support teams, but it will also keep your development and delivery people in an unending mode of playing catch-up. This situation usually results in all of the following problems:
  1. New functionality or even bug-fixes get delayed as developers try and fight the never-ending stream of defect reports.
  2. Testing coverage nosedives as your testing team only has time to test the functions that are being patched.
  3. Parts of the application that used to work, stop working because of patch that was meant for a seemingly unrelated bug.
  4. Project timelines go out the window because your development and delivery teams are always firefighting.
  5. Reputations, and maybe even jobs, are lost because targets are not met and value remains undelivered.
Download our financial services case study to understand how we used test automation to help a customer reduce their technical support requests by 83%.

Are you only conducting manual software testing at the moment? Do you use non-IT people from the business to help with software testing?


Symptom 4. Updates to your applications always break something else that was working before

This symptom is borne out of overworked manual testing teams that simply do not have the time to execute every test case meticulously. When time is short (and let's face it, it usually always is) it is human nature to take shortcuts, or at the very least, make assumptions that help us prioritise tasks and show some semblance of progress.

Such human traits almost always lead to trouble insofar as software testing is concerned. Modern applications are so complex, with many connected layers and interwoven user journeys, that not testing it all leaves critical components open to failure.

SAP or Oracle modules each have hundreds of screens that connect to each other. Add to this the user journeys of external applications that interface with such ERP / CRM applications, and you begin to understand the many points of failure that your software testing program must validate before every release.

These weak spots will be ruthlessly exposed if your digital transformation program uses outdated testing methodologies and unfit-for-purpose software testing tools. Download our Definitive Guide to Software Testing to understand the best-practices you can implement immediately to supercharge your software testing projects.

I suffer from these symptoms, how can I get my digital transformation back on track?

That's a great question, but it is also one that does not have a straight answer. If your digital transformation project is stuttering, it is likely not due to software testing alone, but we have proven software testing solutions that can help you fix this vitally important component of your digital transformation journey. Implementing robust and fit-for-purpose software testing processes will help you in tackling other problematic aspects of your digital transformation project.

A great place to start is our Definitive Guide to Software Testing for digital applications. This Guide will help you understand the gap between where you are now and where you need to get to soon.

If you are interested in test automation then the Ultimate Guide to Test Automation spells out a 5-step process for implementing automated software testing. It comes complete with comparisons of test automation technologies and software testing tools.

If you want obligation-free and professional help from our consultants, take advantage of our a free software quality strategy session to help set you on the right path to achieve your goals.
Or contact us on +61 8 8312 1287 or solutions[at]qsometech.com

0 comments :

Post a Comment