5 March 2021

1 powerful idea that made our software testing services awesome

Share
1 powerful idea to improve software testing services

Our customers turn to our software testing services to help them transform their software testing programs from cost centres to value generators. If we followed the same principles that the industry has been using for decades, we would never deliver the lofty outcomes that our customers seek. Instead we turned our practices upside down and created some overarching principles that are non-negotiable in every project. One such principle that helps us deliver this value consistently and across projects is the concept of team-owned tests.

Don't worry if you read that and thought, "WTF!" That is the most common reaction from test design and test automation candidates who attend our interviews. It is our version of XP's collective ownership principle.

What is the problem we’re solving?

Many symptoms contribute to the problem of lengthy, onerous and ineffective software testing cycles that seem more like a burden or an annoying cousin to be locked in the spare room, than the good looking new boyfriend who is to be shown off to friends. In fact, I think the waterfall concept gets unfairly castigated for giving software testing the bad rep it currently seems unable to escape from. It's a combination of a number factors that are having a devastating impact on an economy-wide level:
The annual cost of poor software testing services to the US economy

The activities that have got the software testing profession and function to this point stem from hardware testing. Developing, testing and maintaining hardware is intrinsically a more static exercise compared to testing software. More so now that cloud, agile, devops, etc are hellbent on redefining the concept of speed and efficiency in the software development pipeline.

The very nature of modern software design and development renders traditional software testing methodologies somewhat akin to what propeller-driven planes are to the airline industry. User journeys in software development change often in response to evolving user demands, adding to software testing costs and pressure. The technologies and methodologies (think DevOps and CI) used to build these newfangled applications add an extra layer of complexity to a tester’s task and the costs of testing an application, to the extent that:
Shift to agile & DevOps creates more software testing & increases costs

Also, and very unlike software development, software testing is undertaken by many smaller teams where the test and test script is often designed, scripted and executed by different people. Conversely, in most development teams a single developer is responsible for creating a function or even a module within an application. Therefore, traditional human models about “ownership” and “only I have to know what’s going on under the hood” are about as relevant as a keyboard is to Siri or Alexa.

Essentially, the problem we are solving with the concept of team-owned tests is that traditional methods of executing software testing only result in wasted time, lots of bugs in production and shredded reputations in this day and age. The traditional methods of software testing do not allow easy modification, maintenance or, often, even execution.

If your software testing (particularly automated regression testing) takes an age and still leaks bugs to production, it is probably suffering from this problem.

The difficulties in changing mindset & culture are huge

You will agree that asking a proud and talented professional to unlearn a very natural human trait such as “this test is mine” is a very difficult task. In fact, the problem of culture was referenced in the latest World Quality Report via quote from this very astute professional
The number one challenge is finding the skilled people.
IT Director, Pharmaceuticals Company in Ireland

To overcome this cultural issue that permeates the entire software testing industry the world over, we had to create some very specific structures within our teams to enable the implementation of team-owned software testing. So we now test the understanding this principle as early as the first interview. Some people understand the concept before the explanation has left our lips. Most take a little bit of prodding and require examples to grasp it. About 20% of our interview candidates find within the first few minutes of the technical interview that they are better off looking for jobs in a different company.

You will find that your software testing teams probably display a similar distribution. However, you will find a similar problem to the one GE encountered when implementing Jack Welch’s philosophy of bringing the middle band up to the “stars” band. This is not just a change of personal habit, but a cultural shift that must be espoused by every team member, else it makes little difference in transforming software testing from a cost centre to a value creator. Download our best practice guide for digital application testing to understand how your team can also transform software testing into a value creator for your organisation.

We have found that peer reviews of test design, test scripting (where automation is concerned) and test maintenance activities help to propagate this new mindset. Peer reviews are not the magic bullet to overcoming this challenge, but every law needs a sheriff to enforce it, and our take on extreme development (for software testing) is delivering the desired shift.

Want to see how our software testing tools & services can cut your testing time from weeks to hours?

But, what is team-owned software testing in practice?

Great question. To help our folks deduce if they are implementing this principle in their work, we recommend that they ask themselves one big question:
Can the person next to you understand your test / script / idea without you explaining it to them?
Qsome principle #1 for team-owned tests
One of the ways we build this self-assessment into our test creation pipeline is by splitting the test design and test scripting processes for automated software testing. If the person scripting the test cannot understand the designed test then that question is automatically answered in the negative.

This question also assumes that the person coming after you has no knowledge of the system under test. For obvious reasons, this assumption is not feasible for totally out-of-the-box applications under test, but we find that it remains relevant for most applications that we test for our customers.

The achievement of this goal in software development often results in us users triumphantly labelling an application “intuitive.” Similarly at Qsome, we aim to build intuitive manual and automated software tests that can not only transcend our internal team boundaries, but also the silos in which most of our customers' teams operate.

Then what?

As a company, we are never short of questions. So, after the Big Bertha of a question that gets asked up front, we add a left and a right jab to really start probing:
Have you placed only logic and the right logic in your scripts?
What are you having for dinner tonight?
This is not a joke. The first question is unquestionably a very serious and pertinent one, given that we believe in thorough and robust software testing that actually uncovers bugs instead of acting like a revolving door that allows anything to be released to production.

At Qsome, we are VERY big on test automation. We automate early and often, to the extent that we our default thinking is that the testing of most digital applications can be significantly automated, until a posse of insurmountable obstacles reveal themselves from the shadows. To make this philosophy work, we prefer to use decision trees to support our data-driven testing framework. Our test automation engineers know that the stress must be placed on the data set, rather than the automation script. This is not an easy task because it is generally not the way that their minds have been wired to work throughout their education.

The odd thing about dinner is that you can only have it if you have the time. If your answer to questions 1 and 2 is not “yes,” then you may just have to skip dinner and head straight to a hearty breakfast, because you will be using that time to fix your work.

My thoughts above about dinner and breakfast are only half in jest.

Our customers have reduced bugs in production by over 70%? Want to see how?

Why are you so demanding of your testers?

Wow you really do like speaking truth to power, huh? That is probably also the question that abounds in the minds of the 20% of interview candidates I introduced earlier. The thing is, we really don’t see our approach in that light.

We started out with one very important and achievable goal: to transform software testing from a cost centre to a value generator. There are few ways to achieve this goal unless our teams change the way that software testing is performed.

A crucial obstacle / reality in achieving this goal is the fact that software tests must be as robust and dynamic as the applications that they are built to test. Additionally, modern IT functions are increasingly distributed, outsourced, remote or many other buzzwords that simply mean that your software tests are definitely going to be handled by many different people.

What is the worth of a software test if it requires a dinner date over fine wine to be understood by a person other than she who wrote it?

In football (of the European, not Australian or American variety) the players practice for weeks on end to develop a telepathic understanding of their positioning on the pitch or decision making in pressure situations. For reasons good or bad, modern IT teams, especially in large organisations, have no such luxury. They must get it right the first time or sh*t hits the fan and there’s never enough disinfectant to clean up the mess it makes of some reputations.

How do you know that this has made your software testing services better?

At work, I don’t believe in making a rule that does not have a firm and achievable goal in mind. But the real results that this principle helps achieves will vary depending on who you ask. For two very recent projects, customers reported the following:
  • One customer reduced testing time from about 4 weeks for every major release to 36 hours after working with us.
  • Another customer has seen a 58% fall in support tickets about bugs in production, after working with us for just 3 months.
I’ll leave you with a simple question, what could such results do for you?

If you need help in cutting testing time and finding more bugs before your application's users find them, speak to us understand how we might be able to help you. Right now, we're offering a free 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