Привет! Меня зовут Игорь Ниточкин, я руковожу агентством тестирования Qualitica (ГК Digital Hub). Мы работаем на аутстаффинге и помогаем компаниям проверять их IT-продукты, чтобы там не было ошибок и багов. Фишка в том, что к тестировщикам на удаленке относятся с опасением. Клиенты видят в этом риск для бизнеса: человек не в штате и непонятно, чем он занят. Рассказываю, как контролировать удаленных тестировщиков и сделать так, чтобы не пожалеть о их найме.
Как контролировать тестировщиков на удаленке
Сегодня выбор аутстаффинга во многом определяет пандемия: по ряду причин компании просто не могут взять сотрудника в офис и делают выбор в пользу удаленных тестировщиков. И их можно (и нужно) контролировать. Внутри своей компании мы следим, чтобы каждый сотрудник отвечал за свою работу и по её качеству ничем не отличался от сотрудника inhouse. Контроль помогает нам закрывать каждый проект ровно в срок, не терять деньги и сохранить клиентов. Кроме того, чем эффективней контроль – тем меньше сюрпризов.
Если вы взяли тестировщика на аутсорсинг, внедрите в рабочий процесс эти способы контроля и проверки:
1. Добавьте его в общий чат и подключайте к групповым созвонам
Чат, как правило, есть в мессенджерах у каждой компании. Добавляйте удаленного тестировщика в чат с первого дня его работы. Так он поймет, что является частью отдела разработки и тестирования (или частью команды), куда его подключили. С той же целью проводите общие совещания в онлайне для обсуждения планов и задач.
Удаленный сотрудник не должен находиться в вакууме. Маловероятно, что он интегрируется в команду так, как сотрудник inhouse, но общие рабочие встречи будут держать его в тонусе и включать в жизнь компании.
2. Собирайте обратную связь
Раз в неделю сверяйте ожидание и реальность. Мы, например, регулярно общаемся с представителями заказчиков, запрашивая обратную связь.
Если вы подключили удаленного тестировщика для задач своей компании, контролируйте его сами. Проверяйте, вовремя ли он приходит, доступен ли в рабочие часы, нет ли с ним проблем на проекте.
Так вы быстро определите организационные ошибки и скорректируете работу специалиста.
3. Проводите чек-ап
Проверяйте, что тестировщик делает на проекте. Фактическую работу сможет оценить технический директор или внутренний сотрудник с похожим функционалом.
В ходе чек-апа проверяют:
- соответствует ли заявленное время, уделенное на задачу, полученному результату: если тестировщик отметил, что потратил на задачу 8 часов, то результат должен объективно занимать это время
- правильно ли тестировщик оценил задачу: удаленный сотрудник может не понять ТЗ, не учесть исходных данных или просто сделать не то, что от него требовалось
- все ли сценарии прошел тестировщик: помните — тестирование задачи включает в себя отработку и позитивного, и негативного сценария. Многие тестировщики забывают об этом или не считают нужным проходить негативный
По итогам чек-апа можно найти серьезные ошибки и понять, ориентируется ли тестировщик в проекте. Такой способ проверки помогает быстро скорректировать рабочий процесс, заново проговорить задачи или вовремя вывести тестировщика из проекта.
Недавно мы стали проверять, что делает удаленный тестировщик, которого мы наняли, и нашли грубые ошибки. Пришлось сразу же выводить его из проекта, менять на нового сотрудника и предупреждать об этом клиента. Более того – мы усилили контроль. В итоге мы не потеряли проект и не сорвали сроки, а клиент остался доволен работой.
4. Составляйте план на день
Это усиленная мера контроля, которую надо подключать, если тестировщик только вошел на проект, не отчитывается о выполнении задач или плох в самоорганизации.
Ежедневное планирование задач и отчет в конце рабочего дня возвращают сотрудника в тонус. В ходе отчета тестировщик докладывает, какие задачи выполнил, а какие не смог и почему.
Такой способ поможет быстро выявить любителей мало сделать, но красиво оправдаться. Если же тестировщик грамотно себя показал, сработался с командой и интегрировался в рабочий процесс, можно уйти от ежедневного планирования и переключиться на общие созвоны со всей командой.
5. Сверяйте данные в bug tracker
Bug tracker – программа, куда тестировщики загружают свои задачи и bug report – отчет об ошибках. Если вы подключаете тестировщика на проект заказчика, сверяйте, какие данные он вносит в ваш bug tracker и в bug tracker клиента. Одинаковые ли это данные? Случается, что в bug tracker работодателей тестировщик вносит огромный список задач, а в bug tracker клиентов, который, по опыту, объективнее отражает реальность, загружает список в разы меньше.
Проверяйте bug report, который составляют, если тестировщик работает над короткими задачами вроде проверки приложения или системы. Заранее создайте понятный шаблон в Google Docs, который содержит все стандарты тест-дизайна. Например, bug report в нашей компании состоит из:
- номера
- краткого описания задачи
- шагов воспроизведения
- окружения / версии
- деталей (скриншоты, видео)
- ожидаемого результата
- полученного результата
Следите, чтобы тестировщик соблюдал порядок в организации своей работы. Например, тест-кейсы и прочая документация хранятся в Quse – системе управления тестированием. Все документы должны быть актуальными: это важно, если у вас вышел релиз с новым или дописанным функционалом.
Не бойтесь работать с удаленными тестировщиками: это удобно – вы можете не обладать компетенциями в тестировании и все равно получите результат – и быстро, ведь вы не ограничены собственным штатом инхаус и можете подключить к проекту большую команду.
Забыли ошейники с электротоком.
Вот вообще ничего кардинального нет) Лучше проверить новичка и вовремя вывести из проекта, не слив своих и чужих денег, чем набрать на проект не тех людей.
"Фишка в том, что к тестировщикам на удаленке относятся с опасением. Клиенты видят в этом риск для бизнеса: человек не в штате и непонятно, чем он занят"
А чем принципиально тестировщики отличаются от аналитиков разработчиком и других ролей, почему именно они вызывают опасения? Или у ваших заказчиков байсы насчет тестировщиков есть?
Знаете, я думаю, что принципиально ничем. У меня агентство тестирования, поэтому объективно могу оценить ситуацию с тестировщиками
Гитлер просто сопляк по сравнению с тобой чувак
Комментарий недоступен
Must для новопришедших в IT. Игорь, спасибо!
Все опытом перепроверено) Всегда пожалуйста!
Готова подписаться под каждым пунктом) как человек, причастный к процессу вывода на проекты и контроля за работой удаленных тестировщиков.
Добавить могу лишь одно - сами специалисты зачастую отмечают, как упрощается их жизнь на проекте и в компании, когда есть четкие и понятные метрики контроля качества их работы - тут конечно речь идёт о тех, кто про "работать и зарабатывать", а не о тех, кто имитирует вид бурной деятельности и думает, что в тестировании выдают золотые слитки за "нечего делать".
Комментарий недоступен
"если тестировщик отметил, что потратил на задачу 8 часов, то результат должен объективно занимать это время"
Теоретеги сразу видно! Понятие объективно очень относительно, можно одну и туже задачу тестировать и 5 минут и 8 часов, как можно объективно это оценить*)
Комментарий недоступен
"Недавно мы стали проверять, что делает удаленный тестировщик, которого мы наняли, и нашли грубые ошибки. Пришлось сразу же выводить его из проекта, менять на нового сотрудника и предупреждать об этом клиента."
Рубите с плеча, если вы нашли ошибки это сотрудника то что мешает теперь ему их не допускать и продолжить работать скажем на другом проекте? Меня всегда такие конторки где из за пары ошибок сотрудников выгоняют настораживали, значит вы своих специалистов не цените и берете всех подряд.
Алексей, видно что вы не особо вчитывались в статью и сделали неверный вывод.
Речь идёт о смене тестировщика на проекте, а не увольнение его из компании. Мы ценим своих сотрудником и стараемся каждый случай разбирать отдельно не применяя каких либо санкций.
Как-то слишком много дрочки)). Покупайте офис, покупайте столы, стулья, компьютеры, кофемашину, платите за охрану и парковки. Трудоустраивайте в штат, платите налоги.
И стойте над душой 3 студентов, сколько угодно!
Немного)) У нас есть офис, столы, стулья, компьютеры, кофемашина и все остальное. Устраиваем своих тестировщиков в штат, платим налоги. И они не студенты. Заходите в гости)
В общем галера для тестировщиков, не знаю кто туда только может пойти) Проще сразу на проект устроиться и работать в комфортных условиях.
Лучше всех работают те, кто замотивирован работать.
Вы мотивацией людей судя по всему вообще не занимаетесь.
Если фокусироваться на отчётах и проверках, люди тоже будут фокусироваться на отчётах и проверках, а не на работе. И линять при первой возможности.
Вы, кстати, не рассказали как у вас с текучкой кадров?)
Ну, и о том, что нет никакой специфики в работе с удаленными тестировщиками здесь уже писали. Это заблуждение, что их нужно тотально контролировать, иначе будут дома фигнёй страдать. Никто не мешает страдать фигнёй в офисе. Дело не в локации.
P.S. Тим лид удаленной команды тестирования
Он же рассказал о контроле, а не о мотивации.
Добрый день. Рассказываю: в моей команде минимальная текучка, все мотивированы и, как правило, контроль и мотивация в работе у нас стоят совсем рядом. И да, статья не о мотивации, а о контроле, обратите внимание на заголовок :)
KPI и подсчёты метрик рано или поздно превращается в фарм цифр, проверено и на эти грабли наступали кучу раз. Я даже дополнительные ненужные проверки уникальных полей в автотестах делал, чтобы дотянуть KPI. Но это не улучшает конечного результата, а вот работник находится в стрессе. В любом случае спасибо за статью, теперь в мой черный список попала ещё одна компания, чьим хантерам я точно скажу "Спасибо, не актуально!" :)
Сам по себе аутсорсинг и аутстаф - это нечто из книги "Как управлять рабами". Я не понимаю кого вообще прет работать в таких компаниях - у вас нет ни денег, ни интересных целей. Только перепродажа человекочасов, где маржа очень мала и масштабирование делается так же как и 100 лет назад - количеством людей - это ведь ужасно хреново даже звучит. Не?
А можете рассказать как вы в вашу компанию мечты набираете тестировщиков?)
Судя по всему, их скупают на определенных рынках, по 5$ за штуку)
Мне одному кажется смешным такое описание?)
Это несомненно ор выше гор.
Но давай сделаем скидку, что они не маркетологи, а тех. специалисты в большей мере)
Доставляют коменты с гитлером галерами и током. Да в тексте самые азы контроля, почти что его отсутствие. Если работа не предполагает исчерпываемого дискретного результата, то не будешь мониторить по ключевым метрикам хоть полотера, хоть программиста - на долгосроке тебя же за это и поимеют, оттяпают по полной. Получишь сперва бурный всплеск лояльности, потом тотальную дегенерацию труда. Другое дело, что всегда, где возможно и уместно, надо регламентировать результаты, а не процессы.
Если бы в моей компании ввели нечто подобное, вне зависимости от их мотивации, последнее, что компания от меня услышала бы: Адьос, голодранцы.
Зачем вам наёмные менеджеры, которые решают за вас в вашей компании?
Можно сделать лучше, 10 тасок в день и точка, не сделал пиши отчёт.
Хотя стой тогда можно лоу приорити баги заводить на локализацию.
И регрессию каждую неделю, чтобы точно не думалось.
Сделал - пиши отчёт.
"Добавьте его в общий чат и подключайте к групповым созвонам"
то есть для "inhouse" сотрудников это делать ну нужно?
"Раз в неделю сверяйте ожидание и реальность. Мы, например, регулярно общаемся с представителями заказчиков, запрашивая обратную связь."
Для "inhouse" сотрудников обратная связь не нужна? Если сотрудник в офиcе, то вам плевать что думает клиент?
" Фактическую работу сможет оценить технический директор или внутренний сотрудник с похожим функционалом."
то есть другой удаленный сотрудник оценить не может?
"если тестировщик отметил, что потратил на задачу 8 часов, то результат должен объективно занимать это время"
видимо это тоже не относится к "inhouse" сотрудникам. Пусть делают задачи по 5 минут в день, а потом говно пинают, просто отсиживаясь в офисе
"удаленный сотрудник может не понять ТЗ, не учесть исходных данных или просто сделать не то, что от него требовалось"
как всем известно "inhouse" сотрудники заходя в офис, получают пассивный навык - понимать ТЗ всегда правильно. Так что не нужно за этим следить
"все ли сценарии прошел тестировщик"
в отличии от удаленных работников, офисному это не нужно. Зачем? ведь он в офисе!
"Недавно мы стали проверять, что делает удаленный тестировщик, которого мы наняли, и нашли грубые ошибки. Пришлось сразу же выводить его из проекта, менять на нового сотрудника и предупреждать об этом клиента. Более того – мы усилили контроль. В итоге мы не потеряли проект и не сорвали сроки, а клиент остался доволен работой."
ох как хорошо, что это был удаленный тестировщик, а то если бы был inhouse то вы бы его не вывели из проекта и в итоге сорвали сроки, а клиент остался бы не довольный!!!
Хвала удаленным тестировщикам!!!
Илья, безусловно Вы правы, тоже самое касается и "in-house" сотрудников, но статья про работу с удаленными сотрудниками, именно поэтому в ней рассмотрена специфика взаимодействия с именно с ними.
То отчем говорите Вы заслуживает отдельной статьи, в будущем я постараюсь отдельно осветить эту тему.
Комментарий недоступен
Человек не в ИХ штате – не в штате компании. Для многих это принципиально важно – вот кресло, вот тестировщик, вот мы на него смотрим 5 дней в неделю :) Удаленных сотрудников со стороны подрядчика не видно: они не в штате, непонятно, можно ли управлять ими и как контролировать. Отсюда переживания по этому поводу.
да всех на удаленке контролить надо)
В кандалы заковывать )
" Заранее создайте понятный шаблон в Google Docs, который содержит все стандарты тест-дизайна. "Тест дизайн и баг репорт не связанные вещи от слова совсем, сразу видно статью человек который поверхностно с тестирование знаком писал)
Комментарий удален модератором
Это типичная история про лоу-левел аутсорс конторы которые продают людей по принципу "пучок за пятачок." Адекватный человек с опытом в подобных местах с такими условиями работать не будет.
Уже практически везде контроль ведется посредством ежедневных 10-минутных дейли и проставлением статуса в таск-трекере.
Плохой практикой является постоянный контроль за временем своих сотрудников
1) Во первых смещается акцент на имитацию работы вместо пользы. Там где нужно посидеть поглубже поизучать дефект, пообщаться с разработчиками, человек будет работать на количество ведь на прошлой неделе он закрыл 5 дефектов, а сейчас лишь один. Если встречали историю когда дефект прошел все этапы тестирования, а потом на проде вылезла ошибка в около-очевидном месте то вот это как раз тот случай, а вовсе не про скиллы вашего сотрудника.
2) Во вторых появляется слой сотрудников с большой зарплатой которые ничего не делают кроме того что с утра до вечера придираются к работе других. На 10 тестировщиков будет минимум 1-2 тунеядца, которые не знают контекст и будут докапываться до сотрудников и торопить их. Результат - конфликты в коллективе, спешка, имитация работы. Контроль за качеством продукта должен идти в рамках всей команды, потому что результат общий. Когда результат общий, тестировщик или разраб сам начинает вкладываться достаточно чтобы не подвести остальных и это происходит без давления сверху.
3) В третьих никто на протяжении 365 дней в году не работает 8 часов, а все таки скорее 6 или даже 4. Потому что все живые люди, бывают разные ситуации, разные времена года и красные дни календаря. Но при этом тестирование это все таки про качество в первую очередь, а не количество и за 4 часа можно принести столько пользы, сколько другой не принесет и за два дня.
4) Не понял пункт про внесение в баг трекер компании. У вас два багтрекера и это дефолт? Вы платите деньги чтобы сотрудник тратил время и дублировал то что делает? И кроме того вы выносите приватные дефекты клиента куда то к себе в инфраструктуру? Это уже какая то дичь и просто не понятно ЗАЧЕМ.