Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Leverage language: How to get testing into the conversation

public://webform/writeforus/profile-pictures/brendan-connolly.jpg
Brendan Connolly Quality Engineer, Procore Technologies
 

Traditionally, testers as a group have had neither the influence nor the authority to dictate the process or vocabulary of their teams. This leaves testers in the position of constantly needing to demonstrate value before advocating for a new practice or process. The challenge in testing is facilitating quality without the luxury of a role or title that implicitly grants influence or authority.

When it comes to teams, the working vocabulary is typically determined and framed by either influence or authority. This is visible in the transition of teams from waterfall to agile software development. Initially, an influential group of people united under the umbrella of the Agile Manifesto and demonstrated increased success delivering software. Later, via authority, management teams began more forcefully transitioning waterfall teams into agile methodologies.

Roles and titles aren't the only things that carry the influence and authority to effect change. Instead of trying to impose a test- or QA-centric view on teams from a position of relative weakness, "borrow" the power and influence already granted by team members by leveraging existing practices and concepts from other domains. Here's how.

Rebrand with the three C's

There are three steps—the three C's—that can guide you through this rebranding and repackaging process.

Comprehend the 'why'

This step should feel natural to testers. Good testing is always about seeking understanding. The product team usually provides the "what" of a feature, and the developers implement the "how."

Both those things are important, but a tester's focus is the "why." This is about understanding the relevance of the change, and it reaches beyond a single role. Why is this feature important to users? Why did the developer implement it this way? Why did the product manager want it this way?

It's about a holistic understanding. So, before you can sneak testing into a conversation, you need to know the audience, look for an analogous practice, and understand the testing's principles and benefits. 

Documenting test cases is usually about providing something that can be reviewed, either when things go wrong, or for training and other reasons. An analogous practice in development might be code review. By understanding code review, you see that developers review work as pieces are completed. There may be some up-front design discussion to serve as a strategy, but they aren't documenting what they might do. 

Code review isn't just about catching bugs; it's a chance to converse and share information and standards. It's about enabling other people to work in that area comfortably. Also, the comments and changes are often stored alongside the code for future review.

Co-opt from others

The next step is to co-opt code reviews and map your testing-centric process onto it. This might sound intimidating or maybe even a little subversive, but it's not a new concept. People constantly are inspired by things outside their immediate skill set.

Automated testing is something testers constantly hear about or work with. That concept did not originate in the software world; in fact, it's just one of many software development practices that have been heavily influenced by manufacturing processes.

Someone simply took a working example from a different domain and used the power of an accepted practice and working example to increase the chance it would be adopted. Rather than come up with a whole new vocabulary and then try to explain the terms, the concept, and why it will work, adherents can just say that it's like putting a robot on the assembly line and leverage existing credibility.

Now apply that to our testing problem. A test-review process modeled after the team's code-review process can allow testers to document their activities after testing a feature. This could then be discussed or shared, and linked to the user story for future reference.

Communicate and engage

Which leads to the last step. Simply use this common language to engage with your team. This, much like the "comprehend" step, is a major skill testers already have. Testers are constantly translating among technical, product, domain, and industry concepts to disparate groups.

As a real-world example, consider that you're on a team where testers write test cases while a feature is being developed, and those tests are executed upon the code's completion. You hate the test cases because they fall out of date quickly and because they rarely match what you actually test. 

With good language and process to support a change, what might have been misconstrued as complaining now has an actionable solution.

Break down the barriers

Beyond addressing the immediate issue, you now have a deeper understanding of testing that grants more insight. It's one less wall between roles, and that insight can enable deeper and more effective communication—granting testers even greater influence over quality.

Keep learning

Read more articles about: App Dev & TestingTesting