Excellence in nearly any engineering initiative depends on appropriate balance between interests in execution and interests in discovery. At the same time it pays to deliver efficient solutions with as little overhead as possible, it also pays not only to adjust when new information becomes available but also to seek opportunities out to gather that information proactively.

It's not enough to insist on just one: excellence requires that discovery and execution work hand-in-hand. Without appropriate balance between interests involving the two, engineering sacrifices achieving tangible results in exchange for posting metrics that may or may not reflect the initiative having achieved excellence.

The same ways this is true with Software Development, it is also true with Software QA, Analysis, and Test Automation. Especially in times where expansive adoption of Artificial Intelligence (AI) has increased the complexity, opacity, and volume of work product, the viability of the balance between interests in discovery and execution (in addition to dedicated customer focus) is what will continue to separate the results enjoyed by market leaders from those experienced by ambitious competitors.

In Addition to Visibility, Clarity Depends on Vision.

The most important benefit Software Development Organizations gain from the execution of tests (manual, automated, or otherwise) is visibility into the current functional state of work product. Test execution does this by producing data and feedback related to how a solution is behaving right now.

What Software Development Organizations depend on testing for more than just visibility. They depend the data and feedback produced through the right testing to solve a particular problem relevant to higher-level organizational needs -- both serviceably and efficiently. They depend on foresight in the development of automation and tooling adaptable to future needs (perhaps unforeseen in initial development), to make components open to independent evaluation, or open to upgrading or porting at some later point. They also depend on skilled testing practitioners to help teams and organizations understand which outputs are valuable from the point of view of relevant stakeholders. And they depend on test planning artifacts to help communicate that -- now and in the future.

In terms of both how organizations approach testing and the results they intend to get from it, clarity depends on insight, foresight, and perspective.

Without vision both for the sorts of outcomes and value testing and analysis can provide and for the sorts of problems an organization intends to solve with them, organizations run the risk of mission creep, operational bloat, unexpected need for rework, and customer frustration.

I Help Software Development Organizations Find the Clarity They Are Testing For.

For an approach to Software Testing and Analysis that prioritizes balance between execution and discovery, as well as vision for engineering solutions to clearly-defined testing problems with excellence, there is no substitute for an expert with a strong track record.

Currently I provide services related to software testing, test automation, and analysis through Upstream Consulting LLC.

It Can Help to Start with Good Questions.

In many ways, questions can be a useful starting point to understand more. They can be useful to frame lines of inquiry for test plans, they can serve as a means of introspecting our best understanding of what we intend to build, and they can serve as a starting point to explore knowns and unknowns.

Oftentimes, the organizations I work with also have questions they would like to start with. Many of the questions they have look like these:

• For the amount of time we invest in executing- and maintaining e2e regression suites, why do so few tests either catch actual product issues or even report clearly what went wrong when tests fail?
• Is there a way to reduce the amount of time it takes e2e UI test suites to execute (in a manner that experience shows also increases test stability)?
• Why do our automated tests flake as much as they do? What should be done either to ensure they are prepared to execute more consistently or to make them report proactively in case of an issue that affects test integrity?
• We have a custom test automation framework that does a lot complex work to determine how output should be evaluated given a set of discreet workflows. Is there a reason why tests built using this framework do not execute consistently?
• Not too long ago we assigned work to a full-stack software engineer to develop a new test automation framework. Now we are blocked trying to update dependencies for the framework due to dependency coupling. How can we get past this, and is there an approach to framework design that will reduce the likelihood of dependency coupling?
• We have a complicated legacy feature set we are interested in determining how to test, but with the number of user workflows it presents, it would take a test engineer years to execute a full regression or figure out what is actually worth testing. How can we develop a strategy to test this functionality (efficiently) so that we can release with confidence?
• In our organization we find that user acceptance testing is constantly a bottleneck, because testers can't seem to keep up with the developers and product owners whenever they need to adjust. How can we speed up QA so that we can get functionality shipped more quickly?

It Can Also Help to Start from A Point of Common Understanding.

I provide insights into the sorts of questions I ask (and how I explore answers to them) in the blog on this site.

I am available for contact via the contact form on this site, or as well as via LinkedIn.