And again about software testing

There are three pillars on which quality is based in every well performant company: People  with right skills and attitude to do the work, Technology  to help people to do their work even better, Culture  with opened environment for growing new specialists and new tools on the way to success. Have I missed anything?

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 stakeholders

Many people, especially in flat structured organisations, say that they don’t need managers. Right, but from my point of view it’s getting possible only if everyone in the organisation is on the same page, can easily and openly communicate to each other, knows where their product is growing, everyone is highly motivated and nobody has high career ambitions. The best example of flat structured organisation is a startup working in a small garage. Definitely they don’t need managers, they know what they are building, they can communicate to each other and they define their business strategy. Problems come with growing of the product where one day they will have to start hiring new people. Staying flat structured means working hard together and make decisions together, not only technical decisions but strategic and managerial as well. More your company grow, more difficult it is to keep flat structure working well, more time it requires to convince others in chosen directions and business

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 tha

SCRUM framework has well defined structure, roles and responsibilities. All Quality assurance aspects are distributed between scrum representatives of all levels: Agile Coaches are responsible for quality of agile processes (Quality of processes on company or development department level) Scrum Masters  monitor and help that teams to follow scrum ceremonies and rules and delivery increments in time (Quality of processes on team level) Product Owners are responsible for the product’s value, backlog and prioritisation (Quality of requirements and delivered product) Development team is responsible for quality of delivered increment and development process Developers - design, solution and code quality, QA/Testers - take active part in grooming/refinement sessions to ensure that feature will be tested properly, corresponds to user story acceptance criteria and not bringing issues to the existing product. Perform testing of implemented features and ensure that quality criteria are met.