Каждый мужчина должен построить дом, посадить дерево и воспитать сына... Задача каждого менеджера подготовить себе замену, но сказать и сделать - не одно и то же.
Как выбрать подходящего кандидата, как подойти к его обучению, какие навыки развивать, как представить замену клиенту, сколько времени потребуется, где найти на это время, зачем все это нужно?
Ответы на эти и другие вопросы, необходимые для подготовки управленца, который с легкостью заменит вас на проекте, освещены в этом докладе.
Выступление Сергея Атрощенкова на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
Когда-то давным-давно, в середине 60-х, в США появился праздник Кванза. Это один из афроамериканских фестивалей, представляющий собой неделю предновогодних торжеств. Считается, что праздник «первого плода» отмечался в древней Нубии в эпоху фараонов, кроме того, его праздновали в средневековых африканских государствах Йоруба и Ашанти. В основу праздника положены африканские традиции и глубинная мысль, провозглашающая Семь Принципов жизни и ценностей сообщества: Единство, Самоопределение, Коллективизм, Совместная экономика, Цель, Творческий потенциал и Вера.
Казалось бы, при чем здесь тестирование?
Да при том, что принципы данного веселого мероприятия очень хорошо ложатся в основу работы любых IT команд, а в нашем случае – тестировщиков.
А когда таких принципов целых семь… Есть где развернуться и организаторским навыкам, и фантазии, и аналитическим способностям всё-улучшающего ума.
Чем принцип Единства не прекрасная возможность объединять различные роли: аналитиков, разработчиков, программистов, системных администраторов в едином порыве, нацеленном на работу над качественным продуктом?
А принцип Творчества? Чем не возможность проявить себя в тест-аналитике?
Я расскажу о том, как принципы Кванзы можно применять в своей команде, например в команде тестирования, если есть полное взаимопонимание между различными проектными ролями.
После этого доклада у тест-менеджеров и им сочувствующих сложится понимание того, как можно работать с командой не держа в голове кучу умных слов. Простое мнемоническое правило, легко запоминаемое и покрывающее навыки: организации команды, персональной работы с сотрудниками, мотивации, создания миссии команды и межролевых взаимодействий после внедрения сможет упростить им жизнь.
Новый код появляется по кусочкам - фронтэнд уже готов, но API, к которому он обращается, еще не установлен на тест-сервере. Попутно идет оптимизация производительности.
Один тестировщик разбирается с критически срочным запросом службы поддержки, другой предположительно ждет новую фичу с минуты на минуту, а третий вообще не может работать.
…Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 50 сделаете второе, то и первое будет получаться!
Давайте теперь посмотрим, как считать время на тестирование, на конкретных примерах.
Выступление Евгения Ефимова на онлайн-конференции для тестировщиков Fun ConfeT&QA
«А сколько времени тебе надо что бы протестировать билд?» и «А почему так много?» одни из наиболее часто задаваемых вопросов QA-инженерам независимо от проектов и места работы.
Я расскажу, как ответить на эти вопросы себе и другим и быть уверенным в своем ответе.
Мы посчитаем, из каких кусочков состоит время, затрачиваемое на тестирование, и научимся составлять из этих кусочков формулы, подходящие вашему конкретному проекту и позволяющие точно и обоснованно отвечать на вопрос, сколько времени нужно на то или иное тестирование.
Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно. Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.
Зачем оценивать?
Любые метрики оценки – трата времени. В это время можно тестировать, заводить баги, готовить автотесты. Какую такую магическую пользу мы получаем благодаря метрикам тестового покрытия, чтобы пожертвовать временем на тестирование?
Поиск своих слабых зон. Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу, а ответы на них даёт оценка покрытия.
Фокус внимания. Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.
Глупые люди наступают на одни и те же грабли потому, что ничему не учатся. Тестировщики наступают на одни и те же грабли потому, что надо воспроизвести дефект.
На конференциях принято рассказывать: мы сделали такую крутую штуку! Мы внедрили опупенный инструмент! Посмотрите, как мы справились с этими техниками… Такие рассказы слушать приятно, и есть, чему поучиться. Но наши рабочие дни обычно состоят не из геройских подвигов! Мы сталкиваемся с проблемами и трудностями:
пропустили критичный дефект
не успели провести тестирование вовремя
автотесты не окупаются и требуют слишком много времени
нет сил актуализировать тесты и планы
Что делать при возникновении таких проблем? Я знаю отличное решение:
расплакаться! Но на докладе расскажу о другой реакции: как извлекать полезный опыт из каждой допущенной ошибки.
В черном-черном городе.. на черной-черной горе.. в черном-черном офисе.. черные-черные разработчики.. писали черные-черные программы... И САМИ ИХ ТЕСТИРОВАЛИ!!!!
Каждый тестировщик будучи junior-ом слышал такую страшилку от старших товарищей.
Сегодня в тренде кроссфункциональные команды. Роль тестировщика не привязана к определенному человеку - тестировать может каждый. Некоторые прогрессивные команды вовсе обходятся без тестировщиков. То, что когда-то было страшной сказкой становится реальностью.
Приглашаю коллег обсудить этот тренд. Чем грозит (и грозит ли) тестирование продукта без выделенного специалиста. В чем плюсы, в чем минусы такого подхода. На каких проектах он применим, на каких - нет. Как обеспечить качество продукта без специалистов по качеству.
И как жить тестировщикам, которых "оставили без работы".
