Why You Shouldn’t Be Afraid to Grant Manual Tester Access to the Code
Granting testers an access to a project repository feels like a threat to some of the managers and developers. In this article, you will find out why it is worth to “risk” and how to avoid the problems when you decide to do so.
When testers want to automate their work
Let’s assume that your Quality Assurance specialists are excellent employees who never let you down – they simply know how to get the job done. Someday you find out that testers want to gain some new skills and learn how to automate their work. What they need from you is granting them access to the project repository. Now, what will you do?
As the manager reporting directly to the client, you may be terrified. What if it will cause delays? What if they destroy the whole project just with one click? As a developer, you may have different concerns. Will they ask me tons of questions that can be easily googled? Will I finish my work on time with such a ballast?
Before you start to panic, let me explain how it really works.
How it really works
Reasonable testers keep in mind that if something can be learned easily, they won’t engage others to help them. If not, they will try to pick the best time to ask for help, so they won’t distract developers, e.g. after a lunch or a meeting so devs don’t need to switch between context that much. For their own comfort, developers can set the rules of cooperation with QAs so they know how and when to ask questions.
If you are a QA and still have any questions or you are simply not sure what you should ask about, try to schedule a weekly meeting with a developer who shares your enthusiasm for self-development and knowledge sharing. Thanks to this your skills will grow systematically and you will be sure that both sides benefit from those meetings. Trust me, every developer would like to have a well-skilled, independent QA in a project. It’s the kind of investment that will pay off in transferring some of the responsibilities to testers faster than you may think.
NEED A SUCCESSFUL TEAM?
We’re 100% office based team with 7-years’ experience
in mobile & web app development
Of course, the work needs to be done by both sides. So if you’re a developer, try to be forgiving. Do you remember where you have started? If you do, you surely recall that being a beginner is not a piece of cake. If you really don’t feel like helping a tester in that specific moment, just say it clearly instead of giving false hopes and try to reach them when you will have some spare time.
In this matter, it’s crucial to work on the relations between testers and developers. As a part of the same team with a common goal to achieve, it’s important to make each other work easier because in the end, you are perceived as one.
How to avoid project’s complications
If you are a Project Manager, or QA team manager who lacks the technical background, you may be afraid that testers’ access to the code can ruin the project…
Well, there’s nothing to worry about if your project is well set up. If you have no idea about those things, just make sure with developers if the following items are covered:
✔️ Grant only the minimum required level of access to the repository. You should start from the “Read” permission so a tester can get familiar with the version control system and the project itself.
✔️ If you are using git and there is a need to rise permissions to “Write” level, make sure that a consistent and productive workflow is in place e.g. gitflow
Thanks to this you can easily disable direct commits into non-feature branches that prevent changes without a pull request.
✔️ Introduce Code Review to the QA team. This will boost collaboration between them. In the beginning, they can be guided by the developers working on that codebase. At a later stage, it can help become independent from them and in case something goes wrong, you can always type “git revert”.
✔️ Create a separate folder e.g. automation/ where all the QA branches are stored so they don’t get mixed with all the others.
Benefits for developers, testers, and for the whole project
Now, when you already know how to avoid any unwanted situations, let me tell you why it’s worth giving the testers access to the project repository. It can be a win-win solution, not only for QA, but also for developers, and for the whole project.
QA is able to learn automation
Testers need to check many different combinations to see if the feature actually works. Doing it manually takes lots of time. At some point, everyone starts to think about making it faster, and here comes automation. With tools like Espresso or XCTest, there’s no way to start automating without access to a repository. Of course, a tester can use tools provided by an IDE, like Android Studio Layout Inspector, to explore layouts while looking for matching ids and just use a different automation tool. However, sometimes Espresso/XCTest is the best one for your project and you shouldn’t take it away from you and your company just because of your fears.
Manual tester gains the ability to build the code
In many cases, QA needs to check how a screen behaves when different content is displayed. The best way to provide them independence is to show the place in the code and instruct what needs to be changed to run proper tests so they can make a build for their own use every time they need and do not disturb the developers too often. In the result, developers won’t be overloaded with additional work and QA won’t need to ask them to prepare mocked data or to change a single parameter and prepare a build for them a couple of times.
Manual tester becomes much more technical
While writing automation tests QA specialists need to get a basic understanding of how the application works from the technical point of view. Thanks to this, they are able to progressively understand the topics discussed by developers. The benefit from that is quite obvious. A tester, who gets more e.g. during a daily status meeting, will definitely have more accurate estimations because of their understanding of work that needs to be done during the implementation phase.
Furthermore, while a tester becomes more aware of the project, they can ask more detailed questions and know what needs to be additionally checked to avoid regression. Sometimes, without the gained knowledge and abilities, they would never imagine dependence between the two tasks.
You know now what are the benefits of having ambitious QA with access to the project repository. You are also aware of the proper project setup and you know what to do to make it actually work without any risks. What is left to say is that I really encourage you to not be a person who kills QA’s enthusiasm. Be smart and use the knowledge you have gained to make the development process better, smoother, and to give the members of your team the feeling of purpose.