Предисловие от 2016 года.
Этот текст был написан мной в качестве подготовки к собранию с большой командой разработчиков. Написан в декабре 2014 — через несколько месяцев после того как мы начали внедрение настоящего тестирования в каждой из групп разработки.
Действующие лица:
- Я — руководитель отдела разработки
- Тимлиды — руководители групп
- Николай — руководитель IT-департамента
- Алексей — заместитель руководителя IT-департамента, известный коуч
- Василий — исполняющий обязанности руководителя группы
- Александр — product owner одного подпроектов
- Дмитрий — product owner нескольких подпроектов, руководитель других менеджеров и product owner
- Илья — верстальщик в одной из групп разработки
Процесс разработки еще не был branch per feature. Были кодфризы в созданием ветки release-xx которые и выкладывались на бой.
Сейчас в 2016 году я решил его опубликовать как есть без изменений, хотя некоторые вещи и выглядят несколько наивными.
Вступление
## Кто работал с тестированием до начала работы в нашей компании?
Этот вопрос задается для разогрева и создания атмосферы вовлеченности в диалог.
Я буду рассказывать о довольно очевидных вещах, но практика показывает, что и очевидные вещи иногда нужно повторять, т.к. они теряются в рутине.
Кто отвечает за задачу
За задачу отвечает разработчик. Она считается сделанной только тогда, когда оказалась на проде и там работает. За любые проблемы с задачей отвечает разработчик и тимлид.
Наказания
Первое. Все видели приказ. Первой жертвой пал Василий. Было нарушено несколько правил, которые привели к серьезным проблемам на проде. У нас 2.5 дня не работал критический функционал. Со стороны бизнеса видно желание, что подобные "страшные" косяки не должны прощаться. Пока отделался легко — просто выговор.
Второе. Николай отвечает за разработку, ходит на пятиминутки. Если раньше мы могли что-то не выносить наружу, если я что-то прощал — теперь не получится. Хорошая сторона — не бывает наказаний без поощрений. Мы добьемся того, чтобы хорошая работа приводила к бонусам.
К делу
Вопросы:
- Кто из вас оценивает сроки по своим задачам?
- Кто чаще укладывается в данные оценки, чем не укладывается?
Особые люди
Тестировщики — особые люди. Они умеют и любят делать то, что не любим делать мы.
Если я поменял только 2 строки, то я уверен, что все сделал правильно и становлюсь заложником своей крутости. На мой вопрос про оценку большинство согласилось с тем, что ошибаются, то есть мы считаем себя круче, чем есть на самом деле. Это реальность.
На лекциях Алексея все видели график.
Я очень хорошо знаю по себе что "ну там-то я точно все правильно сделал и ничего сломать не мог". Это отлично, что мы считаем себя крутыми и уверенными в себе людьми. Хуже если мы будем постоянно сомневаться в своих силах, не браться за тяжелые задачи.
Так вот тестировщики это те люди, которым не важно сколько строк поменяли. Они будут проверять задачу целиком. Им не сложно из-за двух строк прогнать регресс и проверить связанный функционал или вообще проверить все.
Поэтому никогда не приходите к тестировщикам со словами: "там совсем чуть-чуть поменялось, давай быстро проверим." Иначе вы сделаете их программистами (не в смысле что они начнут писать код) и толку от них не будет. 🙂
Ценный ресурс
У нас 2 тестировщика на 15 человек. Этого очень мало. Они — ценный ресурс. Они делают то, что вы сделать не можете, не любите, в чем вы не профи, так что нужно делать все, чтобы им было удобно проверить вашу задачу. Они дополнительный фильтр на пути того что вы сделали и пользователями, бизнесом. Дополнительная страховка, что те ошибки, которые мы допустили при разработке, будут замечены. А так как за задачу отвечает разработчик и вина на разработчике за косяки — глупо не пользоваться этой дополнительной защитой.
Не сваливайте свои факапы на тестировщиков
Вы взяли задачу. Сказали что сделаете за 2 дня. Бизнесу озвучили, что через 5 дней будет на проде. С запасом.
Вы делали в итоге 4 дня. Пришли под вечер 5-ого дня к тестировщику и хотите, чтобы он проверил все прямо сейчас. Т.к. сроки уже совсем горят и провалены.
Не катит!!! Надо было быстрее делать. Тестироваться задача будет столько, сколько посчитает необходимым тестировщик. Плюс у него есть свои планы по тестированию. Мы же не любим, когда к нам приходят и переключают с одной задачи на другую. Отвлекают. Тестировщики — точно так же.
Так что этот провал сроков из-за того, что вы делали задачу в 2 раза дольше, а не из-за того, что тестировщик сможет ее взять лишь на следующий день и будет тестировать ее полдня. То есть виноват разработчик.
При этом в отличие от разработки сроки на тестирование более предсказуемы. Условно если разработчик сделал что-то за 5 минут, то тестирование займет 30 минут. Если за 30 минут, то тестирование займет 30 минут. Если сделал за 1 день, то тестирование займет 2 часа. Если сделал за 5 дней, то тестирование займет 6 часов.
Но бывают и исключения.
Еще один пример с задачей Ильи. Которая висела в отдельной ветке (не запушенная)? Не была сделана до отпуска. Потом был отпуск у Ильи. Нас это парило… Но прошло 3 недели. Как только разработчик вернулся — все появилась срочность. Product owner сделал ее Expedite. Ее вдруг надо проверить прямо сейчас, на все забить и тестировать!? Нет!
Почему задачу не выложить сначала на dev, чтобы ее проверили там, а не сразу лить в ветку откуда она со следующим релизом попадет на прод? Все в курсе как сейчас работать над Expedite задачами куда и как они push-атся?
Не давайте оценку сроков
Никто из нас не любит, когда нам говорят сколько мы должны делать ту или иную задачу. Когда говорят "там на 5 минут". А мы собираемся делать 5 часов, т.к. там уже столько костылей, что нужно сделать рефакторинг. Или потому что внутренний перфекционист не дает нам сейчас написать кривой код.
Так же надо относиться и к тестировщикам. Они лучше знают сколько и как нужно тестировать задачу.
У них есть такой же тех-тест-долг как и у нас. В конце-концов у них может просто интуиция сработать, что надо эту задачу посмотреть более детально.
Или написать наконец-то тест-кейс для тестирования этого функционала.
Относитесь к ним так же как вы хотите чтобы относились к вам.
Тестировщики — часть процесса
Тестировщики — часть процесса разработки. Это не тормозящее все звено. Это так же как релиз. Нельзя поменять сразу на проде файлик по ftp. Все понимают почему это хорошо, что так нельзя? Так же надо привыкнуть и понять почему тестировщики — это хорошо. Это необходимый шаг процесса.
Что проверяет тестировщик
- Что все шаги технического задания были выполнены. Чтобы мы не получили "втык" от product owner, что забыли тот или иной пункт.
- Что техническое задание было поставлено в целом корректно и в нем все учтено.
- Как должно выглядеть на мобильном, как на английском языке, что должны видеть из Китая, как должно отображаться на американской версии сайта.
- Что при реализации этой задачи ничего не сломалось из остального функционала.
- Что аналитик не "налажал" и не ошибся.
В идеале проверка ТЗ должна проводиться на этапе анализа задачи product owner-ом, технической экспертизы руководителем группы. Это нужно чтобы экономить время разработки, потому что если ТЗ плохое и после реализации обнаружились проблемы, то это дополнительные расходы которые мы понесем, когда задача вернется на доработку с тестирования.
Плюс разработчик это воспринимает очень ранимо — в ТЗ не было, а на тестировании завернули. Но мы обязаны так делать! С этим надо смириться, так как мы направлены сейчас на качество, а не на скорость.
Это очень важно понимать. Тестировщики — так же ваша защита от плохого ТЗ. Вы можете подходить к тестировщику чтобы он посмотрел на задачу до того как вы будете ее делать. Мы договорились на такие задачи вешать метку ПТЗ — Плохое Техническое Задание.
Найденные ошибки всех 3-х этапов тестировщик описывает и ставит вопрос перед разработчиком, тимлидом, product owner, руководителем отдела об их критичности. И получив информацию о том, что должно быть исправлено и без чего задача не может попасть на прод, отслеживает это при очередной передаче задачи на тестирование.
Тестировщики — не суппорт
Не знаю почему это надо объяснять. Отличный пример у нас перед глазами — 1.5 года тестировщиков-суппортеров и Димы. Забудьте про то, что тестировщики вам что-то должны. Они должны детально описать ошибку, которую обнаружили при тестировании. Но они не должны по вашему письму садиться и исследовать проблему, находить шаги для воспроизведения по письму от службы поддержки.
Это задача тимлида и/или задача аналитика — найти и разобраться. Не забывайте что тестировщики — ценный ресурс. Их сильно меньше чем нас. Когда их станет достаточно — тогда этот пункт можно будет пересмотреть.
Сейчас в первую очередь тестировщики занимаются приемкой задач, чтобы в том, что мы делаем нового, было как можно меньше ошибок. Это основной вектор. Все остальное — побочная положительная деятельность, но требовать мы от них это не должны.
Описывать где проверять задачу
Опять же следствие из вышесказанного — пишите где задачу можно смотреть. Пишите только после того, как убедились в том, что задача действительно там оказалась.
Пишите, что задача на dev выложена. Пишите, что она теперь на tst выложена. Если что-то тупит и тормозит и вы запушили, но задача не оказалась на tst — тестировщик вернет вам задачу. Это будет ваша проблема. Вы должны передать задачу на тестирование и сделать все, чтобы тестировщик ее посмотрел.
В новой схеме с бранчами и pull-реквестами через Jira это не будет нужно. Но пока нужно. Так же как и запрет на релиз. Выложили на tst — повесьте запрет на релиз, чтобы задача не попала на прод случайно. Не тестировщик должен вешать — а вы, причем сразу как только запушили в ветку release-xx.
Тестировщик может быть сейчас на обеде, он может заниматься другой задачей. И когда дойдет до задачи и повесит запрет на релиз — день может пройти. Я не понимаю почему разработчикам про такие вещи вообще нужно говорить. Это же классический рейскондишн. Плюс снова повторю: тестировщик один — вас много.
Описывать особенности реализации
Если при реализации задачи вы заметили, что в ТЗ что-то не учтено, если вы пообщались с дизайнером, product owner-ом и что-то решили делать иначе или по другому, то это должно быть отражено в комментариях. А product owner должен поменять формулировку задачи. Когда все сделали — резюмируйте все сделанное в своем комментарии. Чтобы не надо было читать тестировщику все 50 комментов в задаче и накладывать в голове патчи из комментов на исходную формулировку. 🙂
NoQA
Итак, надеюсь мы поняли, что за задачу отвечает разработчик. Вы имеете возможность отрелизить задачу в обход тестирования, забив на все правила. Но нужно понимать, что ответственность за это будет на вас и на тимлиде. И если с задачей возникнут проблемы на проде — по шапке получите вы.
Уверенны в себе и своих изменениях — выкладывайте. Чтобы отслеживать такие задачи мы сделали в Jira автоматическое навешивание метки noqa на задачи которые были передвинуты в состояние "Проверено" человеком, не входящим в группу Тестировщики.
Это сделано, чтобы не бюрократизировать процесс и не закрывать правами такие передвижения задач. Всегда может что-то срочное свалиться и возможность исправить и выложить должна быть.
Так же если пришел product owner и попросил выложить без тестирования. Голову включает разработчик и тимлид. Отвечать за то, что задача выложена непроверенной будете вы. Никто к сожалению не отменял product owner-ов которые своими неправильными действиями могут привести проект к развалу.
Пример Саши
Саша привел хороший пример, что если product owner скажет, что на сайте должно быть написано "Ху..", то так и должно быть. Но сказав А, надо сказать и Б. Что задача тестировщика при этом убедиться, что написано именно это слово, что оно индексируется поисковиком, что оно написано на русском языке, правильным шрифтом в правильном месте и не появилось на других страницах и на других языках кроме русского, а если появится то с правильным переводом.
Капризы и придирки
Мы все делаем общее дело. Не надо никаких капризов и придирок. Если в задаче достаточно данных, чтобы ее правильно сделать или правильно исправить найденные при тестировании ошибки — не надо лишней бюрократии. Поверьте в этой борьбе проиграют разработчики и проект. Плюс не надо забывать, что мы не берем junior-ов. А значит по любой задаче мы ожидаем включения головы при ее решении.
Переключение на другие задачи
Никто из нас не любит когда нас переключают на другие задачи. Занимался одним, переключили на другое, потом на третье в итоге к первому вернулся через несколько дней. Тестировщики совершенно так же не любят этого. Им так же нужно переключаться. Все те же правила переключения контекстов работают. Не забываем, что план работы на день мы составляем на утренней пятиминутке. И если вы не предупредили, что вашу задачу надо будет проверить — не надо ожидать чуда. Тестировщик уже может быть весь день запланировал. И если задач не будет он займется автоматизацией, изучением проекта, написанием тест-кейсов и тестированием того, что было сделано когда-то раньше и нормально не проверено потому что торопили скорей-скорей.
Тестировщики — часть команды
Не забывайте что тестировщики — это часть вашей команды. Вы все вместе. Каждый из вас делает команду сильнее. Так же и тестировщик делает вас сильнее. Их надо любить, уважать.
Баги
Тестировщик при нахождении бага как в процессе тестировании задачи, так и найденные побочные ошибки, заводит в Jira. Описывает их важность и критичность после чего идет к тимлиду и product owner, чтобы приоритезировать эти баги. То есть по каждому багу от тестировщика эти ребята должны принять решение об их важности на текущий момент времени.
Не маги
Тестировщики не маги. И если ошибка плавающая и ее никак не удается воспроизвести, то это задача тимлида и разработчиков сделать все, чтобы ошибку можно было найти. Сделать больше логов, расставить дополнительные проверки в коде. Не надо ожидать от них что они будут тратить неделю на то, чтобы так и сяк найти плавающий баг. Не забывайте про белый ящик и черный ящик
Не надо вмешиваться в чужую профессию
Не надо. Мы не любим, когда нам дают советы как сверстать или запрограммировать. Так же не надо вмешиваться в работу тестировщиков. Они не первый день занимаются этим. У них свои задачи и приоритеты которым не надо мешать. Надо помогать.