Helping Your Coworkers Get The Testing Picture

By Kate Paulk

The Gentle Art Of Training Your Manager

As the first tester in the organization, you may need to help your manager understand your ways of testing. There are many different mindsets about testing, and your manager may have one that differs from yours.

Because you are new to the organization, you are more likely to see certain aspects of the big picture than someone who has grown accustomed to the way things are done there. People who have worked in an organization for a time have often learned to ignore, or simply never considered, the way their processes fit in the organization's structure. Your unfamiliarity with the company may allow you to help refocus on the big picture. Understanding what the pain points are for your team and communicating those with your manager can help you do your job more effectively and get the results the organization needs, whatever those results might be.

Learning "Manager Speak"

The first and most important part of training your manager is to learn to communicate effectively with your manager. This includes asking what their priorities and expectations are, and how they prefer to communicate, and how often they like to have communication with you. You will need to adjust your communication style accordingly in order to minimise the likelihood of miscommunications occurring.

You may also need to reconsider how much detail you give your manager. Some people prefer to have all the details, while others would rather have a quick overview with the ability to pull more data when it’s needed or wanted.

When you speak with your manager, you should consider a few things:

Give the most important information first.  Be considerate of their time. Prioritize your communication based on the level of importance. If it’s really on fire, then try to catch them immediately. If it’s something that could wait for a normal catch up session, great. Don’t pop in every time something goes south. It could lead to them thinking everything is always on fire, and/or to micromanage, or it could lead to them not trusting you with your work. Either situation isn’t ideal. You do have some leeway as you’re ramping up. Figure out how much time that is even if it’s asking, how much time you have to ramp up.

Make sure you both mean the same thing when you use the same words. To most testers, "risk" means "likelihood a customer will find a bug I missed." To most managers, "risk" means "likelihood a problem with the software will cost the company money."

If you hear what sounds like a buzz word, ask whoever is using what they mean by it. Often an organization builds its own culture with specialized meanings for words you think you understand.

Make sure you remember to define your terms as well, or you could have people thinking you mean something entirely different.

Make sure your standards are in sync. When it comes to outcomes, you need to be very sure to find out what is considered acceptable and what is not, both for the business domain and the overall quality of deployed code.

Example: At my current workplace, data security is a big concern. I've been with them long enough to know that one person seeing data they should not access is a major issue, so I know to be very cautious about any scenario involving who should have access to what information. It took me some time to realize that what I was thinking of as edge cases could mean potentially thousands of dollars in fines and lost customers for my employer.

Remember that money talks. With very few exceptions, your manager will be talking to her managers in terms of cost, like how much the company has to pay and how much the company stands to earn. If the cost of X is greater than the benefit, X won't happen unless the cost of not having or doing X is even greater.

Remember that time equals money. At the highest levels of the company, people expect that by paying you and your team-mates for a certain period of time, they will get a product that will earn them more than it costs them to pay you.

Phrase what you want in business terms. Phrase needs in terms of saving time to get the same outcome, saving money to get the same outcome, or spending money or time to get a better outcome.

Learning new skills that can benefit you and the company falls into the general line of using Return on Investment (ROI) to justify your requests. Trying a new technique with the potential to mitigate a problem and overall cost the company less is a great example of ROI.

Never blame. State the facts, the undesirable outcomes, and your desired solution.  Remember that there might be more than one way to improve things. Be open to a suggestion or a modification of your idea. They could reject it outright, but at least you were able to mention it, and that’s a start.

Examples Of Speaking To Management

Some of my better experiences communicating with managers have involved me using variations of the approaches below. They will not always be accepted, but I have never seen a respectful approach together with meeting or exceeding the expectations of my managers fail. I may not get the answer I want, but I have often found my managers changing their perspective after some thought and with more experience of working with me.

The “I can do it or I have time to do the work” approach:

"Here are examples of some of the oversights I found in recent projects. If I worked with the product owner during the design phase, we might be able to save a lot of rework before the development team starts. This wouldn't create a hardship for me and my overall work load."

The “I’ve seen this before” approach:

"Based on defects we've previously generated, I've started a feature impact matrix I'd love to share with the developers and product owner. We might be able to avoid future defects by collaborating on it and expanding it together."

The “Best use of time” approach:

“I could spend a lot more time testing using light-weight test documents or examples, like the testing heuristics, instead of writing test cases which very few people read besides me. I could even write up my testing notes and add them directly to the story as part of the sign-off process. Could we use this small feature as an example? I promise my results will be the same, if not better!"

Why Would I Need To Train My Manager?

As the first tester in the organization, you're the person who gets to set expectations of what is and isn't reasonable. If you're lucky, your manager has worked with good testers before and all you'll need is to stay in communication so that they always know what you're doing.

If you're not so fortunate, your manager may not know what a typical tester's day is like, so you may need to try writing up a day-in-the-life log, or doing an experiment where you record all the time you spend on things other than testing. Point out things like:

Setup and teardown - Once your organization has cleared the low hanging fruit of easy-to-reproduce and easy-to-fix problems, you're going to spend a fair amount of time setting up to reproduce reported problems, investigating those problems, then cleaning up afterwards.

Managing test environments - Even if the test environment is your work computer, you're going to need to manage it. There's making sure you're running the correct version. Make sure you're testing against the correct server, keeping data sets that cover the common configurations you'll use, building data sets that cover the most common configurations, and etc.

Example: At one workplace I kept a separate directory for each version of the application I tested because customer-reported issues could come from any of a dozen or more versions.

Meetings - Even the least formal environment will have meetings.

Clumpy workflow - Just as developers don't get work in a steady flow, testing work won't come to you in a steady flow. You'll have times when you're scrambling to keep up, and other times when you have the leisure to investigate other things more deeply or catch up with your professional development.

Research - Tracing that odd event through the layers of application code to work out why it's not being saved the way it should be, searching for reported defects with the tools you're using… and more.

Documentation - Don’t just document your tests either. If my experience is any guide, a solo tester is likely to end up creating documentation for other testers about how the application works and what to watch for, up to and including use case and user story documentation along with database dictionaries. This can be extremely time-consuming, but somebody needs to do it, and in my experience testers tend to look at "somebody needs to do it" and say "I guess I'd better dig in."

Example: At my current workplace I've created database dictionaries, cross-referenced guides to inter- and intra-application dependencies, use case documents, user guides, and guides to using our internal tooling. These are all projects I worked on when I was less busy or when I needed to wait for long-running processes.

And so much more… I've found myself doing system and network administration (hopefully that won't happen to you), product documentation, backup product owner work, maintaining the application lifecycle management tooling, building build servers, plus a number of other things that don’t necessarily fall under the realm of testing. It helps to remember that your job description is just the start. If you can do it, there's a good chance that you will become the person who does it.

The Arcane Secrets Of Training Your Developers

As well as training your manager, as the first and/or only tester in the organization, you may find you need to train your developers for many of the same reasons. Again, if you're lucky there will be some developers in the company who have worked in environments where they collaborate with testers and expect you to be looking for ways to help them while you're asking them to help you.

Developers who are used to a stricter waterfall life-cycle can find it difficult to adjust to having a tester working closely with them. I've found it helps to approach them from the perspective of understanding their pressures and pain points so that you can help them and they can help you. After all, you all have the same goal: producing the best software possible within the constraints you're all facing together.

Why Do I Need To Train My Developers?

In an organization without testers, developers build communication and collaboration networks that don't involve testers. They're going to need to open those networks to you, but they're also going to need to accept that you'll use them differently. Sometimes this happens effortlessly. Sometimes it doesn't.

Tell Your Developers What You're Doing

While this section may seem similar to communications challenges I discussed in Part 2: Challenges With People, the focus here is more developer-centric.

Developers are going to have to get used to the idea of including you in the everyday loop. It can be hard and they probably won’t leave you out on purpose. Most of the time, it’s an oversight, or they didn’t think you would be interested. You're going to have to ask them to help you integrate, or remind them to include you in their meetings. One thing that makes a big difference is the way you communicate with your development team.

When you find an issue, describe what you're seeing and ask if that's what's supposed to happen. Even when it seems really obvious; be tactful. It’s possible you missed something starting the application or they missed something in the check-in and build process. Accidents and misunderstandings happen. Give people the benefit of the doubt first before you jump to a conclusion. Solving the problem is the important part, blaming someone for it should be secondary or not even in the equation.

Here are some examples of the way I communicate with developers before creating new issues or defects:

Build Centric: Could you check that all the changes for Issue X made it through? I'm not seeing any different behavior even after clearing cache and resetting my local system.

Feature Centric: Would you mind taking a look at what I'm doing with Feature Z when you have a chance? I'm not getting it to work and I don't know if I missed something, or if I'm just doing it wrong.

Dependency Centric: I’m seeing an issue with another feature even though it wasn’t directly related to your story, could you help me take a look to make sure we didn’t cause a regression of some kind?

Enhancement Centric: Is it possible to tweak what you did for Issue Y to do this instead of that? It's could be really irritating for our users if we leave it doing that.

"This" was a case of an on-change notification for every field on a page, which was precisely what the user story requested, but maddening for someone trying to change multiple fields on the page before saving. The developer agreed, and we changed the behavior and the user story. Don’t be afraid to request a change on behalf of the user if it doesn’t seem to work out or make sense.

The Lone Bug Wrangler

I've found that, as the first/only tester, I need to be a bit more detailed with my bug or defect reports than I would in an organization where the developers are accustomed to working with testers, particularly until they start to trust my judgment.

While all the suggestions are valuable for any tester, they're particularly valuable for the first/only tester because you're not just establishing your value as a new team member, you're establishing the value of testers to the organization as a whole.

Some of the ways I add detail to my bug or defect reports are:

If there's anything specific to the environment, include it. This includes the browser (for web applications), application version if relevant, and can include specifics like whether or not you had any other tools hooked in, or whether you were working in browser developer tools at the time.

If you were using specific credentials, include those. This includes things like if you're testing multi-tenant applications where all your company's customers are using the same database, you include the customer whose section of the site you were working in.

Application configuration settings. For desktop applications, this is relatively easy, where for web applications, particularly multi-tenanted ones, you may have to give login credentials, customer name, and path to the problem page.

If it's at all complicated, consider recording a short video and attaching it. I like Jing as a free screenshot and capture tool.

Include supporting evidence for what you expected to see. Maybe the problem isn't in the application but in the documentation.

Translating "Developer Speak"

Developers tend to communicate amongst themselves in a highly technical manner. For the problems they're solving, technical communication is the most efficient way to ensure everyone on the team has the information they need. This could have the unintended side-effect of making someone who doesn't communicate with them in their "language" feel like an outsider.

As a tester, chances are you tend to communicate in terms of impact to the user. This isn't necessarily a bad thing, but it can cause your development team to see you as an outsider and, potentially, hostile.

I've found there are several ways around the issue of vocabulary choice by marking out what could be thought of as "tribal" territory within a team. Some of them include:

Where it's feasible, use technical terminology and then suggest non-technical descriptions to use with end users or in application help documentation. This helps to position you as a translator between developers and everyone else.

State where you see your role as clearly as you can and repeat that statement whenever the need arises. You need your developers to see you as a collaborator in the production of high-quality software, and developers who haven't worked closely with testers in the past, are in my experience, more likely to be protective of what they see as their domain.

If you know and understand the technical terminology, don't be afraid to use it. If you don't, don't be afraid to learn, and don't be afraid to state things in the way that works best for you.

Rather than asking developers what a particular code construct is, ask what the implications are for your testing. This shifts your questions from things that could be interpreted as challenging or even hostile to requests for collaboration.

The Trials Of Translating To Team Members

Depending on how your employer structures the company, you may be interacting with other team members: business analysts, technical documentation specialists, or any of a number of other roles. For these team members, I've found a blend of the techniques used in helping managers and developers see the test perspective is helpful: taking the collaboration and inclusive aspect of the developer approach with the less technical aspect of communication with managers and leads.

As always, you'll want to start by establishing common ground, then building on your foundation, making sure that you and your team members are working from a common perspective.

How To Teach Without Really Teaching

When you're fitting into a team where you're the first tester in the company, you need to approach your team members with some care. The developers may have handled all the testing until then, or the business analysts. Or maybe the documentation team were responsible for testing.

Regardless, you are likely to be showing them different ways to handle testing, and that could easily cause issues.

Some of the techniques I've used include:

Be respectful. The testing performed by other team members may not be what you consider optimal, but it met the needs of the company until recently.

Look for ways to help. I've found that making my efficiency tricks available to other team members is a simple, freeway to gain respect in a team. If I create a list of how to configure a complex new feature as part of my testing, I'll hand that on to the other team members, so they don't run into the mistakes I've already made.

Ask and demonstrate rather than tell. If you ask people for help or demonstrate what you're doing, you will be more likely to get a better response than if you tell people what you're doing or what you want. For instance, if you're using test cases in any form, your style of writing them is more likely to be accepted if you ask your team members to review your test cases for scenarios you might have missed.

Patience, Grasshopper

No matter what your situation, it will take time for you and your team members to come to a working consensus. It could be only a matter of months, or you may need years to adjust your role as the solo test specialist to fully suit you.

But What About…

There are many other facets to being your company's first tester, and you may or may not encounter them in your journey with your employer.  You could find yourself trying to juggle the need to test the organization's software now with the need to introduce enough automated regression checks as the amount of regression checking you need to perform grows with each release. Or you could be in the position of unit test evangelist, helping your developers build unit tests for new functionality.

Every tester's journey is different, just as every organization is different. One thing you can be sure of, though: you will continue to learn and grow as a tester in ways that would be less likely if you were part of a larger testing group.

Where Can I Get Support?

Ministry of Testing - I use the Ministry site as a portal to The Dojo and The Club. The Ministry's Slack channel is also awesome.  

SQA Stack Exchange is a great place for specific questions

Jing is my favorite free tool for quickly getting screenshots and creating short screen-capture videos.

Working Effectively With Legacy Code by Michael Feathers is an excellent book about legacy code.