devopsy.kinsta.cloud

Author: Ron DeCanio

  • Automation Killed QA – It’s Time to Deal With It

    Automation Killed QA – It’s Time to Deal With It

    Quality assurance (QA) had a good run.

    From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

    Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

    With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

    We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

    But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

    The answer is simple. Automate everything.

    Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

    While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

    Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

    We must start our automation for quality at the beginning, during establishment of business requirements.

    Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

    Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

    Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

    Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

    Questions?  Comments?  Perspective?  Have at it in the comments below.

    — Ron DeCanio

  • Customer Demands Outpacing Business Requirements

    Customer Demands Outpacing Business Requirements

    As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

    IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

    In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

    As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

    In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

    We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

    Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

    As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

    Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

    Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

    Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

    Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

    Let’s pause and review what we just did.

    We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

    So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

    Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

    Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

    Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

    This is how we translate business requirements into innovative software at speed.

    For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

    — Ron DeCanio