Some responded that I was writing about âcommon truthsâ, but at the same time I received a good response in the comments and personal messages from the category âwas usefulâ, âwhat I need nowâ, etc. But there were questions. The questions, for the most part, boiled down to the âpainâ that has not passed a single QA in his career:
- How to interact effectively with developers?
- how to arrange work with them so that they accept: is there another opinion on the project, the opinion of QA, and is it also important?
- how to encourage them to interact, for example, when building a joint test automation when they are not configured to work together?
- how to act when your technical skills in the stack of technologies used are simply not enough?
Immediately make a reservation that the topic is very sensitive, talking about it you always have to balance on the verge of not hurting the pride of both developers and QA itself. Therefore, I beg you to read with a cold heart and just try to highlight a couple of useful points and try them out in practice.
Introduction
Firstly, as practice shows, often those QA that fail to wedge in the development as required by the profession
- simply not self-confident. They cannot get to be heard, because they speak inaudibly, not reasonably, expressing constant doubts;
- they are afraid to make mistakes and incur extra responsibility;
- complex due to imperfect technical knowledge.
Secondly, the developers in the team perceive QA as an appendage that simply presses the buttons before giving the product to the client, or simply does not imagine how to interact with them. This may be due to the fact that
- they still think of QA as testers 10-20 years ago, when they really were;
- all previous QAs with which they worked in exactly the same way and behaved, and they simply donât know what happens otherwise;
- in principle, they donât know what the essence of the QA Engineerâs work is in essence, because they simply donât need it - they develop in their skills;
- code development is already well established and changing something in it is just laziness.
Let's start with the first problem.
QA Engineer! Do a spring cleaning in your head
Work on understanding your profession
If you want to change the world, start with yourself. Well-known and very relevant truth in our topic.
As a QA Engineer, it really does not hurt you to figure out what position you work for. If your project still lives on the principles of waterfall architecture, and you were hired simply by a manual tester, who, like OTK at the enterprises, checks the readiness of the final product, then this is one thing, and here everything is pretty transparent.
And if you are in the position of a full-fledged QA Engineer, which is almost universal now, it means that your responsibility, laid down by the canons of this profession in [1], is not only testing the finished product, but also directly participating in organizing the processes of its creation and the interaction of participants the whole project. Please remember that without clear processes and organization of the team itâs almost impossible to get a quality product, so in this field the voice of QA should sound confident and clear. To prevent the appearance of bugs, and not to fix after the fact - this is the lot of well-organized teams. And making efforts to minimize the number of bugs is the lot of the QA team. (The circle closes.)
Therefore, the very first, recall all fundamental things about the principles, types, levels of testing and the wording of the definition of the profession of QA Engineer. Understand the notorious âWho am I?â And âWhy am I here?â
Find answers to questions
When professional self-digging is finished, outline a plan for yourself, what you will do, you can take ideas from my articles, or draw up your own plan that suits your circumstances. Each point of your activity should be clear to you yourself - why is it, how to implement it, what is the profit.
Only in this case will you be able to speak confidently on the project. Even if you so far know only the answers to the questions âwhyâ and âwhat is the benefitâ, but you do not know âhowâ. Feel confident already from the fact that you see the front of the work, the correct formulation of the task is 80% success.
The next step is to write down the questions you need to solve in order to answer the question âhowâ. And go to the people with this, that is, discuss with the team - in a specially organized meeting, chatting between business or informally in the kitchen over a cup of coffee, it does not matter. It is important that your project is full of people who have different experience, other knowledge, use this storehouse of useful information, communicate, ask and everything will be clarified.
Drop the experience that you are not perfect
If you are very shy or a maximalist in life who always strives to be a leader, then it will be difficult to play the role of QA. Because QA Engineer is an engineer, he is a person involved in the development, but at the same time we find ourselves on projects with a different stack of technologies and architecture, while developers have their own specialization. Recognizing that you are âoff topicâ for some people means writing yourself into a âweak linkâ. And this was my problem, which I struggled for a long, long time. âThis is what I need to say, that I donât know that I donât know what, I donât understand ?!â - I repeatedly entered into discussions on the full technical aspects.
But only at some point I finally realized that not knowing is not a shame. I am ashamed to continue to "hide in the shell" and not try to find out. And to remain silent, to seem all-understanding, is dearer to oneself.
You were hired, they read your resume (youâll be sure of your abilities;)), you talked to you at the interview, and you were hired. So your stack of technical skills is fine with everyone and those who hired you have guessed what to expect. Therefore, jumping above your head now makes no sense. And when you say "I have never worked with this, but I want to figure it out, help me understand this and this" - this is an absolutely normal, healthy and correct situation (do not bring only the most primary to the point of absurdity knowledge - definitions and formulations - learn from the Internet). And when you indicate to others that you donât understand this technical background, firstly, they already feel that it is necessary to communicate more simply, and secondly, you can ask clarifying questions with a clear conscience. If you wrote the code once or twice and completely understood the internal architecture of the project, then you probably would have been directly involved in the development, right?
And my little favorite trick is to always help others, when I am able - by deed, advice, kind words, this comes back with the mutual desire of others to help me.
Do not be afraid to make mistakes
Take for granted that workflows involve a discussion of all possible options. Truth is born in a dispute. Your task is not to be right, but to find the best solutions. And if you want to offer something, but are afraid that it sounds silly, then believe me how many teams I saw, the most indifferent silent colleagues look the loser. Recognizing some of our mistakes, supporting the best ideas and enthusiastically contributing to their implementation is a healthy workflow.
Remember, the heroine of Muravyeva in the film âMoscow Doesnât Believe in Tearsâ set herself up before going to the library: âif you blurt out, blurt out confidently, then this is called a point of view. It really works.
Do not be afraid to call upon yourself tasks that you cannot handle. Remember, you are working in a team and saying that something is not working out and asking the team for help is normal.
And even if in the course of your work you come to the conclusion âyou donât have to do thisâ, it will be progress, because the next step is to find the best solution.
Release obsolete standards, look to the future
These foundations that QA is a low position, it is not so important and not so significant one way or another found in teams. And while you yourself think so, you are underestimating this tendency, alas, feeding.
You work every day, you make efforts every day, making the product and team better, you spend time and energy, your position is laid in the framework of projects - this means it is important and necessary. All. Do not leave room for self-mutilation, and do not leave room in your head for âtauntsâ from those who consider that you are a status lower than him. These times, when there were simple monkey-tester hand-held testers, have sunk into oblivion, in the future, QA Engineers are âa detachment of elite special forces whose success depends on excellent tactics and modern weaponsâ [2].
Remember that today in leading companies such as, for example, Microsoft and Google, âdevelopers are responsible for quality. If the product breaks after release, then the cones will fly to the developer who created the problem, and not to the tester who did not find it â[2]. Therefore, in such companies, having a QA team that will help make a quality product is a privilege for developers.
And itâs in your hands to introduce advanced principles in your companies, instead of looking back at past stereotypes.
But again, I return to the fact that you need to constantly grow in your project. If you came to the project, six months have passed, and you still have not come up with effective test automation, do not try to figure out what the team is doing, do not analyze existing autotests, then you are not quite the elite that are written about in books.
There are teams that live without a QA Engineer position at all, I know those. And if you already today strive to immerse yourself in the project and learn how to write self-tests with developers, one day you will be able to sell your competencies even there and become a software engineer in test there.
QA Engineer! Fine-tune teamwork
When the work on yourself is over, it's time to work on establishing a collaboration with the developers.
The most important thing
- Your actions should be clear and transparent to the team. The simplest and most effective way is to convey your mission to them. If, for no reason, you start climbing into the pull pool with them asking, âWhat kind of tests are you having here?â, âBut you should write such a test,â the first (protective) reaction will be â where are you going ?! â,â who are you / such to criticize my work ?! â. He may have cooked this brunch for a week, finally exhaled, and then QA got it. Therefore, tell them in advance what you are going to do, why and what the benefits of this are for the project and the team. Prepare the soil.
- Your participation in the development a priori should be perceived as a blessing, as something that qualitatively improves the work of the developer. Become his partner. For example, educate - tell how customers are most likely to use the functionality, what bugs have already happened and which ones should be avoided, which means together think about which tests and why are important. Do not communicate in an imperative mood. You can even resort to psychological tricks - mark those who increased the coverage of self-tests in some final reports in the format âwhat are we all done!â It is always nice when your work is appreciated. And traditional QA reviews with auto-test coverage are also a motivation to work together.
Let the changes on the project be smooth. If you come to work one morning and say, âIâve read an article on HabrĂ© and start spanking my boot on the conditional platform, shaking the air, they say, now I will show you Kuzkinâs mother!â, They will look at you as strange, this is a fact. Yes, and it will be difficult for you - faced with problems on all fronts - there will be an irresistible desire to give up the whole idea of ââimproving the work of QA.
Better set small understandable tasks for everyone, achieve them and take on the following. Carefully move forward, time flies quickly, one day it will be nice to turn back.
Answers to specific questions
After my second article , which offered close work of QA and development, the audience expired from the category âwe tried, but the team leader of developers didnât really want to meet.â From my current level of professional development, I can only advise the following.
Be friendly and treat with wisdom calm those who do not accept your work as you expect. In my practice, I met many different developers and all those who were truly professionally mature always came to meet me, always helped, and we achieved excellent joint results, they were all satisfied. Those who âsnortâ and âwave away from youâ, alas, are from the category of âprofessional teenagersâ. They have not yet learned to cope with their feelings, considering themselves the most right-wing (and physical age does not play a role here). They simply do not know how to work in a team, and you are its integral part. You can just help them grow, but, unfortunately, some never grow. And here you can only influence them through the support of leadership and the collective authority of the rest of the team that will support you. If you know the best ways, share!
There was also an interesting question about how to be, if you just do not yet know how to read the developer code, you cannot figure out their autotests.
I will leave my answer here, so that it is not lost, maybe someone will come in handy. If you canât read it, I would insist on including a list of developed autotests in the PR description and focus on it. I believe this is the full right and duty of the QA team to be as aware as possible about the coverage of the product with autotests, otherwise the whole idea of ââQuality assurance is lost ... If we consider the situation of severe time limitations of the whole team, including the developer, then I would insist on the review Coverage of critical / strategic scenarios with integration autotests. And for all other scenarios, I documented separate tasks to make them later. In any project, there are calm periods when there are no deadlines - then it is worthwhile to focus the attention of Product Manager / Team Lead / Scrum Masters on including these tasks: itâs more complicated - let the developers do it, to learn the most simple ones.
Conclusion
I canât say that everything that is written above will certainly help you, nevertheless, I have a feeling that my own professional voice and style come with experience and through stuffed bumps. You canât take how to use someone elseâs script to work on your project. But if my scribble prompted you not to put up with moments that you donât like, and you had ideas in your head that you can do good for yourself, for the team, for the product, then I have spent time not in vain. And yes, donât think that I portray QA Shark, who knows everything, knows everything. I study and change constantly. I am well aware that in a year my principles of work may change. Always very happy with feedback and I will gladly learn from your experience, write;)
And if you want to read something to strengthen your own motivation, start with two wonderful books, a reference to which I gave in the text:
1. Foundations of Software Testing: ISTQB Certification
by Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. How to test on Google
James Whittaker, Jason Arbon, Jeff Carollo
Thank you all for your attention!