How to organize the work of QA. One practically applied method

Prehistory

Recently, a friend of mine, QA Engineer, who worked for a long time in a sluggish project, where her responsibilities were strictly delineated, changed jobs and settled into a newly launched project. Having spent a couple of days without the tasks indicated above, and frankly bored, she went to the management with the question “What should I do?” And received a meaningful answer “Organize your work”. And then she fell into a stupor, "And this is how?". And really, how?

A few months ago, I changed the job myself and got into an English project in which I had never had QA before. The project itself has been around for a long time. As often happens, a company in which a lot of money, bought a company in which less money, but there are customers. As a result, a large company received new customers and a minus one competitor in the market. My project received a change of management and management principles.

In the very first days of my acquaintance with the new team, I heard the honest bewildering question of one of the developers of the London office, “What are you going to do here?”

In truth, having come to this project and looking around for a few days, I, like my colleague, at first fell a little into a stupor. Not because I didn’t know what to do. Rather, I didn’t know how to wedge myself correctly into the foundations established here. The development team existed remarkably without testers. They used kanban, the principles of continuous delivery, fearlessly, calmly and confidently deployed on production almost every day, even on Fridays. And all because they had a great coverage auto tests. Perhaps the best I've ever met. Reviewing pull requests for each other, they did not hesitate to tell each other what other autotests to add. The author of the current change deploil himself his work on production, which means he was fully responsible for his work. And he carried her, despite the fact that I appeared on the project ... and it would be nice to hear my opinion before the deployment.

But still, of course, the process was not perfect: it happened that the developers did not understand the requirements, missed the bugs, and quite often there were some problems on the customer side that required action.

Faced with the need to determine my position in the team, I also went to the leadership. Only our dialogue was built very differently, not like my friend.

Organization of QA Engineer

Ask the right questions

So. For dialogue, I convened a guide and lead developers of the project. There is one remarkable rule of management, which I, of course, could not forget: when voicing a problem, voice one option for solving it, at least one.

However, I had two questions, the answers to which I could not know. With them, the easiest thing was to start.

First question. What is the structure of the organization, namely who is over whom and who is responsible for what?

Ideally, companies should have a hierarchically represented scheme illustrating the structure of the company. But I am not in the ideal, so it was important to find out to whom with what questions and suggestions you can go.

Second question. The company introduced into the QA Engineer project, what are their expectations regarding me, what goals did they pursue when opening this position?

When the answer is very specific, it largely determines the work front. In my case, the answer contained many common blurry phrases, which I perceived as “do what you want, but so that everything is fine with us”.

The first part of the discussion is over.

Discussing a plan of action

The second part of the discussion, and perhaps the most important, was the presentation of my work plan and its rationale. I needed to get the blessing of my superiors for the smooth introduction of myself and my activities into the project.

It is pleasantly obvious that smart books and theory do not exist from scratch, so I armed myself with the knowledge gained in preparing for the ISTQB certification, once curiously reading books on testing theory and Scrum, I missed it all through a sieve of ten years of work experience and made a pilot project for QA Strategy.

Thematically discussed with the management and fully supported by him, he later acquired the format of the official document of the company. Then I want to share ideological recommendations for the preparation of such a document. They have developed as the quintessence of previous experience and the path traveled on the current project. And, perhaps, in the form of quotations, I will reprint here some fragments in their original form: in English. I am sure that for each QA Engineer, drawing up such a plan will be the key answer to the question “How to organize your work”

We form QA Strategy

1. Introduction to Quality Assurance

Remind / first introduce the term Quality Assurance. Believe me, your team is full of people who very vaguely imagine what it is. Most common definitions can be borrowed from Wikipedia . Tactfully indicate that the presence of a QA team on a project does not mean that all responsibility for the quality of work is now transferred only to them:

Testing is a part of QA. It is a measure of the quality of the feature (s) that we are assessing.

It is not the sole responsibility of QA. It can be used to deliver.

2. Introduction to QA Strategy

Prepare for what more people will read about.

It is a process of development.

Sound the content. It can be as simple as a table of contents, or more abstract sentences. Here mention the existence of an Test Approach, Test Process, Test Automation Strategy and the need for a Test Plan.

Important. Indicate the time interval for the revision of this document. And the project and processes in the company are developing, this document should not turn into a dinosaur. Therefore, schedule a date when your strategy will be revised and changed. In my opinion, six months is enough to return with new thoughts.

3. Test Approach

What is a testing approach? A little away from the voluminous official wording of this definition, I allow myself to simplify it to the thesis that these are “basic thoughts with which we start working every day.” Write here: what is the engine of your progress?

The classics of the genre and well-functioning approaches are “proactive” and “risk-based”.

We will be adopting a proactive and risk-based testing approach.

Forwarding is created.

This is a review of the risk of the ship. It is clear that there has been a clear-cut effect on the system. During the execution of the test, it should be noted that it is more than that. It identifies the risk of risk management. It is a high level of impact defects. “Risk-based testing”

When we talk about advance, we, first of all, should speak about quality control of the specification of requirements. The managers who compose the specifications of the elements of the next development cycle mostly think as simple users of the system, while the logic of the thoughts of the developers exists in another dimension. First of all, more than once I saw such that a developer, reading a specification, cannot translate it into a programming language. For example, it cannot associate the user mentioned in the specification with existing roles / access rights in the system. In the end, he can choose the most appropriate, in his personal opinion, the role that is wrong and will have to return the functionality to work later and lose time; or ask a question to the manager, who may have gone on vacation and again wasting time waiting. QA Engineer is a great layer between a manager sharpened by a user and a technically-minded developer, especially if QA Engineer does not neglect white box testing. That we are able to understand the managers and translate their thoughts to developers. During.

Risk based testing has interesting formal methods for assessing project risks and product risks. It's great to be able to practice them. But personally, I never have enough time to paint the probabilities of occurrence, the severity of their consequences, etc. and calculate the risks according to all the rules. Here I fully rely on my instincts and common sense. When testing or covering by auto tests, the risk zone (what you need to pay first and main attention) for the most part:

• directly developed functionality
• adjacent and interacting areas
• commercially important functionality
• what most often breaks
• backward compatibility (if, for example, the metadata format was changed, whether existing data will function successfully)

4. Test Process

Tell us what methodological sequence of work you expect to follow. I did not invent anything complicated, but took the idea from ISTQB and use it.

If you follow my path, familiarize yourself with the sequence of work that the ISTQB authors recommend, understand what steps you will perform and how. We start with planning and control. These two live together, because on the basis of monitoring their own activities, plans can be regularly rewritten. Then work with the documentation and writing test cases, putting them into operation (activating the planned test data and a suitable environment), completing the testing and cleaning after themselves (deleting temporary files, etc.)

ISTQB syllabus: test planning and control, test analysis and design, test evaluation and design, and test closure activities.

5. Responsibilities

Designate your and other people's responsibilities in the field of improving the quality of the product. Carry your mission.

First, emphasize again that each team member is a tester by himself , everyone is testing what they relate to. Wrote the code - test it.

Secondly, clarify and understand the direction of its continuous development. QA Engineer - the main expert on product functionality : knows how and what works, is able to explain how and what needs to be tested. He is a person who anticipates the operational behavior of the customer, and therefore will not allow serious problems to develop.

Thirdly, designate a way to interact with managers and developers . For example, stop at Three amigos agile approach

Collaboration between Business, Development and QA
a. Business - What are we trying to solve?
b. Development - How to solve this problem?
c. Testing - what could this happen

6. Testing Levels and QA Automation Strategy

Today, this section has become a separate self-contained document. But at the level of organization of the emerging QA process in the team, identify what types of testing who will perform. What will be performed manually, what to automate and on what basis. Who is responsible for what tests.

For example, on the current project, I write only end-to-end tests, the smooth operation of which is strategically important from a business point of view. At the same time, I look at pull requests from developers and, if necessary, give recommendations about test coverage. All the rest (unit, integration, load, etc.) - this is the work of developers. On the previous project - load testing was on me, and I wrote integration tests along with the developers.

7. Feature workflow

Today my project is working on Scrum, using two-week sprints. Therefore, I have a step-by-step lifecycle document for each Story.

Whatever methodology the project adheres to, describe how to do the daily work step by step. If we talked more about the tactics of actions above, then there should be clear instructions that first, then later.

For example, my version is

The workflow below is internally.
1. Get story before planning session
2. Create a checklist according to acceptance criteria and the description
3. Note unclear details / questions
4. Clarify questions on planning
5. Update the checklist
6. Highlight any dependencies
7. When are you covered by autotests?
8. Encourage developer to do it yourself
9. When testing the checklist
10. Create the bugs for the story
11. When bugs are fixed perform manual testing using the checklist again
12. Check if all autotests are passed
13. If it is needed
14. Move story in QA Passed state

8. Test Plan

Select the type of Test Plan, the platform on which you will store it and the purpose of its existence. Provide a way for anyone to look in there.

On this project, my Test Plan is a set of checklists for each Story. With the current level of automation, this is enough.

On the past project, the Test Plan was used for thorough manual testing and as an ideological basis for future autotests.

If you have a lot of manual tests, write test cases in detail, so that any new QA engineer who comes to the project can complete them on his own.

How to work with the document

To write this whole plan and effective words is very cool. The bosses will appreciate, no doubt. But there is one important point in the existence of this document. These are honest answers to questions for whom and for what is all this written?

Prescribing each proposal, it would be good to think about the questions: “Do I really want to work like this?” , “Will I really implement this on the project?”

If both answers are positive, confidently type on.

If one of the answers is “No,” in my opinion, this is a sure sign not to hang up unnecessary duties.

If one of the answers is from the “I don't know yet” series, let it still live on your pages.
I have such moments remained in the list of what will be reviewed first in a few months.

First of all, I wrote my document for myself. I have moments when I step back from the processes described and even go against them a little. To adapt to a situation in order to use resources efficiently here and now is normal. But in the overwhelming majority, in the usual routine work, my document is my guide. More than once I was convinced that the existing plan / strategy in any sphere always brings the desired results closer and with less pain than its complete absence. I wish you to build your work easily and efficiently!

Before the publication the article was greatly reduced, it was too big for the Sandbox. I will be glad to continue this topic later. Nevertheless, I am always glad to develop, if there is something about which I have completely forgotten, please write me a comment.

Thank!