The Role of QA Testing in an Enterprise's Digital Transformation Journey
The Role of QA Testing in an Enterprise's Digital Transformation Journey
IT departments need to adopt agile project management and product development. QA testing can ensure that software is predictable, reliable, and high-quality.
Join the DZone community and get the full member experience.Join For Free
Digital technologies are rapidly transforming both business practices and societies, and they need to be core to your business model if you expect to meet the fickle expectations of the digitally empowered customers of the future. What's the shortest, most optimized path to such a future for a company just starting its digital transformation journey?
For an enterprise with an IT department that does software releases every two or three years (which includes a dedicated period of QA testing of several months), the simple answer to that question is: You can't get there from here. Because customers are interacting with businesses in dramatically different ways than they did a decade ago (with few indications that there will be less change in the coming decade), your IT department needs to take a different approach to delivering applications — one that involves using an agile project management and product development methodology and deploying software in a DevOps environment.
An agile process is any approach that promotes frequent interaction between an IT department and business users and tries to regularly build and deliver software that meets business users' changing requirements. Agile is all about short, flexible development cycles that respond quickly to customer demand. Since you are, in effect, building a continuous, two-way DevOps software pipeline between you and your customers, you should have the idea of Continuous Delivery (CD) in mind from the start as the destination for your digital transformation journey.
DevOps Continuous Delivery is a software development strategy that optimizes your delivery process to get high-quality software into the hands of your customers as quickly as possible. Scrum and Kanban are currently the two main types of agile process frameworks for doing that. For organizations just getting their feet wet with agile principles and approaches, here are a few differences between the two frameworks.
Scrum takes a time-boxed, incremental approach to software development and project management by advocating frequent interaction with the business during what are known as Sprints (which are called iterations in other agile frameworks). The simplest Scrum project team (as shown in Figure 1) is made up of a customer or business unit stakeholder (known as a Product Owner), the team facilitator (called a Scrum Master), and the rest of the agile development team. Team members interact frequently with business users and write software based on requirements that they pull from a Product Backlog (a prioritized list maintained by the Product Owner) that they then integrate frequently with software written by other team members.
Overview of the Scrum agile process framework (Source).
Scrum projects employ fixed-length Sprints, each of which usually lasts from one to four weeks, after which potentially shippable code should be ready to be demonstrated. The notion of releasing a prototype, or minimum viable product (MVP), is also very important in Scrum for getting early feedback from your customers. Once the MVP is released, you're then able to get feedback by tracking usage patterns, which is a way to test a product hypothesis with minimal resources right away. Every release going forward can then be measured for how well it converts into the user behaviors you want the release to achieve. The concept of a baseline MVP product that contains just enough features to solve a specific business problem also reduces wasted engineering hours and a tendency for feature creep or gold-plating on agile software teams.
The Kanban agile process management framework is designed to aid decision-making about what software to produce, when to produce it, and how much to produce. Unlike the time-boxed approach that Scrum takes, Kanban is designed around a continuous queue of work, which goes through a number of stages of development until it's done. Kanban teams often use index cards or sticky notes arranged on walls, such as the Kanban Board shown below, to visualize workflow in a left-to-right manner. When work is completed in a stage, it moves into the next stage column to its right. When someone needs new work to do, they pull it from a left-hand column.
Kanban board (Source).
While Scrum relies on fixed time-boxes for estimating and planning, Kanban puts more emphasis on the concept of cadence, or continuous flow, that an agile team establishes by working together and reliably delivering software at a set pace. Some Kanban practitioners also distinguish between a Minimum Viable Product and a Minimal Marketable Feature (MMF). An MMF is more of an enhanced MVP rather than a beta or test product and is capable of returning value to the customer when released as an independent entity. In addition to being distinct and deliverable, MMFs are expected to pass Bill Wake's INVEST test for features on agile software projects.
Comparing the two agile process frameworks, Scrum promotes more radical process change rather than continuous, evolutionary change and adaptation, which is the case with Kanban. Many organizations benefit from Scrum's more prescriptive approach to work management and its more rigidly defined iterative planning and feedback cycles, which may make it a good choice for organizations that need a fundamental shift towards more efficient processes. Kanban, on the other hand, provides a more incremental approach to work management and improvement. If your organization already has working processes that you want to improve over time without shaking up the whole system, Kanban may be the better choice.
Note that neither of these two agile process frameworks recognizes a separate step or phase for QA software testing. The reason for this is that QA testing involves all the members of a cross-functional agile team. On agile teams, everyone is equally responsible for the quality of the product or the success of the project. This means testing is done by the whole team, not just designated testers or quality assurance professionals, including team members whose primary expertise may be in programming, business analysis, database or system administration. Team members whose expertise is in software testing or using a particular testing tool aren't limited to only doing that activity; they can also collaborate with customers or business owners on product requirements and work with other members of the team to develop high-quality code that fulfills those requirements.
Another role that QA testing can play on an agile project can be to help document the software under development. Although one of the guidelines of the Agile Manifesto is to value working software over comprehensive documentation, agile developers still need to know how to understand, maintain, and extend working software. Agile projects with integrated development and QA processes — such those that use testing software capable of running executable specifications that can describe how the software is actually working — can automate the software documentation process to some degree (you're likely to still need user, system overview, operations, and support documentation).
Continuous Integration and Delivery
In addition to deciding on whether Kanban or Scrum (or a mixture of both) is the best fit as an Agile process framework for your organization, companies embarking on a digital transformation journey need to look at the bigger picture of how you integrate, build, and deploy code, and how long each activity takes.
Continuous Integration is a process wherein developers check code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect errors and conflicts as soon as possible. The software build, which compiles the source code into binary code, is done automatically using tools such as Makefiles or Ant, rather than when a developer manually invokes the complier. This allows immediate validation of successful changes to your application, which saves time and reduces the need for rework.
By automating the deployment process, you are, in effect, releasing every good build to testers and users. This allows for the delivery of new functionality to users within minutes whenever it's needed, as well as instant feedback to your DevOps teams that, in turn, allows them to respond more rapidly to customer demand.
If your company's developers are integrating code into a shared repository several times a day, testing needs to be done continuously as well. This means running unit tests, component tests (unit tests that touch the filesystem or database), and a variety of acceptance and integration tests on every check-in.
If developers are practicing test-driven development (TDD), they'll have already written unit tests to verify each unit of code does what it's supposed to do. Automated unit tests are also the first tests that should be run as part of an automated build because they can provide the developer with immediate feedback regarding potential issues in the latest release
Building a successful Continuous Delivery pipeline means creating a DevOps culture of collaboration among the various teams involved in software delivery (developers, operations, quality assurance, business analysts, management, etc.), as well as reducing the cost, time, and risk of delivering software changes by allowing for more incremental updates to applications in production. In practice, this means teams produce software in short cycles, ensuring that the software can be reliably released at any time. One way to promote this culture is via behavior-driven development (BDD), an extension of test-driven development that encourages collaboration between developers, QA and non-technical or business participants on a software project.
Behavior-driven development (Source).
BDD extends TDD by writing test cases in a natural language that non-programmers and domain experts can read. BDD features are usually defined in a given-when-then (GWT) format, which is a semi-structured way of writing down test cases.
BDD features are written in the following format:
- Describe who is the primary stakeholder of the feature.
- What effect the stakeholder wants the feature to have.
- What business value the stakeholder will derive from this effect.
- Acceptance criteria or scenarios.
The next stage in implementing your CD DevOps pipeline should be test automation. Manual testing is a time-consuming and labor-intensive process and, in most cases, also a non-value added activity since you're only trying to verify that a piece of software does what it’s supposed to do.
The following Agile Testing Quadrants matrix (developed by Brian Marick and refined by Lisa Crispin) can be used to prioritize the many different types of tests to automate in your CD pipeline. There are no hard and fast rules about what tests (performance, functionality, security, user acceptance, etc.) to automate, when to automate them, or even whether certain manual tests really need automation. Crispin and other agile testing experts favor automating unit tests and component tests before other tests since these represent the highest return on investment.
Agile testing quadrants (Source).
Delivering Rapid and Flexible Business Value
Enterprises these days have the choice of transforming their businesses and IT operations due to technology disruption, or not. If they don't transform, more than likely, they won't be in business long. In order do the rapid and flexible delivery of software and systems necessary for that transformation, IT departments need to utilize test management software and adopt the disciplines of agile project management and product development, Continuous Delivery, and DevOps. QA testing approaches like the ones outlined above can ensure that software delivered this way is predictable, reliable, and of high quality.
Published at DZone with permission of Francis Adanza . See the original article here.
Opinions expressed by DZone contributors are their own.