By Gareth Waterhouse and Melissa Eaden
So, what do testers do? And why is it important to understand this for better teamwork?
To better be able to work in teams, as testers we need to understand what it is we do and also be in a confident position to explain what we do to others. You will most likely come up with your own versions for your own situation. Here are some concepts to get you started.
Testers Can Prevent Bad Things
Testers have a developed sense, at times, when something might go wrong with the software or even with their own development team. It comes from a deep understanding of the domain they work in and the environment they have been placed in. When testers are involved with story development and ideas, they can pinpoint where possible issues could happen in the software. They could even prevent those issues simply by explaining their thoughts to the developer or group. If they understand the changes that were made to the code base, they can anticipate problems based on previous issues, knowledge of the technology stack they are working with and even knowledge of the interactions between different parts of the software and/or hardware.
Testers Demonstrate A Unique Understanding Of How Things Work
Testers have an overarching view of the product from design to the end user. We can have the opportunity to influence a piece of software all the way through from the concept to the final product. It's a pretty powerful position to be in, and one in which we can offer a lot of value.
Testers Are Advocates For The Users And The Business
Testers care. We care about the users of the application as well as understanding the what the business needs are for the organization or company we work with. We can achieve this by being involved in the very beginning of the development lifecycle (Shift-Left) and by testing as the user (UAT/Exploratory Testing). We shift left to find bugs in requirements, and we test as the user using the application because if it doesn't work well, then we can't help but feel we have failed.
Testers Can Be As Technical Or Analytical As The Job Requires
Testers need to be more technical than ever before. What defines how technical you have to be is the role that you were hired for. Were you hired to be technical, or were you hired to be more analytical, or be a guide for the team from a testing perspective? Your personal skillset matters. Testers should always work on expanding their skillsets whether they are technical skills or analytical ones.
So, now that we have some clarity about what testers do, how can we work in efficient and wondrous ways with other team members? And what kind of things should we be avoid.
Let's have a look...
To The Good: How Software Testers Offer Value
Testers don't have to write code, but by pairing with the dev, and getting them to talk through their code we can spot mistakes or variables which could cause problems. It also ensures the developer has more clarity on what his/her code is doing and what goal it's trying to achieve.
Paired testing is also useful because it involves working closely with someone else, often on a single computer and doing some testing together. One person can drive while the other can suggest what they do.
Doing paired testing for someone new in the team is a great way to introduce them to a product and bring new ideas on board. You can take them on a journey of testing the software together. They can ask questions, and you can learn how someone new to the system might approach the application.
It may also help to have two testers on the team, who consistently find different types of bugs, by pairing together you can learn about each other's testing techniques/styles. Paired testing is a great way of learning new features and learning how others test.
A very stripped down version of pair testing is when there is a new feature to test, the testers in the team both write down their test ideas/techniques for the feature on their own, they can then swap and use the ideas that the other tester has written to drive out some more ideas/techniques, and eventually you end up with an awesome suite of tests/techniques!
Acceptance Test Driven Development
Acceptance Test Driven Development (ATDD)has a similarities with pair testing. Testers pair with developers to create the acceptance tests first and then developers implement their code using the acceptance tests. Developers run the acceptance tests until they can make failed tests pass..
This collaboration encourages and helps keep code clean and simple using the acceptance tests to meet the requirements. It allows for transparency into the development process and can be used to minimize defects before application code is written.
Three Amigos/Love Triangle/Three Musketeers
"Three Amigos" involves a business analyst/product owner, a developer and a tester all coming together and reviewing anything that have been created for the project. As a group they ask any questions and define a clear view of what is being developed.
This type of group is best formed at the very beginning of the development process. They would oversee and have input from the initial planning stages all the way through release. They could be the group that does demo acceptance or actively organizes and directs the workflow. The general idea, by forming a group like this for projects, allows different points of view and mindsets involved, which can mitigate issues later in the development cycle.
The "Three Amigos" can be most effective when reviewing stories from backlogs, design specifications and business logic.
Peer reviews can be reviews of just about anything involving the project. Not just of the implementation/actual code, but any unit, integration or acceptance tests (manual or automated).
A review could reveal some process that might need a deep dive or further explanation. For example, if you've written automation, then it would be a good idea to do a deep dive session with the team. Walk them through it, and help them understand what it's doing, so they don't assume your automation is covering something it's not.
Examples of other things that can be reviewed besides code are, test cases, charters, business logic, design workflows, color palettes, documentation related to the project, wiki information, any kind of report that gives information to team members and stakeholders, and so on. Basically anything you wrote, tested, or created could and should be reviewed by other individuals before given to the intended audience. This not only helps with clarity of ideas, it also give the whole team a chance for input.
Regardless if you are working in an agile environment, waterfall or v-model, demos are an invaluable way of demonstrating the work that has been completed, and how it is helping the team deliver on their goals (whatever those may be).
It's useful if someone on the team drives the demo, and shows the stakeholders (be it product owner, business analyst, business team) what work has been completed. They can then open the floor up for any questions, talk about any bugs that they found, or just give reassurances to the stakeholders that the team is on track in delivering their goal. Product demos can also easily be created and recorded for virtual consumption. It can be a great tool for remote teams to learn or as a great informational resource to review at a later date.
Mobbing involves everyone on the team contributing and giving instructions to someone who is driving the keyboard. It's great practice because it works with absolutely anyone in the software development process such as, UX, developers, BAs, testers, project managers. The whole team can be involved and it's an effective way of spreading the knowledge and learning from others.
Workshops & Talks
If you've found something really awesome on the web, or at a meetup that you want to share with the team, why not book a workshop or a brown bag session with the rest of the team.
For example, if you've read about mob testing, and want to try it out, work with the team and do a workshop or talk on what it is, why it's useful and then do it! You'll find a lot of people are more willing to try new techniques once they try it and see the value in it.
Breaking The Bad: Changing Habits For The Better
We've looked at activity based things testers can do and get involved in to offer value, but what about the habitual aspect? What can we do on a day-to-day basis to offer value?
There are many things we can do as a matter of habit. The following examples are not a comprehensive list, but rather guidelines and practices which can be used in your day-to-day work with teams of all configurations and sizes.
B+ (Be Positive)
We are going to start with something that sounds extremely obvious, but it can be difficult to practice, especially in the role that we play, and that is to be positive.
You may be saying that I'm a tester, why does it matter if I'm positive? And if it does matter, how can I "be more positive"?
A tester can have the most amazing skillset and all the attributes needed to be great, but without a positive attitude, then it is all for nothing. Being positive is great in a team environment, and can help you bring value from day one. Positivity is contagious, and if one person is contagious it will rub off on others on the team. A positive team is a happy team, and a happy team is a productive team!
People are also more likely to listen to someone who is positive rather than someone who just moans and is in general negative. Being positive is key when you have to persuade someone that the bug you've found is important or that you need a bit more time to test something.
How can you be more positive? This one is a bit difficult to answer as it can vary from person to person, but I find that reflection is a great way to be positive. If you reflect on the good things that have happened during the day, it will help you remember all the good things and you'll find that more good happens than you'd think.
Finally, look at problems as opportunities or challenges that you need to overcome. Going to people with solutions to problems rather than just problems is invaluable and will be greatly appreciated.
Pharrell said it best, and it may sound obvious, but being happy and smiling will spread to others in the team and as mentioned above, a happy team is a productive team.
Sometimes people can be happy because they are productive, but the difficult thing is being happy when you aren't being as productive as you might like to be. You may not have released something for a while, and if you find yourself in this situation, then similar to being positive, reflect, hold a retrospective and look at what isn't working and find out ways you can improve.,
Why is being happy important? Apart from helping the team be productive it can also make people want to talk with you or want to divulge information. A large part of testing is about finding information or sharing information. This can help you be a better tester as well as bring more value to the team!
Happiness can also be a team activity. Make sure to contribute to the happiness and wellbeing of your team. Having consideration, empathy and support between team members can make or break a teamwork situation. Everyone has rough days at the office. The best thing about working as a team is not feeling alone when those days happen. Support and respect your team members and they will do the same for you.
Sharing Is Caring
When you read an awesome blog post, or find out about a new tool or technology that you've learned. By sharing this with the team you're showing them that not only are you a keen learner, but that you want to help them learn and achieve team goals. Use your favorite tool to communicate and make sharing easier. If it's something that should be shared for future collaborators or new employees, make sure it is posted and saved to a shared drive or a wiki page.
Be Open To New Things
In order to really offer value, in a truly effective, cross functional team, we should be willing to get our hands dirty. Do not say "It's not my job," if someone asks you to do something that will bring value to the team. If you try the task and need help, that's OK, but at least you tried to complete it. People will be more appreciative if you try.
This will help the team towards achieving their goal, as well as help you learn some new things, so it's definitely a case of "Win-Win!"
When talking about respect we can look at it with regards to respect inside the team and with regards to respect outside the team.
By doing most of the things mentioned above you will hopefully end up with respect. Not just people respecting you, but being respectful of others. They're two very different things, and achieved in different ways.
People respecting you will come over time Once you start contributing to the team goal, and once you start showing your value in the many ways discussed here, it will ultimately end with gaining the respect of your peers within the team.
The respect which you give others will also help you earn respect. Being respectful of others can involve listening to their opinions, the tone and language you use when talking to people as well as offering constructive criticism to people who come to you with an idea or suggestion.
Why is respect important? If people don't respect you, or if you don't respect others then your job will be ultimately 100x harder. People will not listen to you, they will not take you seriously and they will not share knowledge or information with you, which will hinder you and your team's progress in working towards the team's goal(s).
Trust usually has to be earned. Trust can come with your job title, but in some cases it will come through time spent within the team and offering value on a consistent basis. How can someone build trust within a team environment?
One excellent way is to lead by example. If you show your team that you trust them, then your team will be more likely to trust you. Another way is to be open with your communication. If you are honest and open, then it will help build trust within the team and outside the team as well.
Committing to the team goal(s) will also help with the trust aspect. If your team members see you committed, then they will trust you can do everything to the best of your ability to reach a goal.
Why do we need to worry about trust? Similar to respect, a team with no trust is going to find it a hundred times more difficult to reach their goals. IF you're second guessing people's work, or everyone is unmotivated as a result of the lack of trust, then they're just not going to be performing well.
A key theme in this article is communication. A large portion of issues boil down to communication, or more importantly a lack of. As a tester involved from concept to final product, we can communicate issues or future issues at a number of stages, it's important to do this in an open and honest way. It's also important to consider how we say things, consider these 2 approaches:
"I don't think this is working how it's supposed to be, it's doing X rather than Y"
As opposed to:
"This isn't working"
Which one offers more value to the person you are communicating with? If we can provide the necessary information in our opening statement, we will immediately offer value from the beginning.
Also, it's important to consider when to use tools to communicate (IM, Email) or when a good old fashioned face-to-face conversation is needed.
Enjoy What You Do
Have a passion and enjoyment for the work you are doing. When you lack these essential things for a project or even a job, it can cause issues with the team dynamic. We all have to work on the less glamorous and the less fun parts of the job, but having a good attitude about it and sharing it with your team can be tremendous for team morale.
Commiserate with your team. Nothing says team members have to be happy all the time. Take that negative feeling and try to flip it back to something positive for the team. Whether that's doing a team activity, talking about the situation that has the team upset, or taking the team out for lunch, make sure the whole team is involved. Empathy and listening allows your team to see the positive in the negative. This allows for everybody to enjoy what they do, even if the team has hit a few bumps along the way.
We Are Human
Remember, we are human, the people we work with are human, and so we need to treat them as such. They are not coding monkeys, just like we are not testing machines, we all work differently together. We all need help, and if someone comes to you asking for help, then you need to realise that they have come to you for one reason or another. may be that they feel they can depend on you, or that they respect you, but it's important that you help them as much as you can.
Make friends with the team, and you'll find your role and the journey to complete team goals a whole lot easier. People will be more willing to help their friends, and also they will work harder for you.
The Ugly: What to Avoid In Teamwork
We've predominantly focused on what we can do as testers to offer value, but what about what we shouldn't do...
Blame Game - Don't Play It
It's important to not play the blame game. We're all in this together. In doing so you will earn the respect of others. If you make a mistake, look at why you made the mistake and learn from it. The same goes for anyone else on the team.
If someone else makes a mistake, don't attack them for it, or blame them, help resolve the issue. The absolute worse thing you can do is let issues in the development cycle be solely owned by one team member. Offer to help. Offer to get coffee. Offer, at the very minimum, your support and confidence in their abilities and trust them to keep doing their job.
No I in Team
There is no I in team, we work together to achieve the team goal, we do whatever it takes. There is a nice three letter acronym, GTD, which stands for "Get Things Done" which applies nicely to working in a team. Working in isolation, or working on some automated test suite that is simply amazing is not, in the long run, going to bring value to the team. Involve the team in your work, and they can help and appreciate the value it brings. They can help you improve it in the long run and thus make it more sustainable and more maintainable going forward!
As you can see these are all linked in so many different ways, there is no quick and easy fix. It comes down to the fact that we are human. Different people react differently to different scenarios. Every team is different. What works for one team might not work for others.
You aren't going to be able to start putting everything mentioned into practice right away. It will take baby steps. Pick out the important ones to you, the ones that you think you can start practicing or doing, and take it from there. It may be that you decide to start with communication. Be it on a social lunch, or through review sessions and asking questions, you'll want to implement new things only as fast as a team can adapt to them.. The goal is to help the team deliver on their goals in any way that you can. If you notice something isn't working, don't be afraid to suggest something different and help the team on their journey of continuous improvement.
Metrics Can Be Tough
Missing something big or having the whole team miss an issue that goes to production is a hard day for a lot of development teams. It's especially hard when those issues are core functionality or core business functionality, like selling tickets or updating documents, or saving vital information that can't be reproduced. Mistakes happen and during retrospectives, often metrics can be very stark about pinpointing those mistakes.
In the business world, people want to have someone take the blame for failures. Sometimes it's founded, other times it's less so. Metrics can be used to create the story around the failure.
The worse way to use metrics on releases, would be to measure defects reported per tester, before release or after the release. Defects should be considered in a bigger picture and defects should also measure the health of a project.
Also, the complexity of a project should be taken into account when looking at metrics. We are humans after all, and humans can't always predict what other humans will do with a product. Developers and testers can work together to on accountability for defects, but management shouldn't focus on defects alone to assess the quality of the team's work or progress.
Whether you or your team are determined to have made a critical error, don't panic. First, help fix the issues, analyze what went wrong, and then adopted a team practice to hopefully mitigate the issue for next time.
Teamwork Makes It Better
For software testers, working alone can become the default setting even if you are on a team. Remember, you are never actually alone on a project. Keep in mind the other people you are collaborating with and reach out for help or implement some of the practices and suggestions above.
Being the lone wolf or superhero of the hour may seem great for a while, but eventually, that does come back to haunt you if things on your team, or your project, take a turn for the worse.
Be involved, be proactive, be cooperative, and be the team member you would like to work with. Be the model of a good team member, and hopefully your team members will recognize it and work together, with you, to develop teamwork practices.
About Gareth Waterhouse
Gareth has spent more than nine years of his life involved in testing, testing in a number of domains (e-commerce, insurance, education, finance). He is currently a Lead QA Engineer for a major fashion e-tailer. He is a proud father of two, and is most definitely a family man.