Author: Rick Martin, Quality Engineering Practice Director & Principal Consultant
Unique Challenge
In a recent LinkedIn post, Bas Dijkstra shared insight from keynote address at Test Automation Days:
“The longer the time between writing the code and writing the tests, the more inefficient your automation will be.”
Considering I spend much of my time talking to clients and co-workers about the evolution of Software Quality Engineering and, after thinking about Dijkstra’s quote, I curated findings formed over three decades spent working in the space.
Bespoke Approach
Laws of Proximity for Software Quality Engineering
Like the laws of mathematics, there are tenets I accept, even if I can’t derive formal proof. Perhaps these are better characterized as hypotheses that can be tested by gathering data, observing the results and deriving insights.
Code Proximity
Whenever possible, automated tests belong in the same repository as the application being tested. This has significant ramifications for the language, tools and frameworks used to implement test automation.
The benefits are accessibility by the entire team and cross-pollination between those focused on writing the application and those focused on test automation. When a test is invalidated due to an intentional code change, we do not want to impede the remediation of the test because it is in a separate repo or different language.
Temporal Proximity
This gets to the heart of motivation for TDD/BDD. Incorporating acceptance criteria, or Conditions of Satisfaction as outlined by Mike Cohn, and automation into a Definition of Done is the first step, but we must hold the team accountable, not just the testers. The implication of temporal proximity is that application development and test automation are/should be tightly coupled. Both are components of the “corporate asset” under development. The product code’s future value is diminished without complementary test automation.
Organizational Proximity
Many organizations have transitioned to no longer having formal Test/QA teams or even titles, saying that “quality is a team responsibility”. As someone who has made a career in quality and test, I have mixed feelings. I agree, teams are responsible for the quality of their product, but regardless of if there is a title designating a quality/test role, there remains the need for one or more team members to focus on testing. Quality Engineering is an engineering discipline unto itself and requires the practitioner to be knowledgeable in software architecture, design and a variety of languages, as well as frameworks and tools.
Proven Impact
Unify Consulting understands that many organizations fail to realize that automated tests are corporate assets that complement the “product” code. Releasing code without automated tests is like serving two slices of bread with peanut butter between them with a jar of jelly and calling it a peanut butter and jelly sandwich.
Interested in a continued discussion on how leveraging the Laws of Proximity can help your development process? Contact Unify Consulting.
