We’re curious to know, does your organisation have a community of practice?
Bonus points for any insights or experiences you can share.
- Yes
- No
0
voters
3 Likes
We have a 2 to 3-hour meeting every Thursday morning during which we discuss testing-related topics to ensure that knowledge is shared effectively and we harmonise our practices. The whole team takes part and anyone can raise discussion topics - in fact they are strongly encouraged to do so.
We only do accessibility testing now, so topics mostly include:
- Interpretation of specific WCAG success criteria, usually after some event has caused us to question what a success criterion really means or what it means in a particular context. This gets extremely technical, diving deep into the WCAG, ARIA and HTML specifications.
- How to test specific WCAG success criteria.
- Manual testing techniques.
- Testing tools - good ones, bad ones, limitations, false positives, novel uses. What tools do we need? Do they exist? Can we build them?
- Interesting code patterns. You would not believe the mad coding we encounter, which can make accurate testing difficult or impossible. Much of this is baked into JavaScript frameworks, so the same things tend to come up repeatedly. We also collate good design patterns that we can recommend to clients.
- New design paradigms. Things we take for granted, such as responsive design, infinite scroll, single-page applications, AJAX (and other forms of asynchronous communication) were all new once. Who knows what’s next?
- New technologies and standards. This is a nightmare now, because almost everything we use, such as HTML, CSS and ARIA, is no longer released in numbered versions every few years, so you could learn each version that was relevant to you. Instead, they are “living standards” that literally change every week. Keeping abreast of the changes is virtually impossible.
- Experience reports.
We all work remotely, so the meetings are held over Zoom calls, which we record. We now have about 200 hours of recordings, so searchability is important. We do several things:
- We enable Zoom’s transcript feature and save the resulting text file. It’s very inaccurate, but it’s usually good enough for keyword searches. Its contents are timestamped, so it’s easy to find the relevant parts of the video once you have done your search.
- We enable Zoom’s Meeting Summary feature. This uses AI to create a summary of the meeting, which is emailed to you afterwards. It’s surprisingly good, but it makes mistakes, assigns comments to the wrong person and it occasionally hallucinates. Nevertheless, it’s good for keyword searches, so we save the emails.
- A junior team member replays the recording (at 1.5x to 2x speed) and creates a searchable record of the topics with their timestamps. Other information may be recorded, such as URLs.
- We are in the process of entering all this information in a wiki that anyone will be able to read, add to and edit, creating a centralised knowledgebase that will also contain information from other sources, such as posts to forums like MoT.
3 Likes
Yea! We have several actually.
We have the whole QA Department basically which is 1 big group of around 50 people. We send out evening sessions where we share knowledge about our projects and what our problems were and how we tackle them.
Then there are the smaller QA communities which are specific to a domain for example " Technical QA " which contains the people who do technical testing, such as automation, performance testing etc.
We organize in these smaller groups “exploration nights” and “training days” where we discover new methodologies, frameworks, ways of working etc. We try to do it once a month.
1 Like
Once a month we have space on our calendar to bring the whole test team (and others) together to talk about any concept people want to put forward.
I kind of look at this as being the minimum amount of training we want to do. A lot of times we’ll start a discussion during the CoP time and then later add a few additional hours / meetings to follow up on the topics.
I tend to like doing CoPs that are hands on. Have a mirror board or mindmap, or something and then we have a facilitator who works through the topic with people.
Our team is small, only about 5-6 in the testing group but I’ve run CoPs with as few as 3 people.
Yes, but it can be a bit broadcast rather than collaborative meaning people don’t see the value in it.
Organisationally the idea of a CoP is quite new so people don’t know what they want from it / how to engage. Instead they favour focusing on their project teams to solve problems. This means potentially solving the same problem many times, but when people are up against deadlines I’m not sure they see that as an issue.
Yes I have worked mostly in service based organizations wherewe have a dedicated community of practice.
What we do there mostly is activities related to testing like
1.POC’s for new projects
2.Training a bunch of people on the latest trends and technologies
3.Evaluating tools and procuring licenses
4.Publishing whitepapers
The organization has no testers.
We don’t have a “testing CoP” but rather a “Quality Circle” which includes all kinds of people from the product engineering department and it’s different teams - QAs, developers, product managers, support engineers, devOps, etc.
The goal of the circle is to discuss different software quality related issues and opportunities, work on the quality strategy and roadmap, vent a bit about currently problems and take topics and ideas back to the teams.
Since quality is the responsibility of everyone, this is what we are doing - including everyone. Also, making sure that people don’t only think software quality = bugs, but rather software quality consists of so many other things that we all can influence and change.
3 Likes