Six Takeaways From Working With QA
In the early days of my career as a web developer, testing the final products often played a secondary role and never really got me to the point where I said that I’m very fond of doing it — until the day I got to meet and work with dedicated QA engineers for the first time, where this journey suddenly began to change.
To keep things simple, I’ll be using the term tester from now on when referring to the various quality-related testing roles as a whole.
It was the beginning of an auspicious looking day in spring some years ago, a day I wouldn’t forget that quickly, as a new colleague was about to join the team. Not just any colleague — a professional tester!
I didn’t know what to expect. My excitement was accompanied by a little bit of nervousness; much like pets must feel when they are randomly put together to figure themselves and their habitats out in a new, unexplored environment.
Slowly but steadily, requests came in to test my work and take over tasks — tasks I used to be in charge of. These included feature and release planning, client communication when it came to outlining incomplete, unclear or unreasonable specifications, and of course quality assurance and control.
As already mentioned, the idea of testing the same things over and over again seemed very unspectacular and boring to me back then. Still, as time went by, I eventually got more and more interested in what this tester’s job was all about. Therefore, and without further ado, I decided to immerse myself in this subject and started to examine and obtain insights into what a typical test day looks like.
After all, who tests the testers?
Working on multiple projects of various sizes and with different clients has given me a rough understanding of how much time and effort was needed to meet specific product quality guidelines from the start of a project to its end, and even beyond. Nevertheless, this new collaboration started to reveal a lot more of the various testing approaches, processes, and techniques to me as I was evidently only scratching the surface of thorough testing.
Besides, I began to feel more comfortable, relaxed and confident when writing new code, but also more secure and protected when knowing that another unique mindset and pair of eyes would always verify and validate my work afterwards.
A tester is a developer’s first line of defense.
These are things I’m very grateful for today, which is why, whenever I’m referring to testers or the QA department in general, I like to relate to it as a developer’s personal and first line of defense. So-called highly-valued insurance for things that could go wrong when a new feature is released to the world and its people.
Roles and responsibilities did change, and so have I. Because of my previously gained experience as a “self-proclaimed tester,” it took me a while to figure out the right pace in this new working relationship. I was somehow still crossing territories by testing my work rather than handing it over sooner and entrusting my previous responsibilities to the ever hungry tester next to me.
While reorganizing and refocusing on the core tasks of a software engineer, the tester’s perspective and fresh way of thinking helped me a lot in becoming a better developer overall. One of many examples is the fact that I write more resilient code that withstands real user scenarios rather than code that is written for drawn-out artificial test cases, which is how I went about things in earlier days.
Furthermore, establishing direct communication channels for quick and continuous feedback during feature development has helped optimize these new workflows even more so, and continues to stand today.
A positive sign that my little experiment was starting to bear first fruits!
Maintaining a healthy and friendly relationship — especially between us developers and testers — is crucial to performing successfully as a team. It’s one thing to be able to count on a tester to find potential problems in my code. Still, at the same time, I would like to provide a stress-free and transparent testing experience instead of having the tester deal unforeseeable bugs and broken features.
This relationship could also be compared to the philosophy of yin and yang and its opposing forces. On the one hand, both are pursuing their own goals with the developer working on the product and the tester ensuring the product’s quality, while, on the other hand, both are complementing each other and working towards a common purpose — a high-quality product.
Unfortunately, the reality can look different, and developers and testers sometimes tend to get into a conflict of interest, whether it’s due to mixed responsibilities, misconceptions, the frustration of each other’s work, laziness, lack of motivation or resilience to change.
Blaming the tester for things that aren’t working correctly “anymore” often seems to be the more convenient way to go rather than admitting your own mistakes. Instead, we need to get into the way of thinking that testers are our allies in fighting for smoother product releases and are by no means here to crush our dreams of bug-free code, but to get us there eventually one day!
Thanks for making me a better developer, one Pull Request at a time!
Mistakes will inevitably happen along the way, but they are something we can take advantage of by learning from them, rather than continuing to live on in a state of denial. When a tester reports an issue, we should be willing to listen to what went wrong and reflect on our work to improve in the future.
Granted, it’s not always easy to do so and not an everyday occurrence that you thank someone for telling you that your efforts are not enough. That’s why it’s even more inspiring to see when people are doing so and give credit where credit is due. Just take your time, and say it out loud— testers will appreciate it the same way as developers would!
We have to be fair, transparent, welcoming, and always constructive so that we can learn from these mistakes and treat them as an opportunity to take responsibility and ownership for making it better next time.
Developers and testers play an equally essential role in what we are trying to achieve when it comes to delivering a well-functioning application on time; a goal that’s quite hard to reach without a certain level of trust.
When you hear that your development team feels under fire “in the middle of a World War” because of QA, something might be off and worth addressing. One of the reasons that caused this particular situation is the fact that testers can get very happy about opening Pandora’s box and finding the source of all bugs; almost appearing to be a tiny bit spiteful about it.
There is nothing wrong with showing and sharing this excitement in the first place. However, I think that the way in which these discoveries are communicated could, if not done carefully, become a tightrope walk between succeeding as a team or not. Bugs are hopefully and solely getting called out for the sake of driving the development process and not to point out a developer’s mistake. If not, the consequences could have a severe impact on the working relationship and its underlying trust.
Testers, on the flip side, should be able to depend on developers’ code not being written carelessly because “someone else would still take another look at it anyway before it goes live.” At the time of requesting testing resources, the required information should already be available so that appropriate testing measures can be applied. I have, for example, caught myself dozens of times expecting a tester to go through the most obscure flows without me explaining the ins and outs, which is a no-no.
Nonetheless, I still believe that putting a reasonable amount of faith and trust in each other’s capabilities gives us this speed and confidence boost in moving forward faster, together. It’s these small things we have to watch out for and try to avoid to fully benefit from in the long run.
While trust can be good, control shouldn’t be left out of this equation entirely. There are situations where you might be in doubt and just want to make sure that something will be or has been done the right way to help out whenever and wherever necessary. As mentioned before, I see developers and testers working in a very complimentary way with each other’s competence areas crossing each other from time to time to reach this goal.
It’s fair to say that based on my previous notion of typical testing activities, one could think they’re little more than a drop in the ocean. In reality, there is much more going on behind the scenes, one of them being allowing testers to develop a common sense for all the product’s peculiarities over time, which not many people within a project usually get to see and know about.
Have you, for example, ever found yourself in rough waters where a specification didn’t make much sense? New user flows were overwhelming and inconsistent? Or a feature that appeared to be broken turned out to be intentional in the end? Testers are the ones that come to the rescue!
Be it a tester’s level of awareness or attention to detail for product, team, or really any other related topic, asking them for their advice has always resulted in excellent and very informative conversations for me.
Having someone close with this kind of in-depth experience is of high-value and provides more confidence in navigating through the product, especially when knowledge in a broader context is required. Whether for feature, user experience, and ultimately quality-related questions and concerns, the whole team can benefit from QA.
Preserving a flawless collaboration between us also ideally means to understand each other’s roles and impact on the product. It starts from sharing the love for cookies of any kind, the usage of similar tool sets in a development and testing environment, and, last but not least, the involvement in their respective processes.
Whether we are talking about errors, defects, or failures, it’s always good to get an idea of what a tester’s daily routine looks like, what a testing process consists of and how we can engage when it comes to usability testing, code reviews or test-automation.
Here at Parkside, developers and testers (among other roles) have the opportunity to meet and sit together in weekly scheduled Communities of Practice to share their experiences, techniques, and other useful topics from their worlds.
Knowing the basics alone often gives you the flexibility of thinking outside the box and preparation for possible edge cases ahead. Therefore, investing in a shared base of knowledge should always be an essential part of such highly-dynamic and cross-functional team compositions.
Working with testers from all over the world has broadened my horizons in many ways, strengthened my soft & hard skills as a software developer as well as a person. Moreover, my interest in wanting to learn more about it has been growing ever since — an ongoing experience I wouldn’t want to miss out on anymore today.
Fortunately, I’ve always been surrounded by testers who make me feel they have my back at all times, and the sooner developers start to realize and understand these synergies, the better the outcomes. Showing appreciation for each other’s accomplishments is as important as being honest, unbiased and realistic about things that didn’t go so well to improve ourselves and to make this an evolving, enjoyable and worthwhile working relationship. In the end, we are all in the same boat with the common goal of shipping high-quality and bug-free products to our clients. We’re better together!