Many testers work as the only tester in their company. Lone testers have a lot of control over their jobs and daily activities, a freedom that is quite attractive. Yet, they need to establish boundaries with coworkers, routines within their own workflow, and methods so they can accomplish the variety of tasks required in their jobs.
Setting effective boundaries can be a difficult task for anybody, especially someone who is the only person doing their job at their company. After all, every ask seems like it might be important, and there is certainly more work to do than can be done by one person. So, the lone tester needs to learn to say “no”. It’s harder than it sounds. The first step is to make your work visible. Since the work of the lone tester rarely makes the kanban board or sprint — especially testing tasks like automation or exploratory testing — testers must make their work visible.
How? You can ask for your own work tracking alongside developers in whatever tool your company uses. You can roll your own kanban style board on or near your workspace with post-it notes and poster board – cheap, large, and colorful can also be effective. Or you can create a shared document in Google docs or another doc-sharing service, and even post that doc as your update in your company’s preferred chat tool. Increased transparency may not decrease unreasonable asks of your time, but it does give visibility into all of your responsibilities, especially those not directly related to feature development, making it easier to set boundaries.
Get TestRail FREE for 30 days!
How do you deal with those unreasonable asks even after you have made your workload visible for all? Use skillful negotiation. F.A.S.T. skills, from Dialectical Behavioral Therapy (DBT), are helpful for setting and maintaining boundaries, even for healthy individuals who are not in need of therapy!
“F” means being fair to yourself and the other person while discussing a situation.
“A” means (no) Apologies. So, if you are the person who needs to say no because you have another work item that is a higher priority, do so unapologetically. You cannot possibly do everything, and it is okay to say “no” without apologizing. In fact, DBT practitioners note that apologies become less meaningful if they are used too frequently.
“S” is to stick to your values. As you negotiate a boundary or set a boundary, stick to your personal values. It is easy to agree to bend when we feel pressured, but what are you giving up to give someone else what they want? Make sure that you set boundaries according to your values so that you maintain balance between your work life and the rest of your life.
Finally, “T” is to be truthful. When setting a boundary, there is no need to lie about why you cannot do something. If you always seem to have an excuse, people may lose respect for you. However, if you set a boundary, and it is demonstrable that you are indeed busy with other work, you maintain your truth and integrity.
Making tasks visible not only helps in setting boundaries, it makes routines and workflows clear. Unlike other members of the company, the lone tester has nobody else to meet with or fall back on. To survive and thrive, you need to know the engineering routines and workflows, and then make decisions about how your work will relate to these processes. For example, even though the dev team might work in two week sprints, you may decide that working in one-week sprints helps you to maintain your work on an automated test suite, in addition to work testing features.
In a CI/CD environment, you might ditch a sprint and adopt a much more flexible workflow to accommodate rapid-fire development and release schedules. These cycles may require a lot of context switching, or switching back and forth between different tasks, in a quick succession. While some testers feel comfortable with constant context switching, many can find this exhausting. Understanding where you are and figuring out how much context switching you can handle in a workday will hopefully help you establish good working habits for yourself as you navigate testing for an entire team.
As the lone tester, it is incredibly tempting to set a large number of goals that are very lofty, in order to attempt to meet the needs of the team. Further, failing to meet one or several goals, personally or professionally, can have a profound impact on your well-being. The key to setting professional goals and maintaining personal integrity is to set manageable goals that can be broken down into smaller steps, and tracked easily as they are achieved.
In controlled environments where measurability is important and the task is well-defined, S.M.A.R.T. goals are helpful tools. S.M.A.R.T. goals are Specific, Measurable, Attainable, Relevant, and Time-Based. A google search yields several articles about working with S.M.A.R.T. goals in time-bound and task-specific situations.
In situations where goals are to be more lofty, Forbes magazine contributor and author of Hard Goals Mark Murphy notes that goals that are intended to revolutionize a space, innovate, or break boundaries may also need to break the S.M.A.R.T. format. So, if your goals involve more innovative work in your environment or doing something that is new, consider setting goals that push slightly beyond what you believe you are capable of doing. Choosing the right kind of goal to set can help you focus on what you need to do today for team, and what you need to do to get to where you want to be in your testing career.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
If you are the only tester at your organization, know that you are not alone – there are many people who face similar challenges at their jobs, and are building successful careers in environments where they are the sole test professionals. Use the tools outlined in this article – make your workload visible and clear, set and maintain boundaries, be smart about your goals – and you can be sure that whatever challenges you face are surmountable.
If you need some additional support, feel free to ask questions or share your experiences in the comments section below.
This is a guest posting by Jess Ingrassellino. Jess is a software engineer in New York. She has perused interests in music, writing, teaching, technology, art and philosophy. She is the founder of TeachCode.org
Help us improve this page!
What problem are you trying to solve?
Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.
Organizations need conceptual and QA has crucial strengths to effect that change. Here are three winning action plans to change your QA culture and integrate it with the rest of your SDLC.
DevOps implementation involves shifting the attitude of not only QA but all roles in a team. This takes a considerable amount of effort!