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