Do software testers break stuff?
One of the most widespread urban legends about tester’s work is that they basically "break stuff". I bet you've heard that one before; when someone from quality assurance says that "we may have some concerns", and the response is "what did you break this time?". This is related to the bread and butter in the software development process - testers try to spot errors and bugs that may or may not appear in the project. A project that took time and resources to develop, and makes the developers attached or even proud of it.
So it is sometimes hard for the creators to understand why something does not work as it should and phrases like "it was working fine until you tangled with it!" or "nobody will use this in that way, and now you broke it!" are a form of defense mechanism. The truth is that software doesn't break on its own; it simply does what it has been designed and coded for. Testers’ task is to investigate, look at what the system does, how it will perform under any circumstances, actions, and various scenarios that often drift from the perfect path. An honest response would be: "we didn't break your stuff, it was already broken, but we will show you where, and how we got there".
"Nothin' personal, kid"
The key to professional interactions in the team is to avoid personal attacks in the communication; especially at the daily meetings or standups. It doesn't matter if you don't like a particular developer, or a tester is picky. The best solution is to remain calm, stick to the topic, and do everything you can to make the team communication as seamless as possible. And never mix the personal comments (like who took whose parking spot) with the professional ones. Speaking of mixing, try to avoid bugging your colleagues about issues during their breaks. Everybody needs their time off, even for 5 minutes. How would it feel if the developer/tester approached you during your lunch break and started to ask you if you had tested/fixed that one task from Jira? Collywobbles guaranteed.
Devil’s in the details
A key to good understanding is being specific, avoiding generalizations like "it just won't work", not shift-blaming the others ("it was not tested/developed properly!") and being respectful. Something you find hilarious may be interpreted as offensive and cause a situation when this person doesn’t want to work with you anymore or even take revenge in the least expected moment. Obviously, such situations don’t develop the right team spirit.
To make things more complex, words aren’t the only factor that matter. The thing that we do not always control (even if we try to stay as calm as we can about that one issue that is looming large in our minds) is our body language and non-verbal communication. Our body can send an entirely different message than the things we're saying. Don’t be surprised if a member of your team reacts to you nervously if you look away or avoid eye contact during conversation. Be patient, treat others with respect; they are human beings after all. No matter how annoying they can be.
"I was born ready"
How many times did you forget what you had done the day before? It is commonplace after a long an eventful weekend. You may not remember what happened over those few days, but you have your issue and time tracking software to keep that important stuff in check. Take a moment to remind yourself what you did last time, and what issues you were working on. At least have your tasks open.
This is why it is always important to make detailed descriptions and comments on the issues and tasks. Imagine that you were on an especially wild trip and you woke up 5 minutes before your meeting (luckily you were clever enough to take your computer with you). You're looking for something to put on in panic (visual required, bummer), you open your task and you see "Add a description…", and the title of the task states "Issue with a problem", and you look in terror that you had logged over 32 hours in it. This will be hard to recall, and that wasn't the only task you were working on…
Coping with “issue with a problem”
Sometimes you won't be the only person to work on that task. Oftentimes you will move to the other project, and someone else will take your place. Some issues may come back during the development process, and someone may look for answers to their problems in the older tasks. What if you will encounter an "issue with a problem" and you will try to look for answers in the past tickets, only to notice that someone didn't take the time to describe anything (works for stack overflow as well).
That's why it's crucial to describe and include as many details as possible - you may remember every single detail now, but you don't know if you or somebody else may ever need to use it again. To avoid these "works on my machine" moments, make sure that you're using the correct environment, your software is up to date, and your description is spotless and understandable to any member of your team (even if they never have seen the code before).
Friendly fire and collateral damage
One needs to take into consideration that things may not be as they seem to be. There is always the other side of the coin, and we may not be (and probably aren’t) perceiving the word the same way as the other side does. The development process is an operation that includes information going back and forth. Take a moment to understand the other point of view. Something that is obvious to you, may not be crystal clear to the other members of the team, and vice versa. We may not understand why this issue is so important to our colleagues, and why that pesky project manager is saying that "this is the bottleneck of the project", and we need to get going as ASAP as possible. The least you can do is to try to understand their position. After all, we share a common goal - development of the product, and we're playing on the same team and we want to create the best possible solution. Together. If we all try to go against each other, the project will suffer or even fail, and that’s the outcome that nobody wants. Really.
How to improve team communication?
To sum up, It's not that hard after all. The first step is to acknowledge that despite our differences, and other specializations we share a common goal and any action against others may incapacitate the whole project. Put our personal issues and dramas aside, and work together as a team. Going further, listen to each other, walk a mile in someone else's shoes and try to understand other points of view - this is a dialog - speak up! Use empathy to avoid conflicts.
If everything else fails, seek guidance and help from other members, like project manager - using a mediator is fine! We all want what’s best for the project. Be prepared, make sure you understood another party correctly, don't be afraid to ask questions; it is better to measure twice and cut once. Concentrate on important things, be professional and respect others and if everything else fails - keep in mind that no matter what - we're in this together, and it's up to us to make this experience good, and the project delivered and working - on any machine, not only mine.