Live from Vancouver … It’s Saturday … Day?

The weather is lovely outside, similar to Fall in the Southern United States, but I spent yesterday inside with 22 other passionate testers at TestRetreatYVR. (Initial post found on the AST blog but I’ll into more depth here.)

As the resident TestRetreat social butterfly, I made sure to introduce myself to all the new faces, although some of us already knew each other from the internet. It’s always nice to put a face to all the Twitter handles in the tester world. After a leisurely breakfast, we began to settle into business mode, which is actually pretty casual for a group of this size.

As per the usual, I came with some ideas rolling around in my head, but I didn’t have a formal plan until I got up in front of the group to pitch them. I settled on a couple of topics: Doing What You’re Told and Building Community in Testing. After hearing the pitches of other attendees, we decided to combine our forces to address these topics along with 2 other ideas, What is limiting your agency? and Personal branding respectively.

Agency vs Doing What You’re Told

Jesse Alford mentioned that he has often heard people say they cannot follow up on a particular suggestion he made when discussing real world problems in testing on the job. He is interested in what limits people’s sense of agency, or being able to be the change they want to see in the world. I felt this related strongly to my interest in the balance between testing as you are requested to work and using our professional judgment to recommend or simply execute appropriate testing. We had several other collaborators join us to explore these topics.

Although I often prefer live-tweeting sessions, I wasn’t sure how we would structure this conversation. We all gathered around a table to discuss these ideas as peers, bringing our diverse experiences. When I lost wifi early in the conversation, I switched to drawing a mindmap on a large piece of easel paper. I find this technique very helpful for visualizing connections as well as helping me to focus on the conversation as it flows. While that may sound strange to some, my own research into teaching and facilitation approaches indicates that other learners find it helpful to keep their hands busy so their minds can be clear.

First, Doing What You’re Told. If we view testing as a service provided to a business, then a business may request various types of testing, effectively buying a requested unit of testing work. The request will vary with contextual variables such as product scope, release cadence, and release purpose. A business wanting to release a minimum viable product (MVP) version of a feature or application has different concerns from a business that has built up an inventory of value ready to deliver that is not yet deployed. In the case of an MVP, the business is looking to explore the market for a particular solution in a problem space. When the concern is idle inventory, the long feedback loop may be related to cost of delay or lack of value realized in a system flow. These motivators are quite different although each has the same desired outcome: deploy a tested set of software features. These requests may address different risk profiles, including the need for both internal and external feedback on quality and value. (We could do a Mary Had a Little Lamb on MVP… but let’s stay focused on this session.)

What do you do when your professional judgment is that a business request doesn’t make sense? For example, some industries are regulated with standards and compliance concerns. While these definitions are often vague, the way a company chooses to satisfy them is very concrete. Auditors may have particular requirements or expectations that influence what testers do to provide early feedback about the viability of software implemmentations. However, I have heard from testers in the regulated space that an audit can be a negotiation about how to satisfy a regulation (problem) rather than a mandate of using a particular set of processes and metrics (solution). Sometimes the mandate comes from within a company. In that case, what can a tester do to provide valuable information? When the pressure is focused on counting some form of testing work, one option is to use session-based test management (SBTM) rather than manual step-by-step test cases.

What’s constrains your agency?

Jesse’s question about agency dovetailed nicely here. Many testers have reasons that a particular approach cannot work for them in their particular situation. Some broad categories of concerns include inexperience with the proposed way of working, organizational hierarchy control, and motivation.

Inexperience can affect perception of a situation in both the problem statement and in the proposed solution. Sometimes the way we frame a problem limits the solution options we can see, i.e. “Why don’t you just …” For example, if we frame a testing problem as visual validation of a feature and then insist that Behavior-Driven Development (BDD) automation is the way to go, we may box ourselves into the corner of heavily imperative Gherkin scenarios. Alternatively, if we stated the problem of visual validation as automation-tool-supported, we could consider approval testing as a way to quickly detect changes while preserving the element of human judgment that helps us to make progress toward quality without maintaining brittle automation scripts. This may satisfy an organizational constraint such as “100% automation” in a way that empowers people while automating the boring stuff (i.e. visual inspection of every screen component).

Some testers work in an environment of strong command and control from the organizational hierarchy. These testers may live with concerns of being fussed at, e.g. you signed off on this release yet we discovered bugs in production. People higher up the organizational ladder may use their power in negative ways (e.g. sociopathic games) or in positive ways (e.g. sponsoring junior team members to develop talent). An official “open door” policy may indicate that employees were told to trust one another rather than earning trust through their behavior. Let’s say you buy into the policy and speak to someone above your boss’ level. Although you may be simply sharing ideas or asking for information, this activity can be misconstrued as undermining your boss.

Dependency on others could take many forms. This may disproportionately affect the “frozen middle” levels of management who may not feel in control. These managers may have the ability to remove obstacles to providing testing value but not recognize the opportunities. When we form the problem statement in a way that doesn’t make us feel safe to act, we can lose motivation to solve it. Our emotions heavily influence our perception of what we can do. If we feel threatened or fearful, we may spend energy on resisting change. However, when we are willing to be self-questioning, we can recognize when we really can make a difference and choose how to act. Through reflection, we can act effectively with integrity.

One way we can try to reconcile what we’re told to do and what we may choose to do is pairing with our colleagues. This provides a dedicated period of time to ask about the intent of the request. In some contexts, no one tells you what to do, so you may pair with someone else motivated to solve this particular problem. When you choose to work this way all the time (i.e. 100% of your work hours), you can overcome physical separation, whether with colleagues in the same location or working remotely. Pairs can achieve a high level of flow though constant exchange of information and quick feedback on ideas as well as solutions. Some of these solutions may be non-testing mitigation of risks.

We only had an hour together to dig into this rich topic, but it definitely has me thinking. In the end, we should remember that software development is a relatively young industry. Sofware testing as a specialization is even younger. Making room for good testing work involves both hearing what you are told and using your judgment about what you can do in your context to accomplish the goal. We can try small experiments in how we work to see what improvements we can make without asking permission. #SorryNotSorry

Well this has turned out to be a longer and more serious post than usual… I’ll tackle community and personal branding in a follow-up post.