Digital Transformation alleges major benefits for end-users and the organization as a whole––but does it actually improve work life for employees? Check out this QA Professional’s tester-monial on their experience with Digital Transformation.
The past year has probably done more to accelerate Digital Transformation (DX) projects than any other single event in the past 20 years. No one could have predicted that a global pandemic would be the impetus for change and that business as usual would be anything but usual; changes would need to quickly be made in order to not only comply with government health mandates, but to maintain daily business operations as well as to effectively work with a much larger remote workforce.
When we are referring to Digital Transformation, we are referring to the overarching activities related to taking our existing processes, workflows, interactions, and technology tools and modifying them (or creating brand new instances) so that we can address new or changing environments where we do business.
Traditionally, Digital Transformation projects are implemented for goals like “increasing profits,” “gaining a performance advantage,” or “improving our overall user experience.” The case is frequently made for what should be done and why. What we don’t often talk about is who gets involved in these DX projects and what their overall take on these are. Today, I’m going to share my thoughts and opinions on DXs from the perspective of someone who has been deeply involved in numerous DX initiatives in various roles.
How Digital Transformations Change the Way QA Works
Over the past 30 years, I have seen a number of DX projects created and adapted. Fortunately, I haven’t really seen any completely fail; although, I have seen a number of them transformed beyond what their initial focus was meant to be. I also have definitely seen DX projects that, in my opinion, were more successful than others. Many of these projects had a direct effect on my interactions either with my internal organization or the way that I dealt with customers and external users.
Technological Changes
Perhaps the most direct and noticeable DX project is one that adapts existing work processes and changes them to be more flexible or efficient. In the early days of my testing career, I worked with Cisco Systems® as they were ramping up their 7000 and 7500 series of routers, along with their original router offerings. The first DX project I was involved with in this case was making it possible to leverage as much Internet capability as was available at the time to minimize the need to be camped out in the various labs and directly handle the equipment. The goal was to either directly connect to the systems either through their console ports or their network interfaces, configure the systems, run our tests from our source and destination machines, use our network management and monitoring tools, and be able to run as much of our work outside of the lab as possible.
To this end, we implemented a variety of Automation tools based around the Tcl/Tk language, the Expect extension, and various programs based on the C programming language to interact with protocol analyzers called “Sniffers” (high end and very expensive at that time). By the end of the DX project, we were able to connect to any piece of equipment that was in the source and destination path, configure that equipment, run tests, and verify those tests––all while connecting remotely. The goal was to make it possible that any of us could run our tests anywhere that we were allowed access to do so, either from our locations at work or at home. We were successful and this particular DX project was continually incremented the entire decade that I worked for Cisco Systems®; it was still in active use when I left in 2001. Considering the DX project was started in 1991, that counts as a long term success to me.
Additionally, the biggest benefit of being able to connect remotely to all of these devices, specifically the console ports, was that we were able to enter the configuration mode of the units, script large scale configuration options and changes that could be applied via our automated test scripts, and save them. For anyone who has ever configured a Cisco® router (especially in the 1990s), you can imagine how much of an improvement this was. The biggest benefit for me was that I was able to keep dozens of configurations in source files and feed them into the required routers, save the changes and test immediately. To say that this process alone saved us hours of toil each day would be an understatement and over the course of several years, the time saved in just this area would prove to be huge.
Organizational and Cultural Changes
Since moving on from Cisco Systems®, much of my career has been focused on working with either smaller companies or companies that didn’t have dedicated testing resources until I came along. This is a condition I grew to call being “The Lone Tester” and with that badge, often came the dubious distinction of being “the lone person who knew what was going on in testing.” Whether by design or unintentionally, I frequently found myself to be a “testing silo” and while this may be seen as a benefit (hey, job security when I am the only one doing something!) it can also become a job prison (because I am a silo and a necessary one, I was frequently not considered for other opportunities). Thus it made sense to make sure that I minimized my role as a silo and made it possible for others to see what I did, be able to do what I did, and add to it as well.
I often created my own DX projects around documenting test procedures, test libraries, test tools, and how to use them and add to them. This made it possible to allow the developers to use my testing tools if they wished, encouraged testing to be a process that could be done by more people, and the net result was that it freed me up to look at more interesting problems and to also take on some other roles in the organization.
To be clear, these projects didn’t have to be major reworks or large-scale projects. In one of the companies I worked with, there was a BDD/Cucumber process that was used to test a variety of product configuration and interaction elements. The problem was that there could be a variety of interactions that would time out or fail. To that end, I worked on a front-end wrapper using standard bash scripts to act as both a timing element and a “3 strikes” test runner. What this meant was that every test was configured to run to successful completion but in the event of a failure, it would be tested up to 3 times. Any test that failed 3 times would be labeled as “needs review” as well as a tracker for how long each interaction took to complete (beyond a 15 second threshold was an automatic “failure”). By doing this, we were able to determine which workflows were either flaky or where there were inconsistencies and over time, we improved those processes so that the number of “strikeouts” diminished considerably, almost to zero.
DX projects ultimately are less about the tools & technology and more about the interactions with people. For organizational and cultural changes, the greatest change is communication and interaction with other teams. My role may be a silo of sorts, but there was no rule that said I had to be the only one who interacted with it.
My Tester-monial: How to Improve Your Digital Transformation from Within
After spending 3 decades with a variety of organizations and working with an array of technologies, I can point to a few areas I would recommend if a successful Digital Transformation project is in your future (or is underway right now; chances are, for many reading this, you may be involved in several):
Start Small and Have a Targeted Focus
It is tempting to take on large projects and have a desire to revolutionize everything. To that, I suggest starting with a specific problem, the more specific the better. Just as Agile development focused on developing small, incremental, and focused stories, DX projects likewise should be specific and targeted. Just like when we climb Mount Automation, the overarching DX goal could be on a large scale but breaking up the pieces into bite sized chunks is critical for success. Being able to have early wins and successes will fuel the individuals and teams going forward and adding to the DX project.
In one of my recent projects, I was looking at how we could test a variety of interacting tools. At the time, there were no automated tests in place to examine how we were transferring files from point A to point B. It may not seem like there would be a lot to deal with when it comes to copying files from one place to another, but the devil was in the details. Areas we had to consider were if files were encrypted or compressed, whether or not it was using a variety of 3rd-party processes for handling the data, as well as confirming the data was being formatted correctly. This one area, while it may have seemed trivial on the surface, would provide me close to a year’s worth of work to cover all of the conditions. In short, having a specific focus is important because even with what look to be small projects, they can quickly balloon out of control.
Get Buy In from Everyone Who Will Be Affected by the Changes
Sometimes Digital Transformation projects are necessary and they have to proceed along a particular timeline. However, while there are technologies and tools that come into play and are implemented, ultimately people interact with those tools for them to be successful. If people aren’t given the chance to “buy in” and give their feedback and recommendations, we may very well create a solution to a problem that doesn’t actually exist, or we may complete a DX project meeting a need in a way that the players involved can’t stand or will begrudgingly use.
A phrase I was taught some time back by a friend was that there was a way to voice displeasure at a process or policy that was exceptionally onerous, even if well intentioned. The best way to test a process and a system is to be the “overly compliant one.” What this means is that, when faced with a policy that is frustrating and overly burdensome, occasionally it helps to let everyone see the choice of the actions implemented. This was especially true some time back when due to security concerns, we were required to set up a tunnelling protocol to allow us to perform certain steps to complete our build process. Some people would choose to either ignore or find a creative solution to sidestep the issues. Instead, I put on the hat of the “overly compliant one” and every time I encountered a problem with the security arrangement, I walked the IS group through the problem and had them help me reset it as per their recommendations.
After about the sixth time of me doing that, the IS team called a meeting and decided to re-examine the policy that they had put in place, invited me to discuss where I was finding so many problems, and together we determined a solution that met the needed security requirements but resulted in a process that required considerably less hand holding and in the process, made for an overall solution that was better than their initial approach.
Since all Digital Transformation projects are ultimately people projects, it’s critical to include the affected people along the way. Gather their input, listen to their concerns, fix their bugs, and help them have the best experience possible.
Determine How to Scale and By How Much
The goal of organizations (generally speaking) is to grow their business and abilities and serve more customers. A shrinking pool of customers is rarely a good sign for any business. As growth is the key to continued success, there needs to be a path to making that growth take place.
In the past decade I have been involved in a number of DX projects specifically aimed at CI/CD solutions. During this past decade, the demand for these services has only grown, so more machines, more processes, and more pipelines have had to be developed, often to operate at the same time and in parallel. To that end, technologies like containerization have become critical. Being able to set up and deploy test harnesses in the cloud and on the fly has also proven to be critical.
On the positive side, a lot of work was done to implement these processes. By being able to spin up multiple coordinator nodes and an associated number or worker nodes, we can run tests in parallel, run build steps in parallel, and also run deployment steps on multiple destination servers in parallel.
Summary
At the end of the day, the question on many people’s mind’s is “Are these DX projects ultimately worth it?” My answer is a qualified “yes.” They are worth it when your goals are SMART, when:
- they are undertaken with clear goals as to what they will accomplish,
- those goals are reasonably attainable,
- the process to achieving the set out goals are done incrementally, and
- the affected users/customers are able to offer their feedback and buy into the overall project(s).
Even then, many of these projects never really “finish;” rather, they go on continuously and they adapt and are re-invigorated as technologies change or customer needs change. Having a good strategy and effective planning goes a long way in these cases, and this takes time. The last thing you want to do with a Digital Transformation is rush through it, only to find late in the process that you’ve left out a key portion.
The best way to ensure you’re setting your DX up for success is by getting expert help from companies like LogiGear. From consultation, to strategy, to execution, LogiGear will help you every step of the way to ensure you’re not only increasing business value, but putting value where it matters most: in the hands of your end users.
Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.
