QA Chapter

There are different point of view on organising a QA chapter. As a QA manager, I see it in the following way.

If you ask me `How should QA Chapter look like?`, I would suggest the following structure:

Chapter Lead: Person taking final responsibility for decisions
Mandatory: 3 QA engineers, 1 BE engineer, 1 FE engineer
Optional: Product Owner, Architect, DevOps engineers

NOTE: It is very important for me to have representatives of different roles in the chapter, since everyone sees how to improve quality and where to apply improvements differently. 

If you ask me `What are QA Chapter areas of responsibility?`, I will answer that the agenda of QA Chapter meetings should be based on the following areas:
  • Product quality:
    • Quality of Development
    • Quality of Testing
    • Quality Control
    • Quality of Delivery
  • Visibility of QA work
If you ask me `How are you going to make your QA Chapter performing well?`, I will answer that we will need to define a set of rules and constantly monitor that we are doing a right thing:
  • Low level technical topics should not be a part of chapter discussion, since chapter only shows the direction where we are moving, but not the exact path.
  • All chapter decisions have to be documented, have to be measurable with defined deadlines, checkpoints and action points.
  • QA KPI/OKRs should de based on areas under QA Chapter discussion
  • and etc
 
In the end, I want to tell you that you shouldn't afraid to experiment. Try different chapter structures, agendas, rules. It is very important to find a way for chapter to perform well in your organisation. 

Let the quality be with you!

Comments

Post a Comment

Popular posts from this blog

QA Organisation: work visibility and transparency

In many companies work of QA organisation (QA/Test engineers or/and teams) is something hidden in darkness. Nobody knows what they are doing and accordingly do not feel all the efforts QA engineers spend for assuring high quality of delivered products. In order to improve the situation QA organisation should improve visibility of their work. I recommend to look at the following list of ares where visualisation and transparency is needed: Transparency of communication Channels Emails Messangers Who? When? What? How? Availability and accessibility of all required artefacts Test Strategy Test Plans Test cases / Checklists / Test Flows Roadmap Reports and etc. Transparency of decisions Decision making process Decision making group(s) Chapters Guilds Library of documented decisions Publishing decisions via all available channels Current state of ongoing work What is done What is in progress What is planned next according to the roadmap Feedback loop Feedback about quality from stakehold...
Read more

Organizing UI automation testing

In recent years it is becoming less and less companies where you can meet dedicated test teams working with different development teams under the same product. This is most likely due to financial reasons because there are not so many companies who can afford to keep a team dedicated exclusively to testing and everything related to it. Nowadays a majority of software development companies work using Agile & Scrum, where all team members (software engineers, architects, programmers, analysts, QA experts, testers and etc.) are sitting together and doing their best to meet the goals of the sprint. In such projects testers, in principle, may know nothing about work of their colleagues from other teams because their areas of responsibilities intersect not very often or do not intersect at all. It can work fine until we are not starting talking about organizing automation testing and everything related to it: planning, design, implementation of frameworks and tests, support. I ...
Read more