by Kate Paulk
You've aced the interview and accepted an offer for a testing position with an awesome company, but you'll be the first tester they've ever hired. You're not just the test lead, you're the entire testing department.
There's so much to do. Where do you even start?
When there are no other testers to help you find your feet, you’ll need to look elsewhere to get the information you need. The local testing community is a good start, If there's one available. There are great online resources which can help as well. However, you are the one that will decide what testing looks like for your company. You are setting the standard which any other tester coming in will have to follow or live up to. The following 4-part series is a guide for managing and developing the testing practice as a company’s or department’s only tester.
System Setups & Access Requests
You're probably done with the usual administrative things and dealt with the slight problem of nobody knowing what to do with you. Hopefully, you’ve figured out how to log onto your computer, and if you're lucky, you might get the same rights and class of system as a developer.
If you're not so lucky, well… here are some of the things you might need to arrange for:
You will need administrative rights on your machine. It's almost impossible to test really well when you're locked out of system logs, tool installations, and so forth.
If there are test environments, you need administrative access to them. If there aren't any, you need to start the process of creating them or having them created, including explaining why they're needed.
If there are mobile labs, request access to those.
Request access to development and delivery pipelines. You're part of the delivery process now, so you need access to it.
If the application uses a database, request database access. Data handling and its integrity is part of testing. Having database access could allow you to catch data issues much earlier in the development process. If you're not comfortable with having write access, read-only access will keep you from doing any accidental damage.
If you're working with customer-reported issues, you'll need access to the customer reporting system so you can look for details and search for related issues. It’s also nice to know who spoke with the customer. If clarification is needed, you have the contact information to ask more questions or request more specific data to help resolve the problem.
You may also need to demonstrate that you can be trusted with high levels of access. Some of the people at your new employer might think testers are people who only write and follow scripts rather than see them as skilled IT professionals.
This process of requesting a lot of access can cause a security panic for some companies. Some people may understand why you need administrative rights to your machine, others won’t, especially if no one else has administrative rights.
Be kind, be patient, and above all, make friends with the security, DevOps, and internal IT departments in your company. Folks in those areas can move your requests along or stall them until there is no point of continuing to try.
The Discovery Process
Initially, you’ll want to integrate into the current process, no matter how odd it seems to you. The company adopted the processes and ceremonies for good reasons. Until you learn the current process, you won't know how much of it still works for the team.
After you familiarize yourself with the application, team processes, and business rules, you might have more questions than answers.
There are a number of conversations, depending on your situation, you should have while you're discovering how your new company and its software works. Here are some common discoveries or conversations which might come up while you are exploring your position as a lone tester.
Why Do You Do This?
No matter how strange or nonsensical your new employer's practices might seem to you, they always started for a good reason and probably worked when they were first implemented. It’s possible the reason those practices started isn't an issue anymore and inertia has kept them in place. Or maybe there is a valid reason and you just haven't seen it yet. Regardless, it's important to understand the reasons for a process or practice before you try to change it.
Understanding The Software
Testing software without understanding the ecosystem and constraints is a recipe for frustration. You’ll need to learn the application's limitations, what it does and doesn't accept and why, and what it talks with and how it talks to it. This should be one of your first conversations after you start, and you should be focusing on the 5 Ws + H:
Who uses the software? Are they trained users or anyone who happens to browse to the site?
What problem does the software solve for its users?
When do users use the software? Are there activity peaks that a server needs to handle? Maintenance windows? Downtimes?
Where is the software used? Is it business-to-business? Industry-specific? Recreational? Business-to-client?
Why do people use this software? Are there competitors in the domain? This question will lead you towards the key functions and features of the software, something you're going to need to focus on.
How does the technology stack work for this application? The back-end interactions can have a lot of impact on what the front-end of an application can and can't do. The better the lone tester understands those interactions, the more value they can provide to their team.
Understanding The Process
You will want to fit into the current development process as soon as possible. While testers can act as agents of change within an organization, we can't do this unless our managers and our teams trust our judgment.
Discuss how things are done with your manager and coworkers. Define where in that process you fit in. As the company's first tester, you may be working towards the end of a waterfall lifecycle, or joining a company that's in transition from waterfall to agile. You could also find yourself in an "agile-but" situation where the company says they are agile but what's happening is actually waterfall in small cycles. Or you could be in a truly agile situation. I've seen all of these scenarios, and all of them are challenging.
Regardless of what the current process is, you will need to start by fitting in with it, by asking to join or watch any regular meetings or ceremonies that are currently in place, so you can better understand how things are done. You may find resistance to the idea of a tester being involved more in the process, since just by attending you are changing the process in a small way.
An Experience Example
If you can't get permission to sit in on the planning meetings, go over the requirements you're given, and ask lots of questions. In particular, ask about how the feature is going to work with other parts of the system. Try to stay calm and professional while asking sensitive questions. Accepting a tester's findings can be difficult for developers who have never had testers effectively critiquing their work.
Once you've got a reasonable grasp of the software, you're going to start asking questions that expose holes and flawed assumptions that will force a lot of rework. This is when your manager is going to be more open to you being involved in the process earlier. It will likely happen after you've demonstrated that you can give valuable insight and advice.
Building a list of pros and cons to demonstrate the value you can provide is a good way to prepare for talking with your manager, or whoever runs the process, about being involved earlier. When the pros (backed by evidence) outweigh the cons of a tester being more involved, that's the time to take the list in and ask.
Set expectations early and reset them often. You’ll need to meet those expectations as much as possible even if they don’t make much sense. Over time, you can change perceptions and expectations based on results and trust. Once they understand more about what the tester role can do, and should deliver, it will become routine and you might find that you can expand your own role into other testing specialties. Rushing the process is not a good idea. Waiting for the right moments and setting your coworkers' expectations will give you better results over time.
I find it helps to remind myself that a lot of organizations and people still think of testing as something anyone can do if they have a detailed enough script to work from - and there are many, many testers who work in these environments.
Start by filling the metaphorical box you're put in, then overflow it by doing what's expected and adding activities that will add a lot more value than writing and following detailed scripts. If your manager wants to evaluate you on how many bug reports you create, you’ll probably need to do the bug reports until you can comfortably move the needle away from odd metrics to something which addresses business goals or business values.
To Bug Track Or Not To Bug Track
You were probably hired with the expectation that you would report any problems you find in some kind of defined format. A bug tracking tool or application lifecycle management app may have been mentioned.
The question of whether you should or should not report everything in a tool is a different one altogether and may cause some discussions with your team.
What you should aim for will depend on your team, but as a general rule, if you can get immediate or near immediate turnaround from your developers, you don't need to report it. Updating the story with a comment is a good practice when handling defects in this manner. Handling defects in this way can help to build trust with your team.
Depending on how things are organized and how often new software is released, large projects may push partial functionality to test and warn you that parts of it aren't done yet, avoid reporting on those. If this is the case, your developers will appreciate you taking their advice on when the feature is ready for testing. They'll also appreciate you asking if a problem you run into is something they're actively working on before you create a bug report.
If there are defect report templates, it makes sense to start with these, and gradually move the team's expectations towards something lighter and more flexible. Your new team may have regulatory reasons for their requirements. It helps to find out why they want the format and documentation levels they're asking for, then find ways to provide that level of documentation in a way that works for you and the rest of the team. For example, things like one line test cases for exploratory session documents linked to your user stories and tracked in the system go a long way to reassuring your team while you are slowly changing the testing process to something more flexible.
Getting Past The Basics
You've moved past the basics and you're working with your new employer's software, fitting yourself into their processes, and generally finding your feet. It won't be long before you start moving past simply scrambling to keep up with the flood of new information that comes with any new position.
The next three installments of Blazing New Trails will cover some of the common challenges the first tester in a company can face. They offer some suggestions to move past a basic understanding of your role on a team to handling more advanced challenges of a lone tester.
Where Can I Get Support?
SQA Stack Exchange is a great place for specific questions
Kate Paulk refers to herself as a chaos magnet, because if software is going to go wrong, it will go wrong for her. She stumbles over edge cases without trying, accidentally summons demonic entities, and is a shameless geek girl of the science fiction and fantasy variety, with a strange sense of humor.