BlogShift-Left Testing Strategy: Involving Development and QA in Design

As I wrote in a previous blog post, the shift-left movement advocates moving software testing and quality assurance into earlier stages of your software development process to avoid and/or resolve problems sooner when it’s much less costly and time-consuming to do so. While the aspiration to test-early itself as a concept isn’t new, the movement has certainly prompted teams to see how they can improve their process, and that’s a good thing.

Why bring dev and QA into UX/UI design?

Generally, product managers and UX designers closely collaborate to align the user and business needs to features implemented in the software application. When representatives from development and QA are part of these conversations, their feedback can guide design options so they can be implemented and validated more efficiently.

Let’s talk about some specific risks that can be mitigated by involving developers and testers during design:

Risk #1: Designs that consume too much development time

When representatives from the development team are involved during the design review process, there are two intertwined benefits:

1. Feedback to make development more efficient: Seasoned developers are especially good at eye-balling features and planning out the implementation in their heads. If a design issue will cause an especially complex implementation, developers can identify this early, and the team can consider alternatives to avoid the problem altogether.

2. Developers can plan ahead: When a development team knows the features coming up, they can plan for them today…or at least be thinking about how to implement them in the near future. The additional preparation time often leads to smoother development.

Risk #2: Avoiding bugs before they’re bugs

QA / test engineers live to validate that features will function as intended, and an aspect of this is considering how to break features. So when designing an interface, it’s helpful to enlist the imagination of someone with this mindset. Granted, seasoned UX designers already avoid many problems by leveraging well-understood design patterns that prevent users from getting into trouble, but it’s still advantageous to have someone with a, “how could I break it?” mentality involved early in your process.

Risk #3: Get ahead of external dependencies

As product and UX plan out features, some may rely upon data or capabilities outside of the application. For instance, features may leverage an internal or third-party API, or data from a different system within the company’s infrastructure. Whatever the case, when development and QA know ahead of time of this dependency, they can build PoCs (proof of concept applications) that test whether the API provides the information as anticipated, and does so within your application’s desired performance specs. PoCs greatly reduce the risk that features designed today will encounter problems when the dev team implements them.

Benefit: Author test cases early

This last one is framed as a benefit instead of a risk: Involving developers and QA in design enables test cases to be written sooner. For example, at Planorama, as we deliver detailed user story documentation with our high-fidelity UX/UI designs, our QA engineers can deliver human-readable test cases that will address the positive and negative tests required for each feature. Below is an example snippet of a test case:

By thinking through the test cases up front, we have found that the development and QA teams consider how to validate functionality before any code is written. For instance, if development writes unit tests, this forethought positions them to write them more quickly, and that all key tests are coded. In addition, QA or software developers in test can code functional tests into a regression suite for ongoing validation of existing functionality as new features are built.

Wrapping up: Test early, test often

The oft quoted, “test early, test often” adage is accurate, but the resulting benefits sadly are not mentioned. Perhaps it should be extended: “test early, test often to reduce time for development, avoid bugs, prepare for external dependencies, and get all your tests written before development.”

While it’s true, perhaps it’s not as catchy as the original version after all.

Photo by Saksham Gangwar on Unsplash