ADPASS рекомендует материал к прочтению
IT Test
06.03.2024, 12:06

Как аутстаф-тестировщику оправдать ожидания команды — советы IT Test и DoQA

Работающие в аутстафе тестировщики раз за разом переживают непростой процесс адаптации в новой команде. Но с опытом делать это становится легче. Читайте советы сотрудников IT Test и системы управления тестированием DoQA, прошедших через сотни проектов у самых разных заказчиков.

Не ждите, что вам всё объяснят

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

Правильная тактика в такой ситуации — самостоятельно изучать все с нуля, задавать коллегам вопросы по требованиям, кредам, задачам, спринтам, тестовой документации на проекте. Четко сформулировать для себя, что это за проект, какие в нем основные механизмы, какой вид у приложения или сайта, какой бэкенд, кто из людей по какому направлению работает. Сразу идти в разработку, потому что только там сотрудники точно знают, как сделаны фичи.

Можно этого не делать, но когда новый тестировщик покажет плохие результаты, все вопросы о качестве работы будут к нему одному — такова специфика аутстафа.

Но если чего-то не знаете, не врите

Нормально чего-то не знать на новом проекте. Это можно объяснить коллегам и сразу взять ответственность за свое незнание — задать нужные вопросы, самостоятельно поискать информацию в интернете, потратить время на практику.

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

IT Test

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

Проявляйте инициативу

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

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

Не будьте высокомерны

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

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

IT Test

При этом не стоит бояться критиковать, если знаешь, что главное — соблюдать принцип активного участия. Можно подметить, например, что у тестировщиков непорядок на доске в YouTrack, и тут же взять на себя ответственность за помощь в исправлении процессов: рассказать о своем опыте, организовать карточки самому или предложить, как распределить эту задачу между членами команды.

Ищите подход к разработчикам

Основная разница между тестировщиком и разработчиком заключается в фокусе приложения усилий. Разработчик сосредоточен на том, чтобы создать код, а тестировщик — на том, чтобы найти его уязвимость. Как будто один должен «испортить малину» другому. Поэтому при взаимодействии с коллегами тестировщику иногда приходится преодолевать стену неприятия, особенно, если разработчик заранее хотя бы минимально протестировал свой код.

Вина за наличие дурных вестей — багов — вешается на того, кто их принес. Именно поэтому возникли шутки, что хорошего тестировщика хочет убить весь отдел разработки — он никогда не оставляет их в покое.

IT Test

Чтобы не раздражать разработчиков, свою работу надо делать просто хорошо: подробно описывать баги, понятно их объяснять, помогать с воспроизведением и желательно так, чтобы при ретесте новые баги не обнаруживались. Разработчики не любят канитель с возвратом одной и той же задачи по кругу.


Этим материалом мы продолжили тему, начатую в интервью с QA-инженером Алисой Мордвиновой, и объединили опыт тестировщиков DoQA — TMS разработки IT Test. Больше экспертных материалов о тестировании читайте в Telegram-канале DoQA.

Вам понравится

IT-компания «ASMART»
19.04.2024
Иностудио
01.04.2024
Как создать полезный гид
для предпринимателей?