Отдельная история - метрики и критерии, которые хочется свести к нулю.
Например, количество багов на проде и знаменитая Zero Bug Policy, которая говорит: Мы стремимся к тому, что бы количество багов найденных в проде равнялось 0.  
Это абсолютно понятное и интуитивное решение. При этом я искренне убежден, что оно приносит значительно больше вреда, чем пользы. Каждый, кто работал в QA или читал хотя бы одну книжку по тестированию понимает, что невозможно выпустить продукт без багов. Zero Bug Policy задает абсолютно правильный вектор движения, но вместе с тем ставит недостижимый ожидаемый результат. Если в вашем продукте количество найденных в продакшене багов равно нулю - значит вы просто о них не знаете.
Что бы я предложил вместо этого?
Отслеживать количество таких багов в динамике. Если оно увеличивается - анализировать и искать причины. Если хочется его уменьшить - заводить задачу на исследование того, какие изменения в процессах и наборе тестов могут помочь уменьшить количество таких багов на N.

Прозрачность качества.

В предыдущих постах я говорил о том, как и из каких источников можно собирать информацию о состоянии качества продукта.
Но не менее важная часть процесса QA - донести эту информацию всем, кому она может понадобиться.
Я убежден, что любая информация касающаяся качества продукта должна быть максимально публичной в рамках компании.
Более того, помимо публичности она должна быть ещё и прозрачной. Сделать её прозрачной для всех - тот ещё челлендж, потому что важность и приоритетность тех или иных данных сильно меняется в зависимости от задач того, кто эти данные будет получать.

Для разработчиков критически важно видеть максимально детализированные репорты - какие тесты и на каких шагах упали, какие тестовые данные использовались, к какой ошибке это привело и т.д.
Для Dev\IT Ops - все данные, касающиеся изменения окружений, производительности, стабильности, ресурсоэффективности, сетевой нагрузки и прочее.
Саппорт и Customer Success захочет увидеть в репортах все про имеющиеся проблемы и изменения в UX, что бы выстраивать правильную коммуникацию с пользователем.
Простой список фичей и ссылка на джиру не помогут, а вот лакончиные релиз-ноутс, вместе с понятными и простыми инструкциями сэкономят кучу времени.
Для бизнеса важно видеть общую картину и иметь возможность быстро получить информацию о состоянии продуктовых и пользовательских сценариев, возможные риски и проблемы.
Здесь важнее показать работу ключевых продуктовых сценариев и всё, что затрагивает воронку конверсии. Выгрузка релизных багов из джиры вряд ли скажет хоть о чём-то, а отчёт от тестировании на десяток страниц никто так и не прочтет целиком.
Всё это рождает большое разнообразение репортов, дашбордов и вариаций визуализации показателей качества, создание и поддержка которых требует времени и ресурсов.

По моему опыту, команды которые игнорируют этот аспект работы встречаются довольно часто.
Аллюр репорты, выгрузки из xUnit тестранов, отчеты о прохождении тестов в QMS, миллион дашбордов, которые умеют читать только их авторы, километровые отчеты о тестировании и паспорта качества.
Всё это - типовые решение, которые содержат в себе всё и ничего одновременно, потому что призваны "отчитаться о работе", а не дать людям полезную информацию.

Что же делать?
Начните работать с информацией о качестве как с продуктом.
Узнайте, кому и какие данные нужны, как эти данные будут использовать и в каком виде их удобнее всего получать.
Выбирайте правильную форму подачи информации - для каких-то данных это могут быть графики и дашборды, где-то понадобятся майндмэпы и прочие средства визуализации, а где-то хватит и чеклиста.
Пишите репорты так, как сами хотели бы получать важную для вас информацию - просто, лаконично и по делу. Без воды, канцелярита и создания иллюзии бурной деятельности.  
Собирайте и анализируйте то, как вашими репортами пользуются. Убедитесь, что репорты отвечают на те вопросы, которые есть у читателя.
Если же ваши репорты никто не читает - возможно они перегружены информацией, сложно читаемы или... просто избыточны и от них можно запросто отказаться.
Делайте информацию открытой и доступной, даже если это заметки с ретроспективы или результаты постмортема по пропущенному в продакшен багу.
Любой аппрув фичи или выпуск релиза должен сопровождаться полным, простым и понятным описанием того, что было проверено, какие проблемы были найдены и как изменения отразились на продукте.
Так все, для кого это важно смогут понять как работает QA процесс, как принимаются решения и что может пойти не так.

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

Хороший повод подумать как бы вы решали такую задачу, какие виды тестов, приоритеты, корнер-кейсы и проблемы вы видите и о том, как глубоко "под капот" простирается работа QA.
Все желающие поделиться своими соображениями — буду рад почитать и обсудить ваши идеи, стучитесь в личку.
Ну, и чуть позже поделюсь со всеми результатами этих дискуссий, а заодно и своим опытом и мнением на этот счёт.

Иногда приходится принимать субъективные решения.

Я довольно часто агитирую за то, что решения необходимо принимать на основе данных. Аргументов, метрик, цифр и прочего.
Что если вы делаете какую-либо работу без описанного и измеримого ожидаемого результата - вы, скорее всего, делаете её зря.
Просто потому, что доказать или увидеть обратное вы не сможете.
Увеличили количество тестов? Здорово. А зачем? Какой профит от этого получила команда и компания?
Внедрили генетические алгоритмы для генерации тест-кейсов? Прекрасно, будет что рассказать на конфе. Но все же, а что нам это дало?
Запилили целый спринт классных новых фичей, молодцы! А вы уверены, что они принесут пользу продукту?
Ну и далее по списку.
Я искренне убежден, что это действительно так работает.

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

И тут приходится поддерживать баланс.
С одной стороны - принимая решение на основе субъективных факторов ты значительно повышаешь риски.
Ты можешь просто потратить зря время, или ещё долго расплачиваться поддерживая нерациональное решение.
Или просто получишь команду ребят, которые пилят классные штуки, но не очень понятно зачем.
С другой стороны - игнорируя субъективные факторы ты, скорее всего, убьешь мотивацию (свою или команды) к работе.
Человек, который хотел попробовать новые технологии, но ему не дали - уйдет в другую компанию.
Ребята, которым "просто неудобно, хз как объяснить" пользоваться выбранным идеальным инструментом - просто будут стараться всячески его избегать и саботировать (даже если и не сознательно).
А ты будешь сидеть во всём этом пожаре и думать как это починить.

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

Ещё немного изменений для безумного 2020.
Запустил очередную итерацию переезда в Москву.
Впереди - новые проекты, новые задачи и, кажется, масса всего интересного.

Вопрос: У меня есть команда из нескольких тестировщиков, как мне поделить проект, что бы каждый тестировал свою часть системы?

Ответ: Поделить проект можно, на самом деле, миллионом разных способов.
Это просто определенный объем работы и N возможных исполнителей.

Можно, например, поделить тестировщиков между командами разработки, распределить между сервисами, компонентами или кусками системы.
Разделить работу по доменным областям – кому-то веб, кому-то бэк, кому-то мобилы.
Можно разделять задачи исходя из скиллов и результатов исполнителей.
Кто-то хорошо тестит UI и пиксельпёрфект, кто-то быстро и качественно тестирует апишечки, а кто-то просто бог тестирования методом свободного поиска.
Можно вообще round robin алгоритмом автоматически назначать задачки с доски.

Всё, на самом деле, зависит от ответа на вопрос "Чего именно вы хотите добиться, распределяя эти задачи?"
Если вы просто работаете таск-менеджером и ходите убедиться, что все задачи распределены и никто не делает дважды одну работу – то принцип распределения не важен, хватит канбан доски.
Если задача в том, что бы все понимали к кому из тестировщиков идти с определенного рода проблемами, то распределение по командам или компонентам системы кажется более логичным.
Если вы хотите получить максимальный выхлоп от работы, то распределение исходя из скиллов может быть лучшим выбором.

Важно помнить и о последствиях этого выбора.

Так, распределение ответственности по командам\продуктам\сервисам приводит к тому, что каждый инженер фокусируется только на "своём" кусочке.
В итоге общую картину не видит никто, каждый пилит свой сервис, а не итоговый продукт.

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

Нужно понимать, что любое явное распределение усложняет балансирование нагрузки в команде, потому что нагрузка на QA не статична и её пики могут приходиться на разные участки системы от релиза к релизу.  
Получаем банальное "я свою часть работы сделал, можно и котиков в интернете посмотреть", а на другом QA в этот момент очередь из 15 задач, которые блочат выпуск релиза.

Ну и, конечно же, не забывайте про bus factor.

В ближайшие дни будет пост по мотивам холивара "Что значит тестировать UX и должен ли этим заниматься QA?".

А пока, ещё немного про то, что нужно знать QA инженеру.
Многие из вас знают такой популярный баззворд "T-Shaped".
Это про то, что помимо глубокой экспертизы в основной доменной области, у человека есть базовое понимание смежных областей.

Так вот, хороший QA-инженер должен быть Щ-shaped.

Про тестирование UX и то, должен ли им заниматься QA инженер.

Говорить о качестве UX довольно сложно.
Прежде всего потому, что UX - это история, в которой смешивается всё: ожидания и привычки пользователей, хотелки и представления о прекрасном у дизайнеров и продакт оунеров, гайдлайны платформы, тренды дизайна интерфейсов, технические ограничения и особенности реализации продукта.
Зачастую нельзя чётко сказать “здесь плохой UX”, “здесь хороший UX”.
Его, этого самого UX, качество выражается только в метриках - конверсии, вовлеченности, ретеншене, количестве обращений в саппорт и т.д.
Тестирование UX - гораздо больше про фокус группы, аб-тесты и тестирование гипотез, чем про тест-кейсы и бинарные проверки.
В результате, тестирование UX почти полностью переходит в ответственность тех, кто занимается проверкой этих гипотез - настраивает а/б-тесты, собирает фокус группы, мониторит пользовательскую аналитику и продуктовые метрики.
Где-то этим занимаются аналитики, где-то менеджеры продукта, где-то дизайнеры, где-то отдельные команды UX-дизайнеров\исследователей.

Значит ли это, что QA инженеров это не касается?
В целом, нет.
Как и во множестве других случаев, задача QA здесь - предоставить дополнительную экспертизу и информацию ребятам, отвечающим за UX.
Дать фидбэк, задать вопросы, посоветовать или предложить что-то относительно гипотез, которые выдвигаются, их реализации и результатов проверки.
Вы можете указать на кейс, который они упустили, на конфликт с другими АБ-тестами или событиями, указать на неконсистентность или противоречие стандартам и гайдлайнам платформы, предложить другой вариант реализации и т.д.

Помните, что тестирование UX - это дорого.
Организация фокус групп требует серьезной работы, большого количество времени и денег.
А\Б тесты требуют времени на составление, поддержку и анализ результатов (и повышают сложность системы).
Поэтому, чем раньше вы придете с фидбэком или идеями к коллегам - тем лучше.
Главное, что бы этот фидбэк был полезным.
И, в целом, чем больше у вас экспертизы в UX - тем больше шансов давать действительно полезный фидбэк.

Откуда брать экспертизу?

Учитесь.
Есть миллионы видео и куча интересных книжек про UX, дизайн и поведение пользователей.
Например, можно начать с классической Dont Make Me Think и книжки Эдварда Сталла про UX.

Изучайте гайдлайны платформ, стандарты отрасли и требования.
В некоторых случаях это просто набор рекомендаций, в других - это обязательные стандарты и требования сертификации.
Довольно часто они содержат в себе довольно серьёзные требования к UX и интерфейсам.
Например, почитайте Apple HIG, если вы делаете приложение под iOS или ISO-13485 если ваш продукт - медицинское изделие.

Повышайте насмотренность интерфейсов.
Смотрите на конкурентов и просто популярные приложения, читайте и смотрите рассказы от ребят, следите за тем, что происходит в отрасли.
Это помогает понять, как другие команды решают типовые проблемы, какие есть варианты и на что стоит ориентироваться.

Смотрите на фидбэк пользователей.
Но не забывайте, что хороший фидбэк приходит реже, чем плохой.

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

На правах рекламы и интересного чтива для пятничного вечера.
Прекрасная ссылка в канале не менее прекрасного CTO.

https://t.me/chernov_sharit/111

Не пытайтесь сделать всё сразу, быстро и хорошо.

Я довольно много писал об этом, но на собственном опыте убеждаюсь, что иногда сложно следовать этому, казалось бы очевидному, совету.

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

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

Здесь всплывает первое правило - декомпозировать задачи и делать по одной за раз.
Внутренний перфекционист сразу набрасывает красоты: щас, значит, быстренько накидаем пейдж обжекты, настройки браузеров и параллельного исполнения, результаты - в аллюр какой-нибудь, ну и триггер в CI на каждый билд\деплой\пр\коммит.
Пока ты пишешь тесты - приходит ещё несколько идей, а потом надо тестовые данные ещё подготовить, при сборке в CI постоянно что-то падает, для репортов надо что-то поправить в pytest.
И в итоге задача начинает разрастаться с неистовой силой, живёт где-то в ветке и не приносит пользы даже тебе, не говоря уж о других членах команды.
Во многом потому, что эту задачу надо было изначально распилить на десять разных задач и делать их по-очереди.

Второе правило - начинай с максимально простого решения.
Каждый тест, который я пишу, начинается с простого последовательного скрипта.
Без объектов, с захардкоженными локаторами и time.sleep(n) внутри.
При этом довольно часто в проекте уже есть и пэйдж обджекты, которые частично можно переиспользовать, и умные ожидания, и вспомогательные функции.
И да, когда я удостоверюсь, что это именно та последовательность действий, которая нужна мне в тесте - я вынесу локаторы, вычищу код, уберу дублирование и добавлю нужные функции в utils или пейдж обжекты.
Но попытки делать это сразу приводят к тому что ты или подстраиваешь логику теста под уже имеющийся код, или, что ещё хуже, перекраиваешь уже работающий код для теста, который ещё десять раз поменяется перед тем, как попасть в мастер.

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

Ну и на последок, небольшой пример:
На этих выходных я сел и решил сделать для команды слакбота, который запускал бы тесты.
Просто потому, что CircleCI по какой-то причине отказался от кнопки "Запустить джобу" в своём UI.
В рабочем таск-трекере я просто завёл себе фичу на это, а в личном Notion эта задача, на самом деле, разбита на 14 подзадач.
Примерно 5 из них я выпущу в релиз завтра, как MVP.

Это будет предельно простая штука, покрывающая основные кейсы с минимумом интерактивности.
Остальные задачи, с дополнительными кейсами, красотой и юзабилити, будут доезжать до продакшена, наверное, еще неделю или полторы.
Просто потому, что даже MVP версия полезнее, чем никакой.

Ещё один прекрасный лонгрид, ссылку на который я честно украл из канала Вани Чернова.  
Почти детективная история от людей, все ещё вынужденных поддерживать второй пайтон.
Это одновременно и хороший пример того, как тесты иногда выстреливают в неожиданных местах.
И напоминание, что не всегда достаточно просто убедиться, что используемый инструмент работает.
Хорошо бы ещё понимать как именно он работает.

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

Тема менторства довольно часто обсуждается в QA сообществах.

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

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

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

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

И так, друзья.
Пришло время сделать небольшое овервью по поводу итогов опроса.  

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