Комментарии 9
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
Стратегия тестирования = тест-план в вашем подходе?
Для того, чтобы все участники проекта понимали роль тестированияМногостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Эту задачу (в том числе и для руководства) лучше решает что-то типа тест-плана за 10 минут, одностраничного тест-плана
Подробное перечисление видов тестирования с обоснованием того, зачем оно применяется не излишнее ли? Имхо, полезней описать что мы тестируем, а что не тестируем в нашем приложении (Например расписать из каких модулей/функционала состоит наше приложение и что из этого мы тестируем. Зачастую не функциональные требования остаются за скобками и тестирование говорит, что производительностью мы не занимаемся. Либо указываются ограничения для интеграций — например тестирование только на заглушках или эмуляторах)
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами)
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей
В таком виде выглядит именно как самоцель, имхо. Слишком уж громоздкий документ выйдет, если следовать инструкции. И времени сожрет на создание и актуализацию не мало. Решить задачи можно более простым доком.
Стратегия тестирования = тест-план в вашем подходе?
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
KPI мы используем не для того, чтобы отследить, работает или нет.
Может не так выразился. В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Из интересного — вы предлагает в описывать в стратегии и правила/рекомендации/требования к тест-дизайну. Такого не практиковали, будет возможность можно опробовать. Как минимум один случай всплыл в памяти, когда это бы пригодилось команде.
+ тест-план или тестовая стратегия решает дополнительно еще одну задачу, для вас, может быть не актуальную — возможность ротации, безболезненной смены команды или замену людей в команде. Имхо, в том виде, что у вас документ эту задачу решит очень даже неплохо.
В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.
Хорошая получилась памятка :) Выглядит действительно немного громоздко, но в реальности это все очевидно занимает меньше времени, и многие вещи наверняка делаются на автомате :)
Интересно, в какой момент вы проводите этот процесс? Как соблюдается баланс между ранним планированием и получением как можно большего количества информации о внутренностях тестируемого продукта? Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?
Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»?
Интересно, в какой момент вы проводите этот процесс? Как соблюдается баланс между ранним планированием и получением как можно большего количества информации о внутренностях тестируемого продукта? Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?
Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»?
Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
Попробую ответить на этот вопрос с менеджерской колокольни.
Будет сложно описать в комментариях как разрабатываются KPI и кто в этом участвует. Но попробую привести примеры.
Есть Бизнесовый KPI, кратко можно сформулировать так «Объем продаж через нашу систему». Продажи растут, бизнес рад. Данный KPI разрабатывался вне стратегии тестирования с участием заинтересованных сторон проекта. В разработке идеологически и технически участвовали заказчик, руководство компании, проектная команда.
Есть другие KPI, которые мы не обсуждаем с клиентами (считаем, что они априори с ними согласны). Например, мы выпускаем новый функционал. До выпуска мы знаем, что новой функцией должны пользоваться около 100 человек в день. При разработке мы закладываем нужные метрики и после выпуска настраиваем дашборд в Grafana на основе этих метрик, который отобразит нам сколько человек в сутки пользуется новой функцией. Такой дашборд нужен чтобы понять, что мы добились цели и получили тех 100 пользователей, а так же чтобы те кто участвовал в выпуске новой функции ощутили, что их работа не легла в стол. Сделал работу, увидел результат.
Если мы не видим на дашборде результата, то нам нужно разобраться, что пошло не так. У нас есть несколько каналов получения обратной связи. Можно анализировать логи, которые мы заранее написали очень широко и информативно. Можно напрямую выходить на пользователей, если мы по логам увидели, что он свернул «не туда» или получил ошибку. Так же у заказчика есть свой инструмент для коммуникации с пользователями.
Есть технические KPI, скорость выполнения определенных операций и средне взвешенное количество ошибок в единицу времени. Значения для данных KPI получены эмпирическим путем.
В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»
Это контракт между менеджером и тестировщиком. Таким образом мы формируем правильные ожидания у обоих. Менеджер не выбирает с кем он будет работать, у нас нет такой роскоши. Мы стараемся поддерживать компетенцию всех специалистов на уровне. Если кто-то что-то не умеет, то научим и подтянем.
А бывает такое, что уже в процессе разработки оказывается невозможным поддержать, например, планируемую нагрузку? У вас есть какие-то лайфхаки на этот случай?
Лайфхаков, наверное, нет. Масштабируемость должна быть заложена в архитектуру приложения. Проблему нагрузки можно решить запустив приложение на нескольких серверах, но в таком случае появляется целый ворох проблем под названием «распределенная система». Здесь будет и балансировка и репликация данных и распределенные пользовательские сессии и распределенные транзакции (или без транзакций вообще) и многое другое. Все это должно быть заложено в приложение, либо это нужно реализовывать, коли возникла необходимость.
Так же можно поставить более мощное железо и на какое-то время решить проблему. Но весь мир идет по первому пути :)
Так же можно поставить более мощное железо и на какое-то время решить проблему. Но весь мир идет по первому пути :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как составить стратегию тестирования: версия настоящих инженеров