Sometimes, during your daily project routine, you ask yourself, what am I doing here, and do the others on the team know what I’m actually doing? As a tester, I have asked myself this question before, and I have put together some of my thoughts. In the following post, you will find some anecdotes from my life as a tester.
Daily
Another day, another daily, and I as a tester wonder how to favorably present the specification of test cases today, as work done, current work, and future work. Usually, I say “I specified test cases for the user story xyz and will continue doing that”, or something to that effect. Rather monotonous, and often cause for a condescending smile, but this is in fact the main task during the first days of a sprint. After all, I, as a tester, am the one laying the foundation for the proper testing of current user stories.
Things get more exciting when I report that I am now running test cases as well, proud to have verified an error here and there. But pride is really the wrong word in this context. It all depends on the developers, the current mood in the team, the priority of the error, or the tester’s (i.e. my) self-confidence. Sometimes I just kind of mumble the word “bug” and then let someone else take the floor. But why be so reticent, really?
As a tester, I am responsible for pointing out if the software does not work as defined. And that is a good thing. How are we supposed to deliver high-quality software if we do not accept that mistakes happen, and that they cause stressful situations or conflicts? Have courage—the error does not disappear if you do not address it (on the contrary, it gets worse the longer you wait to fix it), and it can easily be forgotten in the jumble of the daily development work if it is simply pinned to the task board between the major user stories.
Regression testing/test automation
Speaking of the task board: This is a good tool for keeping an eye on the user stories with the tasks they contain and the progress made during the current sprint. If you take the time to stop and consider the work in the team with the help of the task board over a period of weeks or even months, you could come to the following conclusion: The developers work with shiny new tools, and the testers dig through the dirt of the past, always looking at all the glossy new things. That does not mean that I as a tester am not aware that the developers also have to adapt existing code and fix bugs from time to time. But as a tester, I have a very different perspective. Despite all the automated tests that our developers write, I have to keep track of everything that is affected by any changes made, i.e. I keep looking back at the relics of the past while the programmer forges ahead.
And this is where the greatest challenge in my everyday work comes in: regression testing. Although this can be automated as well, the tools for that are not always kind to me. If I do not use them from the start, I am continuously busy chasing the changes made by the developers. But even if I use them from the start, I have to use them on the UI level to fulfill my tasks, which is tedious and, unfortunately, prone to errors as well. Some thoughts on this:
Test automation tools suggest that I can automate testing simply by recording test steps. Unfortunately, my initial enthusiasm is replaced with the realization that this is not enough because my test records usually do not persist for more than a day. So let us try something new: This time, we program, leaving the recording tools behind. Immediately, new obstacles appear. I am not good at programming, and now I have to deal with some cryptic things. And the next idea is born: Use the developers’ experience. Again, there are limits to this idea because it usually only works as long as the developer has time and is willing to do this. Which is understandable, considering that the developer wants to create something new.
So I am torn: Do I write automated tests, or do I do everything manually? I definitely need to plan for regression tests. Whether they turn out to be automated, manual, or exploratory depends on a wide variety of parameters. For me, at least, test case automation is no cure-all. I appreciate the value of automated test cases that can be done in every sprint: greater test coverage, less manual testing of defined work flows. But test case automation by itself is no cure-all because it cannot replace my experience as a tester, and the corresponding ability to “think outside the box”.
Conclusion
In any case, testing as such—be it manual testing, regression testing or test automation—should be acknowledged within the team, and everybody should work together on the quality assurance. Otherwise, the tester will quickly start to feel like an outsider, not a part of the team, if their work is not taken seriously.
This post was written by:
