Testing, Schmesting…Are Digital Workspace Teams Missing a Critical Role?
Yesterday an update at a major hospital in the Netherlands (+1,000 beds and +10,000 employees) forced patients to return home and employees working from home to have either a horrible user experience or worse, no workspace to logon to at all.
Healthcare employees, including the IT staff, now more than ever deserve every compliment they receive now.
The problem underlying this outage is one that I see in every industry, and it seems like it is happening more and more – a lack of testing to confidently demonstrate that a planned change in the environment will not result in adverse impacts to the end-user – to paraphrase a saying from the health-care vocabulary – how is this still happening?
Sometimes, reality hits like the iconic frying-pan-in-the-face cartoon image, and you wonder how could I have gone this long not seeing something so obvious. Here’s one such fun fact that occurred to me in a recent customer discussion. We at Login VSI make a testing platform that is by and large targeted at the Workspace team and so it would seem obvious that the folks who use that product would have the word Test, QA or something equivalent in their job titles. And yet, with rare exception, they don’t. To quote Homer Simpson, “Doh!” While this might be seen as a sign of madness on our part, I believe the more accurate reality is that there is a prominent role missing in most Infrastructure teams, that of Tester.
The vast majority of IT testing solutions are sold to the people involved in developing, and by extension, association, testing, applications. The users develop in-depth and rigorous testing scenarios and drive test automation platforms to ensure maximum test coverage from the UI to security to back-end performance and more. Of course, their goal is to ensure a high-quality application experience to the end-user, free from defects and performance issues. When all the tests pass successfully, that release candidate is delivered to the Workspace team for consideration in the next Change Advisory Board meeting. Once approved, the change is promoted to Production.
The next morning, if users start to experience availability or performance issues on the updated application, the troubleshooting begins with a goal to identify the root cause. If the issue is tied to the underlying change at an application code level, a bug fix is developed, test and either patched in Production or a new release candidate is produced. However, often, the issue is somewhere in space that exists between the developers’ lab and the reality of the Production environment. From packaging the application for use and perhaps repackaging for a virtualized layer, only to subject it to the wild vagaries of a Production environment continually being updated, odds are there is always going to be some variable (or dozens) not accounted for in the Developer/QA lab because it occurs downstream of their process. Therefore, it is critical that an additional set of tests be completed to subject the updated software to the realities of the Production environment, or as close as possible. The design and execution of these tests require a deep understanding of the Workspace environment and associated layers of virtualization technologies. In short, it requires a Workspace Test Engineer.
Ironically, in recent months I’ve heard from multiple customers that they are tired of being an extension to the QA team of (fill in your favorite Workspace vendor) because they believe that these suppliers do not adequately test their product. This is an unfair expectation of an ISV, irrespective of its size. There are an endless set of possible configurations in the various Production environments of their customers. When compounded by the different scale of those customers from hundreds of users to hundreds of thousands, then the only feasibleQA strategy is a “lowest common denominator” approach. Therefore, it is inherently irresponsible for any customer to roll updates from these ISVs into Production without significant on-site testing. I can already hear the chorus of voices saying, “of course we test,” but who specifically designs these tests to ensure optimal test coverage and what investment in test strategy, tools and competency is available.
Testing is not a part-time or side job to one’s role as a system administrator, and it is a well-defined discipline that people spend years mastering. The cost of failure in this area is well documented – point me at an enterprise and I can assure you there’s a story of a failed change/update that had to be rolled back due to some “silly configuration issue” that wasn’t trapped before deployment. When will Workspace leaders borrow a page from their counterparts in App Dev and develop competence in Testing. As DevOps continues to drive the rate of change at the desktop with more frequent updates piling up as release candidates for Production deployment, a failure to test is a recipe for disaster. What say you, Homer?
Here are my top 3 factors that positively contribute to change management:
- Test changes as a whole (in the full infrastructure where they’ll live)
- Invest in Deployment automation
- Invest in Test automation
