Термины написаны не копи-пастом из вики, а человеческим языком. Группировка также не из вики и вообще не по ISO 9000 и в таком роде. Нам просто нужно подразумевать одно и тоже.

Вводные термины

• релиз кандидат, release candidate: сборка, смотрящая на прод серверы, без логов, с обфускацией, в финальном состоянии. В общем случае подразумевается, что в ней не будет никаких новых проблем выше 4-го уровня. Эта же сборка потом раздаётся пользователям

• код фриз, code freeze: этап, на котором в продукт и его компоненты не вносится никаких изменений. Каждая найденная проблема обсуждается, можно ли её отложить до следующего релиза или до хот-фикса. Проблемы от 4 уровня и ниже всегда переносятся на потом и пересборки из-за них быть не может. Даже если это совсем точечное изменение, даже если это кажется ерундой

• хот фикс, hot fix: сборка с устранением проблем, накопленных ранее, но сумма которых не тянет на новую полноценную версию продукта. Хот-фиксы гарантировано имеют малый потенциальный урон (impact) и дёшевы в разработке и тестировании.

Если урон большой — это уже не хот-фикс, а полноценный релиз с соответствующим выделением ресурсов и закладкой сроков. Отсюда следует, что нельзя даже простые задачи включать в HF просто потому что можем. Меньше задач – острее внимание

• критикал фикс, critical fix: сборка с устранением одной конкретной проблемы, о которой на момент выпуска релиза не было известно. Это может быть и пропуск проблемы со стороны QA, и просто новые обстоятельства, например вынужденные переезд на другие серверы.

HF тоже может быть с устранением лишь одной проблемы. Принципиальное отличие CF от HF в том, что в HF о проблеме знали и решили, что она не может задерживать релиз, тогда как в CF о проблеме раньше не знали

• мейтененс релиз, maintenance release: релиз продукта с устранением самых разных проблем, но без добавления новых фич. Планируется как полноценный релиз. Если HF жирнеет, то он превращается в MR.

MR ничем не отличается по работам от обычного релиза. Разница только в том, что в MR нет новых фич. Либо что-то есть, но это что-то было сделано только ради исправления проблем

UI/UX: отвечают за взаимодействие пользователя с продуктом. UI – это есть ли кнопка на экране, на которую можно нажать, а UX – это очевидно ли пользователю, что на кнопку можно нажать и удобно ли ему это сделать

Термины, связанные с тестированием, будут дальше.

Задачи тестировщика

Важно понять, что тестировщик лишь информирует о качестве продукта. Тестировщик не формирует это качество и, главное, не отвечает за него. Он не может быть обвинён в том, что что-то плохо работает. Но тестировщик должен приложить все силы, чтобы предоставить максимально объективную оценку качества.

Следовательно, тестировщик должен сообщать (читай – «записывать в багтрекер») обо всех, даже незначительных проблемах. Разумеется, это породит ворох задач, которые никогда не будут исправлены. Но знать о них всё равно нужно. Простое удерживание в голове знания о какой-нибудь мелочи заставляет ответственного разработчика учитывать её, когда он работает над областью, в которую эта проблема попадёт. Ответственный разработчик воспользуется возможностью устранить мелочь. Eсли это не создаёт новых проблем.

Замечание: описанное выше роляет лишь при условии, что не используется Zero bug policy. Т.к. мы решили, что нам он не подходит, то альтернативное мнение и не описываю.

Тестировщик может и должен полагаться на выработанные привычки взаимодействия с ПО и сообщать, что где-то UX сломан для текущей платформы или где-то UI «некрасивый», не смотря на субъективность. Но тестировщик должен показывать примерами, что такое хорошо. В идеале он должен давать ссылки на объяснения, почему так, а не иначе.

QA не управляет разработчиками и наоборот. Попросить что-то проверить или посмотреть что-то вне очереди можно, но это работает в малых командах (наша как раз к таким относится). И только соблюдая этикет взаимодействия: принимающая сторона должна ответить, сделает это и когда или не сделает из-за, например, сильной загруженности. Также не является чем-то плохим и напоминание об обещании. Потому что мы можем просто забыть, что пообещали что-то глянуть — так бывает.

Чтобы не было недопониманий. Тестировщик отвечает за то, на сколько хорошо (внимательно, глубоко, разносторонне) он проверяет продукт.

Приоритизация

В общем случае тестировщик присваивает заведённым дефектам только важность (severity). Однако иногда важность не отражает имиджевое влияние, влияние на «очень важного заказчика» или наоборот, не играет роли в текущей ситуации и тогда менеджер меняет приоритет. По умолчанию считаем, priority = severity. На приоритет ориентируется разработчик при планировании рабочего дня.

Информация ниже не применима к нашему текущему багтрекеру, но может быть использована на созвонах, чтобы просто говорили числами.

В общем случае значение чисел такое: – 0-2 – критично или очень серьёзно. Блокирует релиз – 0 — редкое явление, означающее, что использовать сборку нельзя. И не важно, потому что она не запускается или потому что при её использовании ломается будущая совместимость. Это просто маркер, означающий «пока не сказали, что поправили, не ставьте промежуточные сборки» – 3 – продукт может пойти в релиз, если это не привнесённая проблема. Если привнесённая, то релиз блокируется до тех пор, пока менеджер не понизит приоритет, например до 4. Допустимо делать релиз с 3 для привнесённых, если следом уже планируется хот-фикс – 4 – релиз не блокируется, вне зависимости от того, привнесено это или нет. Однако, если привнесено, то в следующей итерации нужно либо поднять приоритет до 3, чтобы исправить (или снова отложить – так бывает, хотя и ставит под сомнение реальную важность), либо опустить до 5, чтобы забить болт – 5-7 – разные уровни малозначимых проблем. 5-ки ещё могут подняться вверх во время триажа, но 6 и 7 – это просто кладбище, куда складываем то, что знаем, но чему в нашей жизни решения, скорее всего, не будет

Расчёт важности

Чтобы рассчитать важность, нужно ввести ранжирование сценариев (юз кейсов)

использование	описание
обычное	типичный сценарий работы
—-	частый сценарий работы, хоть и не на каждый день
—-	сценарий, которого придерживается сколько-нибудь заметная доля пользователей, даже если нам это кажется странным или неудобным
—-	сценарий, который может возникать не часто, но по-прежнему является И ожидаемым, И допустимым. Например, смена часовых поясов или что собеседники никогда одновременно не появляются онлайн, или собеседник никогда не использует Wi-Fi и т.п.
не обычное	сценарий маловероятный, но при этом продукту нарочно плохо не делали. Например, пользователь не будет выходить в онлайн 8 месяцев, а потом появится
—-	редко возможное состояние системы, на которой работаем. Например, очень старая, но ещё поддерживаемая версия ОС
специальное	продукт используется в стресс-режиме. Например, пытается отправить много больших файлов одновременно на плохой сети
—-	само состояние системы стрессовое. Например, осталось мало свободного места или состояние сети на грани живого и может десятки раз в минуту переключаться
абсурдное	продукт используется в сценарии, который не закладывался. Например, отправка текста «Войны и Мира» в одном сообщении
—-	система находится в состоянии, которое не закладывалось. Например, используется сильно кастомизированная ОС: от запуска на ГУ автомобиля до васянского супер кастома

«Абсурдный» не означает «бессмысленный». В основном это ситуации, которые просто не планировались, не обсуждались. Но то, что сегодня абсурдно, завтра может стать новой задачей. А может и не стать.

функциональность	использование	важность
ключевая	обычное	1
—-	не обычное	1
—-	специальное	3
—-	абсурдное	5
важная	обычное	1
—-	не обычное	3
—-	специальное	5
—-	абсурдное	7
вспомогательная	обычное	2
—-	не обычное	3
—-	специальное	5
—-	абсурдное	7
не функциональное	обычное	3
—-	не обычное	5
—-	специальное	7
—-	абсурдное	7

Следующим этапом прибавляется или вычитается уровень влияния на пользователя конкретной проблемы. Вычитание означает, что проблема повышается в серьёзности, прибавление – понижается.

тип	влияние
отказ в обслуживании (падение, зависание, повторяющийся ANR)	-1
неудобно использовать продукт и нет обходного пути	0
неудобно использовать продукт, но есть обходной путь	+1
не мешает пользователю вовсе	+2

Да, серьёзность надписи Mikrosoft прямо на главном экране продукта – это 5: не функциональная область, обычное использование, не мешает пользователю вовсе. И тут менеджер уже должен менять приоритет. Тестировщик может попросить менеджера это сделать.

Виды тестирования

Глобально:

Полное регрессионное

Оно же «фул регрес»: продукт проверяется от и до без учёта того, что в нём менялось или не менялось. Включает как функциональное, так и не функциональное тестирование. Очень дорогое (в человекочасах), потому не может проводиться постоянно. Согласовываем фул регресс на 2-3 раза в год. Чаще нет смысла из-за во-первых дороговизны, во-вторых не накапливается достаточно изменений, которые бы могли задевать разные области.

У фула две задачи: – сформулировать текущее состояние продукта и создать этим отправную точку будущих проверок. Чтобы не было «да туда 100 лет не заглядывали, может оно уже 10 релизов как не работает» – обнаружить накопившиеся проблемы, которые не были обнаружены в промежуточные проверки

Регрессионное

Обычный “регресс”. Разработчик ставит что-то в InTest и, если считает нужным, добавляет в комментариях, что ещё нужно проверить дополнительно к тому, что описано в самой задаче изначально. Вне зависимости от того, оставил разработчик свою просьбу или нет, тестировщик проверяет исправление/реализацию как того, что прописано в задаче, так и «окружающей функциональной области». Короткий интест может занять часы проверок, если задевает несколько областей разом.

При регрессионном тестировании тестировщик также делает функциональные и часто, но не всегда, не функциональные тесты. Например, если правилось падение, то тратить время на вычитку текстов не нужно.

Все промежуточные (между фул регрессами) тесты – это обычные регрессы. Потенциально, из-за того что проблемы могут появиться в местах, о которых ни тестировщик, ни разработчик не подумали, приходится несколько раз в год делать фул. Или раз в пару лет, если дела идут прям хорошо.

Финальное

Не является общепринятым термином, но его всё равно часто используют. Под финальным подразумевается достаточно поверхностный регресс после код фриза. Поверхностный он потому что проверка доработки замечаний, выявленных при регрессионном делается тоже обычным регрессионным. То есть финальное лишь отвечает на вопрос, успело ли что-то отъехать глобально. Такое бывает в сложных системах, когда для сборки, пригодный для финального теста, потеряли какой-нибудь коммит, перепутав ветки или что-то в таком роде. Как избегать эту проблему – это головная боль разработчиков, тестирование этого не решает.

Регресс будет хоть и поверхностный, но остаётся итеративным. То есть если в финальном тестировании нашлась проблема, которую решают исправить к релизу, то после исправления делается регресс этой области. А то и перезапуск всего финального тестирования, если разработчик посчитает, что фикс был не точечный.

Для финального тестирования создаётся набор тест кейсов, который называют импакт планом и в таком роде. Само формирование набора – это часть импакт анализа.

ВАЖНО 1: в ситуации «потеряли коммит», когда финальное тестирование этого не обнаружило в виду низкого его погружения, QA не несёт за это ответственности. Потому что QA не отвечает за процессы других команд.

ВАЖНО 2: и хотя фиксы после финального могут быть и их могут включить в релиз, нужно искать причины, почему эти фиксы понадобились вообще и устранять причины. Они хоть и могут быть, но это очень плохая практика. Лучше планировать сразу HF или даже MR. Ситуацию, когда финальное не находит вообще ничего, считаем маловероятной

Импакт

Чтобы проверять только то, что могло быть задето в релизе, оставив за скобками то, что точно не трогали, тестировщик собирает все сценарии, которые связаны с теми функциональными областями, которые правились в релизе. Дополнительно тестировщик спрашивает мнения разработчиков о том, что может быть задето и добавляет сценарии проверок этих областей (если вдруг оказалось, что разработчик добавил новых сведений). Это называется импакт анализ.

Далее тестировщик проверяет эти сценарии. Это называется импакт тестирование или тестирование по импакту. Но все говорят просто импакт, подразумевая как раз это.

Приёмочное

Делается для RC. Это набор тестов, включающий базовые проверки всех функциональных областей продукта в обычных сценариях использования. К нему добавляются проверки по импакту. То есть приёмочное – это тоже, что и финальное, плюс базовые проверки других компонентов.

Двойная работа требуется из-за того, что бывают ситуации, когда обфускаторы ломают то, что работало. Или разработчик использует другие версии тулкитов, отличные от тех, что на сборочном конвеере. Причины изменения поведений у RC могут быть разные и это должно устраняться не QA.

В идеальном случае финальное тестирование не проводится. Сразу после перепроверки фиксов после фриза, выкатывается RC.

В общих чертах:

• Функциональное: как работает техническая штука. Запускается ли вообще приложение, работает ли звонок, ходят ли сообщения. Здесь не учитывается UI и UX, даже если всё совсем плохо. Функциональное нужно, чтобы убедиться, нужно ли копать вообще или пока копать рано. Либо, если фича существовала раньше, проверяется, не сломалась ли она

• Не функциональное: подразумеваем UI и UX в основном. Потому что околотехнические тесты лучше выделить в свои виды. Главное, что здесь имеется в виду — проверяется, что уже работающая фича удобна, очевидна, красива. Нет никакой нужды делать нефункциональное до реализации фичи. Даже когда речь о «там просто баг, сейчас поправлю» – всё равно не нужно проверять. Потому что часто вдруг оказывается, что просто так не поправить и нужны значительные доработки или даже переделки. А значит время, затраченное на сверку с макетами было потрачено зря

• Локализационное: формально является не функциональным, т.к. тоже про UI, но выделяю отдельно, т.к. у него свой подход. Это проверка, что тексты не просто правильно написаны, а что они ещё и влезают. Отдельно оно проводится лишь когда добавляется новый перевод или было существенное изменение существующего перевода. В прочих же случаях оно полностью перекрывается не функциональным. Подводные камни локализационного:

  • длина слов в разных языках разная, а в некоторых языках слова принято сцеплять, выбрасывая пробелы. Т.к. пробелы для ОС являются триггером для переноса не влезающего слова, может получиться, что слова будут вылезать за пределы своих элементов

  • RLT. Например, арабские языки. Хотя тексты развернуть не проблема, часто стреляет то, что некоторые надписи являются картинками и про них тоже нужно помнить. Кроме того, нужно согласовывать, разворачивать ли интерфейс приложения (обычно нет)

    • вторая проблема RTL в том, что один участник может собою развернуть других. К примеру, его имя написано с управляющим символом RTL юникода. Если его имя попадает в абзац текста (или, например, в перечисление «А, Б, В печатают…»), может развернуть всех
    • стрелки «Далее» и «Назад» в мастере первоначальной настройки может развернуть, опять же

  • часто разработчики могут несколько раз вставить одно и тоже слово, скажем «Да», а потом найти, что оно уже есть и переиспользовать ранее существовавший ресурс. «Осиротевший» ресурс остаётся на месте и может получиться, что уточнили перевод сироты, а вот реально используемый потеряли

  • смежная ситуация: переиспользуется ресурс, который в одном языке означает одно и тоже, но в при переводе нужно разделить ресурс на более чем одно значение. Например удалённый: remote и deleted

  • переводы делаются, в основном, не видя реально приложения. Так что нужно проверять не только что фраза переведена, а что она переведена с учётом контекста

  • при расчёте сроков нужно держать в голове, что придётся все задетые ресурсы как-то вызывать. Это не просто «ну гляньте за полчаса». Некоторые ресурсы вообще нельзя будет вызвать со стороны тестирования без привлечения разработчиков и даже инфраструктуры

• Тестирование производительности: включает все виды проверок от просто «по ощущениям», до нагрузочных и стресс тестов. Расчёт потребляемого трафика тоже здесь. Не может быть обыденной проверкой, по типу функционального тестирования. Для перформанс тестов нужно заранее подготавливать окружение. А для этого нужно заранее понять, что хотим узнать. Для этого придётся проговаривать всё словами и, в итоге, сформулировать цели. Способы же проверки формулируются только после формулирования целей

По пониманию продукта:

• Чёрный ящик: когда ничего не понятно, и нужно разобраться, как это работает. Выпускаемый нами самими продукт НИКОГДА не может проверяться как чёрный ящик. Каждый тестировщик должен разобраться в каждой фиче продукта и понимать, как именно это должно работать и как оно работает на самом деле. Если тестировщик не желает разбираться, тестировщик не должен работать в команде

• Белый ящик: когда тестировщик понимает, что к чему. В пределе, но не обязательно — читает и понимает исходный код. В целом достаточно того, что тестировщик представляет механизмы работы ОС и продукта. Это помогает предполагать опасные/сложные места и начинать проверку с них. Как правило, в простых местах разработчик не ошибается, а опасные как раз может не учесть. Как итог – ошибки находятся сразу же

Задача лида – сделать продукт понятным тестировщику. Задача тестировщика – приложить усилия, чтобы разобраться в продукте и в его взаимодействии с ОС.

Задачи

Жизненный цикл задачи

Вне зависимости от типа задачи – задача, пожелание, баг – она проходит один и тот же жизненный цикл.

• завели в баг трекере. Заводить может, понятно, не только тестировщик, а любой участник команды. При описании нужно помнить, что проверять может кто угодно. Нужно хоть как-то описать задачу, чтобы понять, о чём идёт речь и через год

• принятие решения о реализации. Вполне может быть, что задачу нельзя, невозможно, нет смысла и т.п. реализовывать и ответственное лицо (в основном разработчик, если речь про баги) может отклонить задачу или запросить больше информации. Нужно написать, почему именно отклонено или какую информацию нужно добавить и выставить в InTest. Разработчик не может закрыть баг, даже если не согласен. Его инструмент – отклонение с объяснением

• реализация, если принято решение о реализации

• отправка на проверку. По умолчанию все проверки делает QA, вне зависимости от того, кто задачу создал. Так что разработчик ставит InTest и отправляет на тестировщика

• проверка. Тестировщик, если может, проверяет реализацию. Если автор не он, то он общается с автором (если возможно) и всё равно проверяет сам. Если задача была очень специфична и явно не для QA, то тестировщик вешает её на заказчика со своим комментарием, почему это сделано.

Интеграция новых методов из натива или переход с устаревших на их замену и подобные штуки от разработки не являются “слишком специфичными”, они всё равно в ответственности тестировщика. В этом случае тестировщик делает регресс по фиче, даже если визуально ничего не изменилось.

Просьбы

Нормальным и даже рекомендуемым поведением является оформление просьбы что-то проверить в виде задачи. Чаще всего просят тестировщика что-то сделать. На созвоне или в переписке о чём-то просишь и, если тестировщик говорит, что да, может это сделать, то завести ему соответствующую задачу и поставить в InTest.

Благодаря такой формализации тестировщик и вряд ли забудет о задаче, так ещё сформулирует ответ в ней же. А значит все смогут этот ответ прочесть. К тому же всегда можно будет вернуться к задаче и вспомнить детали.

Просьбы оформлять в виде задач в багтрекере – это хорошо и правильно.

Триаж

Задачи в баг трекере будут накапливаться. Некоторые будут решены, некоторые решены не будут. Раз-два в год, чаще нет смысла, нужно проводить триаж. То есть проверять, актуальны ли ещё задачи и нужно ли что-то поднять из подвала наружу.

Этап 1. Тестировщики проверяют все открытые задачи.

Те из них, которые более не актуальны, закрываются.

Те, которые актуальны, обновляются с указанием, на какой версии проверено.

Те, которые актуальны, но чуть изменилось воспроизведение (например с тех пор изменился экран или экран переехал и теперь надо иначе его вызывать), обновляются под новую реальность.

Если удалось найти ещё способы получить эту же проблему, кроме той, что записано, это также добавляется.

Если новое поведение проблемы таково, что её важность повышается, она добавляется в список проблем, на которые нужно обратить внимание.

Этап 2. Лиды и PM рассматривают сначала список проблем. на которые нужно обратить внимание, даже если тег Triaged установлен. Если окажется, что проблема действительно стала более важной, тег снимается. Задача рассматривается как новая. Имеется в виду, что, возможно, нужно будет ещё и приоритет переопределить

Далее просматривается список оставшихся в живых проблем без тега Triaged и принимаетя решение, что с ними делать.

Если проблема такая, что точно никогда ничего делать с этим не будем, на неё ставится тег Triaged. Таким образом тестировщики её будут актуализировать каждый год, но на второй этап она никогда не попадёт (если у неё не изменилось поведение и она не попала в список “обратите внимание”).

Если проблема такая, что её бы хорошо поправить, она добавляется в скоуп релиза. Релиз не обязательно ближайший. Это может быть отдельный релиз, MR, к примеру.

Философия

В этом разделе попытаюсь ответить на вопросы, которые возникают в головах и иногда проговариваются вслух.

Почему тестировщик находит проблемы в ранее проверенном

К примеру, почему в финальном тестировании находятся новые проблемы, хотя именно эти области и так проверялись раньше. Может возникнуть желание обвинить тестировщика в невнимательности.

В самом простом случае тестировщик просто правда плохо работает. С такими нам не по пути. Но хороший тестировщик тоже допускает такие косяки. Основные причины:

• ранее устранённые проблемы освобождают время проверок. Скажем, из-за некой баги пришлось потратить 3 часа на её воспроизведение, на анализ. Эту проблему устранили и теперь как бы появилось «лишних» 3 часа в обычном рабочем дне, которые тестировщик непременно инвестирует сюда же – в проверки.

Может звучать не правдоподобно, но это действительно самая популярная причина. Собственно, почти все обнаруженные на поздних этапах проблемы – это «лишнее» время. В том числе потому HF и MR существуют и потому они планируются заранее, ещё до самого основного релиза.

• область была затронута после проверок. И хорошо, когда тестировщик или разработчик это понимают и перепроверяют, но так ведь не всегда бывает. К тому же проблема может быть такой, что в простом сценарии она не ловится и без честного регресса её не поймать

• устранение ошибки приводит к раскрытию другой. Не редка ситуация, когда одна ошибка маскирует другую

• люди устают. Могло быть так, что в прошлый раз тестировщик был уставшим и с рассеянным вниманием. Отличие от тех, с кем нам не по пути в том, что хороший тестировщик может иногда уставать и каждый раз это прям новость. “Ничего себе, как так?!”

• тестировщик потерял интерес. Это происходит со всеми. Когда проверяешь одно и тоже из раза в раз, пропадает чувство новизны. Нам надоедают новые компы и машины, чего уже говорить о просто программах

Личное замечание. Оно наверняка считается сексистским и каждый с ним вправе не согласиться. Девушки теряют интерес сильно позже, чем парни. Они лучше выполняют одни и те же работы и сильно дольше остаются внимательными к деталям. Что, разумеется, не означает, что им не нужно давать новое.

• замыленный взгляд. Когда тысячу раз видел одно и тоже поведение, оно становится привычным. А вот пользователь может не согласиться. Когда тысячу раз делал одни и те же проверки, другие сценарии перестают приходить в голову, потому что другое применение уже даже не ожидаешь

• слишком хорошее знание продукта. Когда тестировщик слишком хорошо изучит продукт, он начинает предсказывать его поведение. Это очень помогает в обнаружении проблем новых фич, но мешает в обнаружении проблем в достаточно привычных сценариях. «Ну да, падение, если поворачивать телефон во время удаления контактов, ну а чего вы ждали, особенности работы». Только пользователи ждали не понимания причин, а чтобы просто не падало

• отрыв от своих пользователей. Не редко бывает, что пользователи используют продукт таким образом, каким тестировщик не использовал никогда и не догадывался, что кто-то так делает

Почему не проверили вот это, это же было быстро

Каждую отдельную ситуацию проверить быстро. Но секунды создают минуты, затем часы и дни. Отдельных сценариев прям много, прям сотни. А когда релиз делается ради фичи X, то фичу Y будут проверять сильно реже и вообще потом. Если нужно вклиниться в список задач тестировщика, лучше всего просто попросить об этом. А когда просишь – нужно убедиться, что просьба услышана.

Повторюсь снова: не грех и напоминать о просьбе. У тестировщика тоже есть работа и жизнь и он может просто забыть об обещании. Напоминание его не оскорбит, зато поможет проекту

Ну и лучше всего прочитать раздел Просьбы и сделать так, как там написано