I hope you donât mind me posting another question. Iâm hearing a lot about companies following the Spotify model with squads, tribes, chapters and guilds. Which one of these would a communities of practice apply to?
The most challenging thing I have found in building a CoP is getting people to buy into. Not just the members, but those outside of it. This is time that is outside of a project or something similar, so there is the challenge of will people have both capacity to do it, and been allowed to by various levels of management? There is also knowing if people will be interested to attend or be involved, even if they have the time available?
This can be helped by âsellingâ the benefits of the CoP, which can be pitched differently for those inside the community versus outside. You could have a catchy pitch to get those into the first session, with the first session explaining in more detail why it exists, how it will help and what it will achieve. You could also give a more formal presentation to those with influence outside the community such as managers, in a format that theyâre more used to. Myself and two other people gave a presentation with slides to our senior managers, explaining what a CoP is and isnât, showing the differences between it and a meeting, as well as helping them see how it will give a tremendous benefit for only 1 hour a fortnight per person.
As for the follow up comment, whilst a CoP can benefit from a retro, I would have it separated from the QA retro (though Iâm curious what it is about QA that means it gets itâs down retro?). But sending out reminder e-mails is good, as people can easily agree to something and then forget about it, or think that they will go to it, only to realise theyâre double booked.
Hopefully that answers your question, but feel free to reply and seek clarification if not 
The worst thing can be actually getting it started. You can have an idea of what you want to do, who will turn up, and what will happen. But often expectation and reality can differ. Researching how the initial session can go will help, but people could ask questions or want to do things that you never expected. You might have your first session ready to go, but no-one turns up. You might want to start, but canât find a meeting room big enough to hold everyone (which I have had), as they get booked months in advance due to how rare the slots are.
Iâd say there are no downsides to having one, but depending on what the community is about, and how the company is structured, they might not find much benefit from it.
Weirdly, companies which are in traditional waterfall silos, where people from the same role/department spend time together and are co-located, but donât get to interact much with others roles, get less from a CoP. This is because theyâre easily able to share ideas with one another, know what ways of working theyâre doing, and keep up to date with things.
Whereas for agile companies/teams, because people with similar skills/roles are split across lots of different teams, and whilst the agile team is co-located and collaborates together, they donât interact as much with people outside their team, a CoP offers more. One set of testers might be struggling to find the best way to test something, but by raising it in the CoP they could find out another team had a similar problem and then can share how they solved it.
Hopefully that answers your question, but feel free to reply and seek clarification if not
Now, this is a tricky and wide set of questions!
I would recommend having a goal/aim for the community, but as you suggest, I would recommend the community decide it.
An initial aim might help decide who should be involved with your community to start with. If making a Test CoP, you might not want to include developers even though they perform unit tests. Or, you might want them in, because they do unit tests, and to broaden the testing skill across teams.
I would advise your goals are built to the SMART model:
- Specific
- Measurable
- Achievable
- Realistic
- Timely
So if you said we want to get all 50 testers completely fluent in using automation in a month, it would be M and T, it wouldnât likely be Achievable or Realistic, and arguable not Specific enough (which automation tool/language?).
But, if it was to get 50 testers to be able to build and run a Selenium script without support over the next 12 months, that could be SMART.
As for goals changing, they can and likely will change. Once your have achieved your goal, the community can see if there is a new goal they want to work towards, and if not, then they might want to think should the CoP be disbanded? It isnât a failure for one to stop, especially if it achieved what it wanted to do. Even if it is a case of taking a break for a few months, the community might find there are things they can set as a new goal, and restart the CoP again.
Hopefully that answers your question, but feel free to reply and seek clarification if not
Without being there to see how they both work and interact, I would tentatively say yes, they should have their own CoPâs. They are practitioners of different things, and that is the key thing to remember for a CoP - It is easy to remember it is a Community, but it is the Practice that can be easy to fall down on.
Whilst quality is the responsibility of everyone, there can be a difference in how the groups achieve that. Do the testers want to know how all the code is written? Do the devs want to know what boundary value analysis is, or a decision matrix? As those are things that each community could be focusing on, using extremely broad examples.
One thing I would do with both CoPâs, is challenge them as to WHY they exist? I talked about that in the video, but if neither of them know why they exist, what their goals and vision is, then should they exist? Or do they exist for the wrong reason?
Hopefully that answers your question, but feel free to reply and seek clarification if not
1 Like
I canât see why you couldnât use the Club, or either of the Slack groups (https://www.ministryoftesting.com/slack_invite and https://www.ministryoftesting.com/testers_chat_invite) to discuss ideas. Depending on what you want to discuss, it might be things which are good for testers in general, not just for CoPs/Guilds to discuss ideas.
Is there anything that comes to mind you want to discuss, or is it more a case of knowing that it is available for when you need it?
Hopefully that answers your question, but feel free to reply and seek clarification if not
No, but the reason is Iâve accepted that we each have our different experiences and skills. If someone knows things I donât in a field I want to know more of, they havenât gained that knowledge by stealing it from me. It isnât a zero-sum event where only one of us can learn about Exploratory Testing, for example. Instead, I could find out if there is a way I could learn from that person, whether it be from them mentoring, sharing their experiences in the CoP, running a workshop, whatever works for them to help the knowledge be spread around.
It is easy for us to think weâre imposters, and that one day we will be found out that we shouldnât be testers (or any other role weâre doing), and we will be fired. The fact youâre asking questions in the AMA format shows that even if you donât know something, youâre willing to learn, and that means you are NOT an imposter.
Hopefully that answers your question, but feel free to reply and seek clarification if not
Not about CoPâs and about me, but Iâll answer it.
What keeps me in testing is I feel as though I have found my niche. I enjoy being given a set of requirements, where they say they want something to do X, and then thinking all the ways it canât or shouldnât do that, and then proving it. I find it more interesting and appealing than writing code, and as I keep learning new things and ways to disprove what something should do, it helps me teach others too.
What keeps you in testing?
Hopefully that answers your question, but feel free to reply and seek clarification if not
Honestly, I wouldnât have agile play a part of it. It is a way of working, but not necessarily a way of learning and experience sharing. Some of the tenets of the agile principles fit, such as people over process, as the people are the key to the community. But you could argue there isnât an MVP, as what is the product in a CoP?
Now, there are things used in different agile frameworks that could be beneficial to a CoP, such as holding periodic retrospectives, so you can find out what is and isnât working for the members of the community, ideas of how things can be changed to improve, and stay aligned to the goal of the CoP (which I discussed in the AMA and in earlier responses).
Hopefully that answers your question, but feel free to reply and seek clarification if not
1 Like
Iâm assuming when you say engineering teams, you mean the developers/programmers writing the software?
If so, it depends on how closely they work with the testers. If they are completely siloâd off, then improved communication and understanding of what both roles bring is needed.
Do they understand the concept of testability? https://www.ministryoftesting.com/dojo/lessons/masterclass-from-testing-hell-to-testing-well-adopting-whole-team-approach-to-testability-with-rob-meaney?s_id=87046 and https://www.ministryoftesting.com/dojo/lessons/testing-ask-me-anything-testability-ash-winter?s_id=87046 can help go into more detail on what they are, and much better than I ever could.
Do they believe their job is to write code, and throw it over the fence for testers to deal with, and so donât need to do much testing themselves, as otherwise theyâre doubling up on work that will be done? If so, they need to be shown the benefits of doing their own testing (unit but also mutation testing is something they could look at), in terms of less work coming back multiple times.
As itâs such a broad question, and one testers have been dealing with for years, Iâm not sure how well I can answer that for you.
Hopefully that answers your question, but feel free to reply and seek clarification if not
Another more about my overall thoughts on the industry over CoPâs, but Iâll try my best to answer it.
Just because developers and testers are in the same team, that doesnât mean they canât have their own specialities. Where I work for example, we have .Net developers and SQL developers in the same team. They are distinct languages with their own skills related to them. They arenât looking at merging, and I see no reason why testers should be treated any differently.
I have found often the mindset between someone who is a developer to be different from a tester.
They get asked to build something, and think about how it should be written to make it happen.
With testers, we get told something is wanting to be built, and we turn it around and upside down. We ask âWhat ifâŚ?â, and either want the answer proven, or find out there isnât an answer which means it will need to be answered.
There are some who say that the only way a tester can survive and progress is by moving into automation. That may work for some, but it isnât a one size fits all situation. I know it isnât for me. Improving analytical techniques, communication skills, lateral thinking, ability to coach/train others, all these things make us better testers, without forcing us into becoming poor developers.
If you want to learn to code, great. But if you donât and are forced to, you are just going to be a bad developer, and how does that help anyone?
If you end up in a situation where developers and testers merge, I would challenge calling yourself a âTesting Specialistâ. As part of people becoming T shaped, and then eventually Pi and Comb shaped (representing multiple strong areas of skill), we will naturally have something we are best at, and saying it is in testing, even if that isnât our role or title, it will still be what weâre best at, and wouldnât a team want everyone doing the best each of itâs members can?
Hopefully that answers your question, but feel free to reply and seek clarification if not
1 Like
I covered some of this in my previous response, but no, I have not progressed into automation, nor does it make me fear for my role as a manual tester.
Automation allows us to make processes happen quickly, but it doesnât tell us what processes should be done, nor how until it has been done.
Something I said to @mwinteringham at TestBash Brighton this year, was how I see myself as a manual tester is exploring a jungle. Sure, it is slow cutting through the jungle, but I can vary how I go, change direction, and uncover things of interest. But once I have carved that path, automation can follow me and build roads for people to make the same journey quickly and easily. As they do, I can continue to explore, making new paths.
Automation canât build a road it doesnât know where it wants to go.
You canât automate speaking with someone to clarify code or requirements. Automation canât pair to help understand something (though you can pair when doing automation). Automation canât think of all the ways to âbreakâ a system or process, though it can help to apply it once someone has worked out the ways (see Mutation testing tools, as they change logic from = to !=, >, <, null, and so on).
The reason it is popular is that it is easy to sell to those who control the budget. Do you want to complete testing in half the time, or with less people? Automate it. But then what happens when you need to do something which canât be automated? How do you measure those metrics?
Hopefully that answers your question, but feel free to reply and seek clarification if not
3 Likes
If theyâre unmotivated from it, do you know why?
Does the CoP have a goal? A vision? A purpose?
If so, is it being followed? As if it has lost itâs way, that could explain it.
If not, then what is it trying to motivate people to do?
Perhaps the goal has been achieved. If it has, does the CoP need to continue? Is it not better to end gracefully, than flog a dead horse and have people gain a bad impression of what a CoP is about?
You could find out with a retrospective, a feedback survey, or even a face to face chat with some of the community (depending on how big it is and if youâre co-located).
This can allow you to (hopefully) address what is making people unmotivated.
Maybe they donât like it always being presentations, as it is too passive as well as not being referenced ever again so the information doesnât stick - That is something that has happened at one I am involved with.
Maybe the times or frequency of the sessions arenât good for people. It can be hard to be engaged at the final hour of the day, or right after lunch on a Friday, for example.
If you do manage to find out why theyâre not motivated, please share what they say here, as well as what you did to resolve it, so others can learn from it.
Hopefully that answers your question, but feel free to reply and seek clarification if not
Reinforce that it is primarily for those who are practitioners of what the CoP is about, but that doesnât mean those who wish to learn more arenât welcome.
Have an open door policy, including making the invites to the session as public within your organisation as possible.
If notes are shared on Confluence or equivalent, make them available, rather than buried or locked away so only those involved can see. Few outside the CoP may use it, but itâs there. Itâs how I found out what other CoPâs exist at my workplace, for example.
Look at sessions that have a broader range of appeal than the core membership. With a Test CoP for example, do they all understand what unit testing is and why it is done? Developers could be invited to present, but also be in the audience to help answer any questions, or how they unit test if it is different.
Iâd also flip your question, to ask do people not feel welcome/able to attend a CoP outside of their discipline? If a tester wanted to go to a developer CoP, could they? Would they feel welcome there, or challenged as to why they belong? Do they even know of CoPâs beyond the ones they go to? As awareness could be the problem for them not being inclusive.
Hopefully that answers your question, but feel free to reply and seek clarification if not
I like the way how you explain about the tester mindset
2 Likes
We havenât tried that out. Partly because many of the testers (and managers) around are very resistant to change. It is also partly because we are made to use detailed scripts, and exploratory testing isnât accepted as a means to perform testing.
I did get them to try Pairing and Mobbing however. The testers werenât keen on pairing, as they sadly saw it as two people doing the work of one. Whereas for mobbing, that went down really well with the Agile CoP, as it encourages the whole team to work together.
If you do try it out with your CoP, please do share the results here.
Hopefully that answers your question, but feel free to reply and seek clarification if not
I am skipping question 18, as @heather_reid has answered that already in the chat, and shared her response within the post here too.
One thing I mentioned during the AMA was what I see as the difference between a CoP, and a Meetup, and how a CoP focuses inwards towards a single company, whereas a Meetup is outwards and encourages all testers (or whatever the Meetup is about) to attend. However, they both work in the same way, bringing practitioners of the same thing together, allowing knowledge and experiences to be shared, and help people know they arenât alone.
For your question, a tester focused Meetup which gets testers from different industries together is a good idea. In fact, in Leigh Rathboneâs recent talk he has been touring, he encourages testers to get in contact with those working in computer games and gambling, as they are often ahead of the curve with how things are done.
Testers might think, I work with backend databases, why do I care how to test a website? But each could offer ideas to the other, that they hadnât realised. Maybe the backend tester can point out how if the input is larger than the column allows, they expect an error, whereas the web testers might question what happens when it tries to query and finds no data in the database?
Regardless of the industry, we are testers, and can help and learn from one another.
Hopefully that answers your question, but feel free to reply and seek clarification if not
This relates back to the third post on here, where I encourage understanding the WHY behind being setup in the first place. I also advise watching the AMA back, where one suggestion I give is to get them to think of what makes a good CoP, to list all the things that would make it bad - Talking over each other, irregular dates/times, so notes, no support, etc. From there, the community can agree what can be done to make sure those things donât happen.
When inviting people initially, there are two thoughts I have on this.
- You invite everyone who will be your core membership, so testers for a Test CoP, for example. See how many of them turn up, and go from there. Everyone is made to feel welcome and invited, and even if not everyone attends, they canât say they werenât offered the chance.
- You find out who are the passionate people that want to get involved from the start, and only invite them. There is a risk it seems like youâre building a closed group and a clique, but you will feed of each otherâs passion, and get a strong foundation, which means once more people get involved there is a stronger idea of where it will go.
There are great ideas in Emily Webberâs book, which is linked in the resources at the top, and was what we used to go through it all, and I will recommend it every time to anyone who wants to start a CoP.
Hopefully that answers your question, but feel free to reply and seek clarification if not
I would say that a Guild from the Spotify model is the closest to a CoP.
The main thing I would also say is that unless a company is seeking to emulate the Spotify model (and if they are, remember to ask WHY, as the only company like Spotify is Spotify), to not get too focused on the different types of structure, and focus on what theyâre wanting to do.
If they call themselves a Guild, but do all the things that a CoP does, does the name matter? But if they veer off from what a CoP is, so it isnât optional, isnât about learning and collaboration but dictating how things must be done, then it becomes a different beast.
After the AMA, I see guilds and CoPs as being quite distinct entities. The way I understand it (if understand is the right word - maybe âimagineâ would be better), a CoP is people who are from departments directly related to the subject, whereas Guilds are anyone who is interested. The latter is certainly the way we run them, and it has proven useful. Like youâve said previously though, itâs a very informal sort of thing, so itâs whatever works for you.