Top.Mail.Ru

Главное - соблюдать принцип активного участия. Советы QA-инженера новым тестировщикам на проекте

Новое интервью из серии материалов о том, как тестировщику стать специалистом, которого с радостью примут в любой команде. QA-инженер IT Test (компания-разработчик DoQA) Наталья Зуева рассказала, как правильно доносить критику, какое поведение может задеть коллегу-разработчика, и почему личное мнение тестировщика не должно стоять выше общего блага для коллектива.

Самостоятельность — не значит изоляция

Некоторые тестировщики не задают вопросы из чувства гордости. Бывает, что в новой команде коллеги сложно идут на контакт, и у специалиста возникает мысль «ну и ладно, мне больше всех надо?». В итоге вместо того, чтобы помочь людям наладить связи и сделать так, чтобы у членов команды возникла привычка отписываться и отчитываться, тестировщик молчит. Но никто не может прочитать его мысли, и никто другой не будет впоследствии нести ответственность за результат работы тестера, который предпочел делать все в одиночестве.

Все ждут от новичка, что ему хватит самостоятельности, и он не будет часто отвлекать коллег, но стоит понимать, что вопрос вопросу рознь, и задавать их можно по-разному. Раздражает, только когда тестировщик дергает человека без попыток сначала самому разобраться в теме ничего не читая, не выясняя, не изучая сервис. 

Если новый тестер на проекте чего-то не знает, это становится его проблемой, потому что этим он подводит не только себя, но и команду. Нельзя будет потом на вопрос, почему ты о чем-то не узнал, ответить «вы мне не сказали» — это инфантильно.

Важно не замыкаться, говорить с коллегами, узнавать, что именно делает команда, как она это делает, как распределяются зоны ответственности. Классный онбординг встречается, но не везде и не всегда, поэтому не ждите по умолчанию, что люди обязательно принесут всю информацию на блюдечке. Нередко бывает, что каждый работает сам за себя, и обязанность нового сотрудника.

Боритесь за качество продукта, а не за собственное мнение

Тестировщики в каком-то смысле являются последней инстанцией перед релизом продукта или его функционала — они дают добро на то, чтобы показать результат работы пользователям.  Иногда это может подстегивать профессиональное эго: тестеры начинают спорить с проджектами, категорично отстаивать свое мнение. 

Тестировщик должен защищать свои решения, но важно понимать для чего: чтобы просто «упереться рогом» и потешить самолюбие или с пользой для продукта, когда действительно болеешь за качество. Коллектив ждет, что тестер будет гореть результатами и проявлять максимальную вовлеченность, поэтому любые рекомендации важно аргументировать с точки зрения целей команды.

Разработчик тестировщику не соперник

Важно, чтобы тестировщики и разработчики чувствовали общее стремление к целям, а не соперничество. Некоторые тестеры ликуют, когда находят баги, будто одерживая победу в соревновании, мол, разработчик ошибся, а я это обнаружил — так делать нельзя. В команде каждый специалист должен быть заинтересован в том, чтобы у коллеги все получалось.
Найденные ошибки я бы посоветовала отправлять не с заявлением «смотри, ты ошибся», а со словами «смотри, здесь возник вот такой момент, посмотри, пожалуйста, может быть, это должно не так работать». Это позиция содействия развитию продукта и уважения к коллегам, а также один из критериев, по которым проджекты оценивают новых людей, заходящих на проект.

Как высказывать критику, чтобы она привела к изменениям

По опыту, самое негативное впечатление о себе оставляют специалисты, которые приходят на новый проект и начинают свысока оценивать процессы. Например, бывает, что тестировщики работают без документации это реалии жизни, такое случается по разным причинам, и все в команде понимают, что это плохо. А новый коллега начинает надменно указывать на недочеты сразу, как включается в работу. Такие люди часто задают много вопросов, которые ни к чему не приводят. Это критика из серии «у вас здесь все не так», но делать с этим тестировщик ничего не будет. Подобные заявления без дальнейшей активной помощи по оптимизации воспринимаются как пустые претензии.
Нужно понимать, что у команды есть определенные условия, в которых специалистам приходится работать, и никто из них не стал бы специально ломать процессы. И прежде чем высказывать мнение по поводу того, как организована работа, важно уточнить, почему сейчас все устроено именно так, иначе тестер рискует стать раздражающим элементом, который будет только подавлять коллектив вместо того, чтобы поддерживать в нем боевой дух. Свои знания и опыт нужно не выпячивать, а использовать во благо команды.
При этом не стоит бояться критиковать, если знаешь, что главное соблюдать принцип активного участия. Обратная связь от нового коллеги будет полезна осознанные руководители ждут свежего взгляда и с удовольствием берут в работу аргументированные замечания. Можно подметить, например, что у тестировщиков непорядок на доске в YouTrack, и тут же взять на себя ответственность за помощь в исправлении процессов: рассказать о своем опыте, организовать карточки самому или предложить, как распределить эту задачу между членами команды.

Оставьте данные, и мы скоро свяжемся с вами

На демо покажем, как пользоваться DoQA и чем система может быть полезна в вашем случае, а также проконсультируем по волнующим вопросам.
Выберите один из способов связи на ваш выбор
Отправляя заявку, вы соглашаетесь с Политикой конфиденциальности

Задайте ваш вопрос

Отправляя заявку, вы соглашаетесь с Политикой конфиденциальности

Contact us

In this form you can ask any questions about DoQA and place an order without a trial version
By submitting an application, you agree to the Privacy Policy

Свяжитесь с нами

В этой форме можно задать любые вопросы о DoQA
и оформить заказ без триальной версии
Отправляя заявку, вы соглашаетесь с Политикой конфиденциальности

Спасибо за заявку

Форма отправлена успешно. Скоро мы с вами свяжемся!

Thanks for your request

The form was submitted successfully. We will contact you soon!