For the past few years I have attended the Farm Credit IT Symposium. This years’ symposium was held last week in Austin, TX where I had a chance to present on a couple of topics. One of my talks was titled Roadmap to Enterprise Quality. The description for the presentation is as follows:
In this presentation you will learn how Farm Credit Services of America/Frontier Farm Credit transformed their quality practices and tooling to bring visibility and consistency to Enterprise Quality, including: testing as a team approach, creating an automated test architecture, measuring progress with dashboards and standardizing on a set of testing tools.
If you’re reading this blog post there is a decent chance you are somehow involved in software development. One of the key concerns with software development is that of quality. Like many other organizations, we spend a decent amount of time and resources working toward maximizing our capabilities around enterprise quality. In other words, we are continually tweaking processes and tooling along with educating our teammates in an effort to ensure we are delivering great products that offer outstanding user experiences.
The primary themes in this talk revolve around:
- Shift-left
- People
- Processes
- Tooling
Shift-Left
If you’re not familiar with the concept of shifting-left the short version is that teams following a shift-left strategy strive to focus on quality and testing sooner in the development cycle. For example, focusing more on prevention rather than detection (though detection is still important). In other words, these concerns are shifted toward the left of the SDLC. The following image shows what this might look like in practice:
People
Ask the CEO of any successful company to divulge the secret to their success and there are pretty good odds that he/she will simply state: “it’s our people that make all the difference.” It’s the people (employees) of a company that define a company’s culture. To truly be successful in your journey toward enterprise quality (I.e. delivering great products that offer outstanding user experiences) you must embed quality practices within your culture. It is the employees of an organization, your teammates, that will make this happen. You can’t do it without them!
Processes
A key component in successful enterprise quality is consistency (in processes, tooling, etc.). You don’t have to be 100% consistent in everything across all teams but, the more consistent you are, the more predictable things become. Consistency also allows you to take advantage of a common set of knowledge across team members reducing the number of times a person has to tackle a new learning curve.
In relation to quality, an approach we have been using for a while now is something we call Lean Quality Delivery or, simply, LQD. LQD provides our applications development (AppDev) teams with a consistent process for approaching quality on their teams. The LQD is made up of four components:
- Vision – the vision is the same across all AppDev teams. In our case, our vision is to be the chosen partner.
- Goals – this is a set of common goals for all AppDev teams. For example: functional quality, structural quality and process quality.
- Strategies – each goal is broken down into various strategies (e.g. delivers the desired value, predictable delivery, design for testability, etc.). As with the vision and goals, the strategies are the same across all AppDev teams.
- Tactics – this is where things start to differ a little bit by team. For each of the defined (common) strategies, each team is responsible for coming up with a list of tactics to satisfy the strategy. Many of the tactics are common across the team but they don’t have to be. For example, a team building mobile (e.g. iOS, Android, etc.) apps might have different tactics than a team that is developing back-end APIs.
Teams tend to review their respective LQD tactics before starting a new project (because tactics can vary by project type) and/or after ending a project (to see if there are any tactics that might have improved the outcome if they were to be added to the LQD). A team will also review the LQD during a project from time to time to ensure they are satisfying the strategies and goals.
Tooling
Tooling is another area where every team doesn’t have to be 100% consistent but it helps to at least have a consist toolbox to choose from. Similar to the processes discussed above, having consistency in tooling can help with predictability, training, etc.
When it comes to testing and associated tools we make use of the Testing Pyramid to visualize where we should be focusing our testing efforts and the toolset we have at our disposal. For example, in the following pyramid diagram, you can see that we are inclined to apply most of our testing efforts at the unit test level and the least amount of effort at the UI level.
Not only does this help our teammates visualize where we should be (generally) applying specific types of tests is also shows the accepted set of testing tools that have been adopted for each layer.
Summary
While this is the roadmap we have defined for our company that does not imply it is necessarily the best roadmap for yours. However, you might find some useful ideas and/or approaches in our roadmap that can apply to your company. This is something we are still working toward and evolving. It’s likely to be an on-going process that never really ends. To that end, we do expect things to become easier as we get better with everything described above. As things get easier it is generally easier to drive adoption. The more adoption we get the more likely it is things will get easier, and so on…
I would love to hear from any of you (reading this) about your efforts toward enterprise quality. What has worked (or has not worked) for you and your organization? What tips might you share with the rest of us? Let us know in the comments below!
If you are interested in the presentation, you can download the PowerPoint slides here.
Great summary of a great QA vision! I like the terminology/concepts like “shift-left” and the test pyramid (another case of testing mostly earlier rather than later, in a slightly less temporal sense than shift-left).
Thank you for sharing – really interesting.
Can you share some of the metrics you used to track whether this initiative was worth the time and expense?
Other than the QA metrics available in Jenkins, are you tracking more business-focused numbers? (Things such as Lead time, defects discovered in Production, up-time etc.)