I’ve previously talked about being a generalist with specialist tendencies. I’ve said I’ve generalized in just about everything but I’ve tried to specialize in quality assurance and testing as disciplines. But what does that actually mean? Let’s talk about that.

This post is very much going to be a stream of thought for me because I haven’t found the right way to put all these thoughts together into some sort of cohesive narrative. Much like in treating testing like fiction writing, I’m hoping to get thoughts out and then later edit and refine. I’m going to focus on at least what I think being a specialist means and I’m hoping that translates well into criteria for hiring such specialists.

The Biggest Problem I Often Have To Solve

One of the biggest problems I have to solve is getting people past a key thinking impasse. The challenge is that people get stuck feeling like they have to know everything before you can know anything. People have to become comfortable with the idea of partial knowledge and, as a specialist, providing that comfort is a large part of my role.

Beyond that, some of the biggest challenges I find in any group that is attempting to release a product or a service has to do with two things:

• Manage collaboration
• Manage communication

Most everything else is the application of thought applied via tools, whether that be issue tracking, burndown charts, automation, continuous builds, etc.

So, Given That …

As a specialist, what I’ve come to realize is that, as much as is possible and responsible, I have to work towards a single source of truth with built in traceability between elaborated business rules and the tests of those rules. This kind of thing occurs when decisions are being made rather than after they’ve been made. When you begin to move towards this approach, you can reduce one of the major killers of productivity: communication churn. What kills projects the most in my experience is missed information, ambiguous information, contradictory information, inconsistent information, micro-decisions based on incomplete information, and so on.

When these problems occur you end up with rework and duplicated work. You end up spending a lot of time determining which of the multiple “sources of truth” you have actually contains the truth. You spend a lot of time working from downstream artifacts (like source code) to figure out or understand the business rules of your product or service. You end up with team dynamics that foster islands of sophistication and reservoirs of knowledge.

As a specialist, my goal is to reduce sources of truth, reduce communication churn between project artifacts, and capture communication as examples that provide a shared notion of quality. This means I have to democratize test artifacts and, to some extent, the test process. The idea here is that not everyone is a tester, but rather that everyone does testing. Getting people to buy into that, however, requires some specialist thinking.

As a specialist I have to realize that testing is a design activity, not just an execution activity. To have any hope of quality assurance, you must have a shared understanding and expression of decisions related to quality. That shared understanding has to be empirical and demonstrable. Test specialists must have a means of encoding how they do this. I call this “being lucid” and it means having a through-line of knowledge about all decisions that impact quality.

As a specialist I have to promote and treat testing as a broad activity and put various test processes and artifacts at the most responsible moments. As a specialist, I must realize that “Quality Assurance” is not a team; it’s a function carried out by all teams to various degrees and with various levels of rigor.

That last point is somewhat important because quality assurance and testing are two different things. This contention leads to a very nuanced set of discussions, some of which I cover in my quality assurance category. As a specialist, I at least have to have a reasoned opinion on the matter, backed up by a certain amount of experience.

Specialist in Testing as Communication

I’ve talked before about how the primary purpose of testing is communication. That’s easy enough to say but, as as specialist in the discipline, what does it mean? This is a huge topic so I guess I’ll just cover what I’ve discovered about myself and what I look for in others.

In my view a specialist tester wants to impose order and structure to raw content in order to ease communication of that content to the largest possible audience.

In my view as a specialist, test design is done for one major purpose: to find and reveal information. Test design works to prove that a shared notion of quality has been collaborated upon and is capable of being reached. Test execution proves that the agreed upon quality has, in fact, been reached. There is one major reason for test execution: something that matters might fail to work in the way it was intended to work. The input to testing is collaboration and the output of testing is communication.

As a specialist, this means I must have be able to improve the quality and clarity of my team’s approach to creating test solutions. I need those test solutions to be in service of communication and collaboration first, execution second. And I must use test techniques that provide and effective and efficient basis for communication and collaboration. That being said, as a specialist, I’m keenly aware that there is no single best technique; there are only good techniques that have certain compromises. As a specialist, when I implement a technique, or promote the use of one, I need to consider the one that best suits the current needs with the least number of compromises that could cause problems.

Convince, Persuade, Visualize, Inform

As a specialist tester, I realize my test artifacts and results will often be required to convince and persuade. As such, I don’t want to have to face the fate of all presidential press secretaries, which is having to deny the obvious, deflect the embarrassing and minimize the negative. So, as a specialist, I need to have strategies for putting in place communication mechanisms that allow the obvious to be recognized early, to accept the embarrassing and use it as a learning experience, and to find the negative early enough such that it doesn’t have to be minimized, simply dealt with.

As a specialist tester who puts heavy emphasis on communication, I know the brain is tuned to respond better when it feels it’s in a conversation. So I have to know how to tell a story. I have to know how to center my testing — design and execution! — around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable. I know that testing is the steady and explicit evaluation of a product’s properties with respect to a shared understanding of what makes those properties valuable.

That said, I know that there are roughly twenty-two times the number of nerves from the eye to the brain as from the ear to the brain. So what is both seen and heard is remembered four times more than what is just seen or what is just heard. This means I must know how to incorporate visuals into whatever I am presenting. And even if I’m not presenting actual visuals, my stories (be they in the form of tests or not) must have a good chance of “painting a visual” in the minds of my readers and/or listeners. As a specialist, I also must know that this must be a two-way street, meaning that that when discussion and dialogue are added, you increase the ability for people to learn and retain.

As a specialist, my role is a coordinating role between the business facing teams and the technology facing teams by helping all of us use tests as a design, communication and execution mechanism. As a specialist, I’ve had to learn the good and bad approaches with TDD and BDD such that we can create test specifications to make sure that our tests are design-guiding, quality-oriented, and executable via automation. Specialists in particular must embrace this role by recognizing that adds value because the test specs can be used as a common resource by developers, testers, and the business teams. This, in fact, goes back to those points about communication and creating those visuals.

Specializing in Evangelizing Testing

Any evangelizing I do is in the macroscopic (i.e., multiple groups or the company) or the microscopic (within specific teams). Speaking to the team component first, teams define themselves by goals, working agreements, and motivation.

As a specialist tester with a broad focus towards evangelizing my discipline, I know that people have to be motivated, engaged, curious, and inspired to solve problems, draw conclusions, make evaluations and judgments, and generate new knowledge. If there’s a mantra I try to get people to live by it would be “Imagine. Experiment. Practice. Refine. Persist.”

But what does that mean practically speaking? It means that each and every tester must have a personal goal of becoming a credible, high-integrity reporter of information that people value. Any ideas and solutions they put forth must be demonstrable in the context of that goal. This shared goal unifies the team and allows evangelizing to received feedback from — and be backed up by — experience.

An ethic of elegance should operate in terms of graceful work, a service-oriented outlook toward your stakeholders, and a focus on what really matters to the organization. That said, as a specialist, I know that while you can strive for elegance, sometimes you shouldn’t. So this means I need to achieve the objectives I set out to with a level of capability that is possible rather than one based on a purist view of “what should be.”

Speaking to the multiple groups or company level, as a specialist I’m fully in agreement with a fail fast, blame slow, learn quickly culture. If lessons are being learned, and mistakes are being addressed quickly out in the open, then a culture of diligence and quality will be encouraged. That said, as a specialist, I have a large role in that based on the fact that my tests are a collaboration and communication mechanism.

As a specialist, I encourage teams and groups of teams to embrace uncertainty and respond quickly. Use the powerful flux of uncertainty as a shaping element, rather than as a destructive element. I encourage teams to create processes and approaches that are designed to teach and adjust. Particularly as this relates to test artifacts and a shared notion of quality, as a specialist I promote testing as allowing us to quickly respond to an ever-evolving environment and to deliver ongoing value early and often.

Have I Muddied The Waters?

I fear I have done a terrible job of talking about what being a specialist in the context of my career means to me. That said, I’ve done the best I can with my current ability to articulate these thoughts. Consider this a work in progress.

As you can probably tell, I approached this with a high-level view and ranged over a variety of topics, each of which contains many nuances in terms of thought and practice leadership. I focused very much on the “what” here and not the “how.” Obviously this is all very opinionated and slanted toward my own personal predilections, but I do believe there are some salient aspects here for looking for specialists, who must display not just a skill set but a particular mind set.