Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Зачем нужна стратегия тестирования?
Кто составляет стратегию?
В первую очередь, конечно же, QA и обязательно менеджер проекта.
Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!
В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.
В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.
Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.
Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.
Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.
На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.
Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.
Здесь важно ответить на вопросы о проекте:
Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.
Подобным образом необходимо разобрать все остальные типы тестирования:
и другие.
На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.
В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).
Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.
Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.
Например, это могут быть:
Нужно договориться на берегу, а возможно, дальше и регулярно пересматривать формат ведения тестовой документации:
Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:
В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.
Проговорите с командой ключевые моменты:
(Подробнее о способах описывать баги и userstory мы писали в этой статье).
Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.
На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.
Стоит обсудить такие вопросы:
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
0. Разберемся на берегу
Зачем нужна стратегия тестирования?
- Для организации процесса в условиях ограниченных ресурсов. Поэтому для начала неплохо бы осознать, какими ресурсами мы располагаем.
- Для того, чтобы все участники проекта понимали роль тестирования, что оно может дать, какие профиты мы с этого получим. Чтобы у всех были равные ожидания и понимание, что вообще происходит в области контроля качества. А также для выявления возможных проблем, которые неизбежно станут очевидными в процессе обсуждения.
Кто составляет стратегию?
В первую очередь, конечно же, QA и обязательно менеджер проекта.
Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!
1. Какие типы тестирования будем применять на проекте и почему
В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.
Тестирование установки версии
В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.
Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.
Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.
Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.
Тестирование производительности
На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
| Дано | Решение |
|---|---|
| Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей. | Имеет смысл запланировать volume-тестирование с большими объёмами данных. |
| Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика. | Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду. |
| Приложением пользуется несколько человек в неделю, объём данных минимален. | Тестирования производительности не требуется. |
Регрессионное тестирование
На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.
| Дано | Решение |
|---|---|
| Выкатываем первую версию продукта или модуля программы. | Регрессионное тестирование не требуется. |
| Проект очень большой, и на проведение полного регресса перед релизом новых фич требуется время, сопоставимое со сроком разработки. Требуемый темп поставок этого не позволяет. | Решаем, что регрессионное тестирование не проводим, а больше внимания уделяем другим видам тестирования и мониторингу. |
| Взаимодействие между микросервисами покрыто контракт-тестами. | Проведение полного регресса нецелесообразно. В рамках ручного тестирования проводим регресс функциональности по рекомендации разработчика. |
Интеграционное тестирование
Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.
| Дано | Решение |
|---|---|
| Данные по продажам из портала передаются в аналитическую систему. | Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге. |
Тестирование локализации
Здесь важно ответить на вопросы о проекте:
- какие языки должны поддерживаться,
- предусматриваем ли подключение дополнительных локализаций в процессе эксплуатации решения,
- в каких странах будут работать наши пользователи,
- будут ли происходить продажи и в каких валютах,
- требуется ли работа с часовыми поясами.
| Дано | Решение |
|---|---|
| В системе предусмотрено 2 языка: русский и английский. | Имеет смысл обсудить, каким образом мы будем понимать, интерфейс на каком языке показывать пользователю. |
| Заказчик просит сделать приложение мультиязычным. | Стоит ответить себе на вопросы, каким образом будем верифицировать тексты, откуда мы возьмём тексты на арабском, как будет адаптирован экран для текста, который пишется справа налево. |
Кроссбраузерность и кроссплатформенность
Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.
| Дано | Решение |
|---|---|
| Пользователями мобильного приложения являются сотрудники по всей стране. | Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать. |
| У нашего приложения корпоративные пользователи на стационарных машинах. | Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности. |
Подобным образом необходимо разобрать все остальные типы тестирования:
- Функциональное (проводим или нет),
- Приёмочное (кто его проводит и каким образом),
- UX/UI (каковы объективные критерии хорошего интерфейса)
- Модульное и юнит (кто пишет контракт-тесты, кто пишет юнит-тесты и пишем ли их вообще),
- Тестирование безопасности (кто гарантирует безопасность данных, и насколько система устойчива ко взлому),
- Отказ и восстановление (как поведет себя система в экстренных обстоятельствах)
и другие.
2. Приоритеты в тестировании
На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.
В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).
| Дано | Решение |
|---|---|
| Нашей программой пользуются в аэропортах для продажи услуг пассажирам при посадке в самолет. И если в этот момент случится какая-то ошибка, то у нас не будет времени на хот-фикс. Поэтому ошибок быть не должно! | Проверяем сценарий использования в аэропорту в первую очередь. |
3. Окружения для работы
Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
| Дано | Решение |
|---|---|
| На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности. | Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA). |
| Регулярно проводятся сессии бета-тестирования. | Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение. |
4. Работы тестировщика на проекте
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.
Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.
Например, это могут быть:
- оценка задач спринта на полноту и непротиворечивость,
- оценка трудозатрат на тестирование,
- подготовка чек-листов для тестирования (или тест-кейсов),
- ревью сценариев автотестов,
- написание функциональных автотестов,
- непосредственно ручное тестирование,
- деплой изменений на окружения,
- актуализации стратегии тестирования и т.д.
5. Тестовая документация на проекте
Нужно договориться на берегу, а возможно, дальше и регулярно пересматривать формат ведения тестовой документации:
- какую тестовую документацию будем вести на проекте,
- будем ли писать тест-кейсы,
- ведем ли чек-листы
- и как часто обновлять эту документацию.
| Дано | Решение |
|---|---|
| Для примерно трети функциональности системы уже написано порядка 300 тест-кейсов. Их надо не только периодически проходить, но и время от времени актуализировать. | В условиях ограниченных ресурсов мы решили не работать с тест-кейсами, а ограничиться чек-листами для каждой конкретной задачи. И в результате экономим время на поддержку документации без потери качества тестирования. |
6. Каким образом генерируются тестовые сценарии
Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:
- какими техниками тест-дизайна имеет смысл пользоваться. В рамках этого пункта полезно составить список объектов, с которыми работает приложение, и их классы эквивалентности.
- какие эвристики и банальный жизненный опыт помогают придумать сценарии тестирования для конкретного проекта. Для мобильных приложений удобно использовать стандартные эвристики, например, “I SLICED UP FUN”.
| Дано | Решение |
|---|---|
| На страховом проекте пользователь (агент) должен провести осмотр машины, в процессе которого необходимо сделать фотографии и загрузить их на сервер. Здравый смысл подсказывает, что в гаражах вряд ли есть wifi. А порой, там нет и мобильной связи. | Значит, надо проверить приложение не только при работе с 3G, но и при отсутствии связи как таковой. |
| Любое действие пользователя в мобильном приложении авиакомпании — это часть некоего сценария. Например, нельзя выписать билет, не создав предварительно бронь. | Поэтому логично использовать технику «сценарии использования». |
7. Порядок работы с трекером
В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.
Проговорите с командой ключевые моменты:
- Как мы будем отличать ошибки, найденные нами, от ошибок, найденными заказчиками (и надо ли нам их различать),
- Как оформлять доработки,
- Надо ли отличать доработки, которые мы придумали сами, от тех, которые попросил сделать заказчик. Каким образом?
- В какой статус ставить ошибку, если она не повторилась,
- Какой статус считать конечным.
| Дано | Решение |
|---|---|
| Тестировщик создаёт bug. Разработчик не может его воспроизвести, переводит в статус rejected. | Тестировщик перепроверяет задачу и ставит статус Closed (конечный), если ошибка и правда ушла, либо уточняет описание и возвращает в New. |
| Заказчик ставит задачу на доработку. Разработчик понимает, что ему не хватает данных для реализации. | Разработчик переводит задачу в статус Feedback. |
(Подробнее о способах описывать баги и userstory мы писали в этой статье).
8. Критерии начала и окончания тестирования
Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.
На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
| Дано | Решение |
|---|---|
| На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования. | Считаем задачу проверенной, если мы прошли все пункты чек-листа. |
| На проекте ведется работа по спринтам. | Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше. |
| На проекте составлен список функциональности по приоритетам. | Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка. |
| На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом. | Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5). |
9. Инструменты для работы
Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.
Стоит обсудить такие вопросы:
- Какие инструменты нам нужны для ведения тестовой документации,
- Какими инструментами можно подготовить тестовые данные,
- Какие инструменты нужны для автоматизации.
| Дано | Решение |
|---|---|
| Для описания реализованной функциональности решили использовать mind-maps. | Ребята в команде работают на разных платформах, поэтому нужно выбрать такой формат файла mind-map, с которым можно работать и в винде, и в линуксе, и на маке. |
| Мы договорились, что нам нужна автоматизация на проекте. | Значит, нам нужны инструменты, которые позволят подготавливать тестовые данные (например, накатывать скрипты на БД), позволят осуществлять запуск в рамках конвейера (например, newman), позволят создавать заглушки (например, WireMock). |
10. Оценка качества проекта и инструменты мониторинга
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
- Каким образом мы будем отслеживать ошибки в проде,
- Каким образом будем собирать обратную связь от пользователей,
- Каким образом будем собирать статистику использования наших фич.
| Дано | Решение |
|---|---|
| После релиза новой фичи системы настраиваются мониторинги использования (например, количество продаж услуги). | Снижение показателей является триггером для расследования. Возможно, фича работает не так, как ожидалось, или мы не реализовали часть сценария. |
| Мы настроили в программе мониторинг скорости выполнения основных операций. | Критерием качества работы будет то, что при наплыве пользователей скорость выполнения не падает. |
Заключение
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.
- Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей.
- Вполне нормально, что не всегда сразу получается ответить на все поставленные вопросы. Это повод ещё раз поговорить с заказчиком или пользователями продукта.
- Проект растет, и если вчера заморачиваться с производительностью было рановато, то завтра возможно будет уже пора. Поэтому после составления стратегии важно её регулярно актуализировать и пополнять и доводить изменения до команды.
- После написания стратегии обычно становится понятно, где провалы в тестировании и что надо сделать. Это повод поставить задачи, смотреть динамику и… обновить стратегию через какое-то время.
Комментарии (9)
NaCl
31.10.2018 09:58+1Хорошая получилась памятка :) Выглядит действительно немного громоздко, но в реальности это все очевидно занимает меньше времени, и многие вещи наверняка делаются на автомате :)
Интересно, в какой момент вы проводите этот процесс? Как соблюдается баланс между ранним планированием и получением как можно большего количества информации о внутренностях тестируемого продукта? Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?
Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»?eastbanctech Автор
31.10.2018 12:23Дополним предыдущий ответ.
Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?
Да, вы совершенно правы, смысл в итеративности.
pingywin
31.10.2018 11:30+1Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
Попробую ответить на этот вопрос с менеджерской колокольни.
Будет сложно описать в комментариях как разрабатываются KPI и кто в этом участвует. Но попробую привести примеры.
Есть Бизнесовый KPI, кратко можно сформулировать так «Объем продаж через нашу систему». Продажи растут, бизнес рад. Данный KPI разрабатывался вне стратегии тестирования с участием заинтересованных сторон проекта. В разработке идеологически и технически участвовали заказчик, руководство компании, проектная команда.
Есть другие KPI, которые мы не обсуждаем с клиентами (считаем, что они априори с ними согласны). Например, мы выпускаем новый функционал. До выпуска мы знаем, что новой функцией должны пользоваться около 100 человек в день. При разработке мы закладываем нужные метрики и после выпуска настраиваем дашборд в Grafana на основе этих метрик, который отобразит нам сколько человек в сутки пользуется новой функцией. Такой дашборд нужен чтобы понять, что мы добились цели и получили тех 100 пользователей, а так же чтобы те кто участвовал в выпуске новой функции ощутили, что их работа не легла в стол. Сделал работу, увидел результат.
Если мы не видим на дашборде результата, то нам нужно разобраться, что пошло не так. У нас есть несколько каналов получения обратной связи. Можно анализировать логи, которые мы заранее написали очень широко и информативно. Можно напрямую выходить на пользователей, если мы по логам увидели, что он свернул «не туда» или получил ошибку. Так же у заказчика есть свой инструмент для коммуникации с пользователями.
Есть технические KPI, скорость выполнения определенных операций и средне взвешенное количество ошибок в единицу времени. Значения для данных KPI получены эмпирическим путем.
В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»
Это контракт между менеджером и тестировщиком. Таким образом мы формируем правильные ожидания у обоих. Менеджер не выбирает с кем он будет работать, у нас нет такой роскоши. Мы стараемся поддерживать компетенцию всех специалистов на уровне. Если кто-то что-то не умеет, то научим и подтянем.NaCl
31.10.2018 12:32А бывает такое, что уже в процессе разработки оказывается невозможным поддержать, например, планируемую нагрузку? У вас есть какие-то лайфхаки на этот случай?
pingywin
31.10.2018 13:00Лайфхаков, наверное, нет. Масштабируемость должна быть заложена в архитектуру приложения. Проблему нагрузки можно решить запустив приложение на нескольких серверах, но в таком случае появляется целый ворох проблем под названием «распределенная система». Здесь будет и балансировка и репликация данных и распределенные пользовательские сессии и распределенные транзакции (или без транзакций вообще) и многое другое. Все это должно быть заложено в приложение, либо это нужно реализовывать, коли возникла необходимость.
Так же можно поставить более мощное железо и на какое-то время решить проблему. Но весь мир идет по первому пути :)
izzmajjra
Стратегия тестирования = тест-план в вашем подходе?
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Эту задачу (в том числе и для руководства) лучше решает что-то типа тест-плана за 10 минут, одностраничного тест-плана
Подробное перечисление видов тестирования с обоснованием того, зачем оно применяется не излишнее ли? Имхо, полезней описать что мы тестируем, а что не тестируем в нашем приложении (Например расписать из каких модулей/функционала состоит наше приложение и что из этого мы тестируем. Зачастую не функциональные требования остаются за скобками и тестирование говорит, что производительностью мы не занимаемся. Либо указываются ограничения для интеграций — например тестирование только на заглушках или эмуляторах)
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
В таком виде выглядит именно как самоцель, имхо. Слишком уж громоздкий документ выйдет, если следовать инструкции. И времени сожрет на создание и актуализацию не мало. Решить задачи можно более простым доком.
eastbanctech Автор
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
izzmajjra
Может не так выразился. В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Из интересного — вы предлагает в описывать в стратегии и правила/рекомендации/требования к тест-дизайну. Такого не практиковали, будет возможность можно опробовать. Как минимум один случай всплыл в памяти, когда это бы пригодилось команде.
+ тест-план или тестовая стратегия решает дополнительно еще одну задачу, для вас, может быть не актуальную — возможность ротации, безболезненной смены команды или замену людей в команде. Имхо, в том виде, что у вас документ эту задачу решит очень даже неплохо.
eastbanctech Автор
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.