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, "How's that?". And really, how?
A few months ago, I changed the job myself and got into an English project in which I had never had a 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 will you do here?”
In truth, having come to this project and looking around for a few days, I, like my colleague, at first fell into a stupor a little. 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 autotests. 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
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 quite 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 that I could not know the answers to. 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 QA Engineer into the 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 ISTQB certification, once curiously reading books on test 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 makes it possible for us to assess.
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.Voice 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 reviewing 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-working approaches are “proactive” and “risk-based”.
We will be adopting a proactive and risk-based testing approach.When we talk about anticipation, we, first of all, should talk 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 not the one 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 user-sharpened manager and a technically-minded developer, especially if QA Engineer doesn’t neglect white box testing. That we are able to understand managers and translate their thoughts to developers. During.
Forwarding is created.
It is a risk that the system will be shipped. It is clear that there has been a tendency for the system. Risk-based testing and prioritize the tests during the test. It identifies the risks associated with planning, planning, specification, preparation and execution. It’s possible to reduce the likelihood of defects, it is not a good idea to get past us less painful. “Risk-based testing”
Risk based testing has interesting formal methods for assessing project risks and product risks. Very cool to be able to put them into practice. 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 them (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, stress again that each team member is a tester on his own , everyone tests 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 atThree 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 possibly 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 action above, then there should be clear instructions that first, then that.
For example, my version is
We work adopt internally.
Get story before 1. planning session
2. Create a checklist acceptance criteria according to the description and
3. Note unclear details / questions
4. Clarify questions on planning
5. Update the checklist
6. Highlight any dependencies and how you're going to overcome them
7. When the story is in Review check if acceptance criteria are covered by autotests
8. Encourage developer to cover all acceptance criteria with autotests or do it yourself
9. When the story is ready for testing perform manual testing using the checklist
10. Create bugs for the story
11. When the bugs are
checked again . 12.
If it is needed
.
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 peek 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, having come to the project, can perform them independently.
How to work with the document
To write this whole plan and effective words is very cool. The authorities 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
put this into practice on the project?” If both answers are positive, confidently print further.
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 an 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!