Customer Engagement, Workforce Enablement, Operations Optimization Articles | RCG

Future-proof Software Testing for Agile, DevOps and beyond

Written by Niko Mangahas | February 03, 2017

This is a follow-up to a previous blog titled, “QA Survival Guide: 3 Philosophies to Future-Proof your Software Testing Practice” .

AGILE IS NOW THE STANDARD AND DEVOPS IS NOT FAR BEHIND

It is a fact for Software Testing professionals that technology evolves at an extreme pace today, and there is tremendous urgency toward building a strategy on how we tackle it. Because of this invisible hand that continues to push for acceleration, our technology communities have developed smart ways to accelerate delivery – in Agile and DevOps practices. The most recent studies indicate that only 4% of organizations do not have any agile teams, and most have more than half their dev teams doing a flavor of Agile[a], so it is almost a certainty that you are familiar, even experienced in it. DevOps on the other hand, is another set of practices to enable a seamless flow for continually delivering software into production. DevOps is quickly becoming a standard today with research showing that 74% of IT organizations are doing, planning or plan to implement it in 2016[b]. Considering that it has only been around officially for 6 years, this rate is alarmingly higher than adoption for Agile, which many considered to be already remarkable. With this trend, DevOps will be a directive for most organizations within this year or the next.

HOW IS DEVOPS RELATED TO AGILE?

Some see DevOps as a supplement to Agile, some say the two are parallel, and to some, an evolution of Agile itself. Personally, I would simplify it as having an Agile mindset with a Continuous Integration & Deployment (CI/CD) capability. No matter how you see the relationship between the two, there are significant parallels to what is driving the incredible rate of adoption of Agile and DevOps. In fact, where they overlap is precisely where we need to pay attention, since this means regardless of where you are in the adoption of either or both – these expectations are the common ‘wish list’ of the business, your CIO or pretty much the IT industry as a whole. If you focus on developing capabilities that are common to both, you will largely be ready whatever comes your way and in fact get ahead before your organization makes it a must. This overlap can be summarized in four points:

  1. Working Product is king – in Agile, “Working software is the primary measure of progress” and DevOps promotes habits of “Evidence Gathered in Production and Live Site Culture”, so bringing tangible value to the market and keeping it live is of the utmost importance– and everything else is secondary.
  2. Delivery needs to be frequent and incremental – espoused in the Agile principle “Deliver working software frequently, from acouple of weeks to a couple of months, with a preference to the shorter timescale.” And in DevOps, incremental delivery to the frequency where it is a non-event is an ideal. Agile and DevOps also align in embracing that incremental delivery results in less risk, less rework and better adaptability to changes, with value is exhibited sooner, and subsequent buy-in and investment will be easier.
  3. Adaptability increases Business Value – in Agile, we “Welcome changing requirements, even late in Agile processes harness change for the customer’s competitive advantage.” In DevOps, “Focus on Flow of Customer Value” paired with more frequent, incremental releases, provides the ability to adapt and formulate a response to a rapidly changing market thereby creating a massive benefit to the customer and the business.
  4. Collaborative Work Environments are the most effective – in Agile, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In DevOps, one of the habits is establishing a culture of Team Autonomy. Both agree that aligning with the Enterprise is important, but the team itself should work within self-governing teams with collaborative cultures instead of competitively.

AND THERE ARE EXPECTATIONS COMING FROM OUR ORGANIZATIONS AS WELL

But we should not make decisions completely on what our superiors and the industry want us to do. When we signed up to be leaders of QA and Software Testing, we took on the responsibility of advocating quality in our organizations. As leaders, there are expectations of us both by upper management, peers and team members. The fine print stipulates that we need to strategize, manage and innovate in terms of:

  • Balancing and optimizing quality, risk, time and resources
  • Generating and sharing testing expertise, and creating specialization
  • Building enablers and adding new testing services
  • And more broadly, influencing the organization to pursue better quality

The area of overlap between Agile, DevOps and the Software Testing discipline is the primary focus for building strategy. This is where the Ubiquitous Quality™ Model comes in.

Figure 1: The Ubiquitous Quality™ Model (click for larger image)

UQM FOCUSES ON WHERE AGILE, DEVOPS AND QA PRINCIPLES OVERLAP

Since we have to be champions of software testing and quality, and reflect the speed with which our development practices change, the Ubiquitous Quality™ Model evolves software testing in a cadence that allows both for thoughtful planning for the future and shifting gears as we learn, and as the organization around us changes. UQM in a nutshell:

  1. The three pillars of UQM are Expertise, Distribution, and Infrastructure. Every testing organization is encouraged to create their own vision as it relates to these three. Every capability is built towards a pillar (more accurately, a vision of the pillar), with some across 2 pillars, some overarching all three.
    1. Expertise relates to how you generate, manage, share and extend testing expertise, or in a broader sense “how you get better at testing as a discipline and share it”.
    2. Distribution is your vision of how you consume test assets and artifacts and how you pursue quality as the accountability of the whole IT organization.
    3. Infrastructure is how you enable capabilities and scale according to the need, as well as reducing dependencies and barriers to testing (or simply, more test independence).
  2. UQM prescribes the building of capabilities towards one or more of the pillars in a 3-month period and forecasting the next capability in the succeeding 3 months.
    1. While building the current capability, collection of feedback from testing teams, QA leadership, Head of Dev, CIO, and other stakeholders would need to be accomplished for the forecast capability. This allows for the refinement of your forecast capability at the end of the first 3 months and before you start building it. This timing roughly coincides with 4-7 sprints, or one ‘Program Increment’ (in SAFe Agile) which is ideal timing to create a full ‘Plan-Do-Check-Act’ cycle across multiple teams.
    2. Note that you are building capabilities for multiple QA resources and teams, as such they need to be evaluated by feedback, and best supported if basic metrics are defined to guide the decision.
    3. If 3 months is too little time for your organization, build a prototype or define a less sophisticated solution (such as going from an automated approach to a manual one).

 

Figure 2: The approach to UQM (click to enlarge image)

 

  1. UQM does not provide a fixed sequence for building capabilities.
    1. The biggest recommendation is to start with 2 base capabilities that share benefit across all three pillars (shown in the center – Test Sizing and Test Data Management) because how well you build these will support the succeeding capabilities. Also, once they are set up you are free to prioritize one pillar or build one capability for each of the three pillars.
    2. While the rest of the capabilities have no prescribed order, this is where the input and needs of the larger IT organization also come into play – consider the highest priority by looking at the most urgent problem, “lowest hanging fruit”, or biggest win and value for the company.
    3. Capabilities that stretch across two different pillars often have prerequisites from both, which might make them more challenging early on.

UQM RECOMMENDS ADAPTIVE CAPABILITIES AS BUILDING BLOCKS

These guidelines to UQM and its approach are the basic building blocks to get started. There are also 16 capabilities which can be broken down or extended further, as long as it follows the approach, timing and the direction toward the three basic pillars. These capabilities, as well as various ways to implement them, will be covered in future articles. There is a whole spectrum of example implementations for each capability, starting from rigorously mechanical approaches to the completely automated and dynamic ones – and there is no single best approach. Selecting an implementation requires a balance of business need, risk and availability of resources – skillsets, hardware and software. Some industries also need to factor in regulatory compliance as well (PCI, SOX, HIPAA).

The capabilities in UQM may seem familiar, and that is unsurprising because there are elements based on the different components or dimensions found in QA roadmaps and assessments methods, or ‘process areas’ in terms of the TMMi (Testing Maturity Model integration) Framework. The major difference is that UQM does not measure success towards different stages of rigid conditions to exhibit testing maturity. Nor does it point out a ‘gap’ in some aspects of your software testing, as found in QA assessments. It also does not define a fixed sequence for building capabilities and processes. What it does instead is focus on building immediately beneficial capabilities, instead of procedures and processes. Governance and operational processes and metrics of Software Testing are seen as foundational and are present to support, manage and measure the building of testing capabilities.

UQM IS FOCUSED, FLEXIBLE AND FUTUREPROOF

The beauty of UQM is that it is cleanly streamlined to create laser focus on just three pillars towards enabling (Infrastructure), generating (Expertise), and sharing (Distribution) business value from testing. UQM recognizes the unique circumstances of your organization – the collection of organization goals, business priorities, access to resources, or wherever you are in Agile or DevOps adoption. And let’s face it, with the velocity necessary to remain competitive in the IT industry, those will change – a lot. With UQM, you will always be ready, and you can even get ahead. The beauty of UQM is that it is Futureproof.

Works Cited

#UbiquitousQuality #IdeasRealized
View full post