Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

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

В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.

И да, отмечу, фраза «каждый легко найдёт оправдания и объяснит, почему налажал не он» не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.

Я как аналитик сделал всё возможное: проанализировал ожидания и возможности, проконсультировался с инженерами. Несколько раз скорректировал требования по мере проявления нюансов.

Я как разработчик реализовал требования в архитектуре и коде насколько позволили уже существующие архитектура и код, а также время и личная смелость.

Я как тестировщик, проверил фичу, пришёл в ужас, зарепортил баги, бился за них, но треть багов умерли вонтфиксами. Часть потом переоткроется, как показывает опыт, но это потом. Ответственные лица решили, что баги не фатальные. С формальной точки зрения блокирующих проблем нет, тестирование — done.

Я как… Ой, а всё, никого ж не осталось. Релиз.

Я как руководитель RnD недоволен, что мне на совете директоров рассказывают про баги в продукте. Каждый из инженеров видел проблему, и никто её не починил (а то и не заметил).

В этой войне авторитетов «рядовой тестировщик» равно как и «рядовой разработчик» с формальной точки зрения не всегда может показать что продукт — ну не готов к использованию. Есть те, кто более равны и есть формальные требования.

Поэтому важно привнести тот самый фактор субъективности в финальную оценку качества. Чтоб учитывался не только формальный критерий, но и общее впечатление от продукта. Тогда есть шанс перейти от «тут довольно много багов, но сплошь мажорчики, можно релизить» к «да, каждый баг формально мажор, но вместе они делают работу с продуктом невозможной».

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

Полагаю, привносить эту субъективность можно по-разному, и разным командам/компаниям подойдут разные способы. Я лично знаком с системой Quality rating’ов, и сам видел, как она помогала. Если тестировщик поставил фиче оценку 2 из 5, вероятно с фичей что-то не так. Возможны и другие способы, но «техническая» реализация не суть важна. Важно дополнить формальные показатели живым ощущением сотрудника — тогда чуть больше шансов узнать реальное состояние продукта.

Всяко это лучше и полезней, чем пытаться понять, что таск-трекер может сказать о качестве продукта (QA квартирник Codefest’а, привет). Таки таск-трекер для задач, а качество для людей. Давайте у людей и спрашивать о качестве.

Сказка о неразобранных автотестах

Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты («Selenium» — подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех «зелёными» результатами. «Красные» результаты быстро исследовали, чинили проблему, и каждый следующий запуск был «зеленее» предыдущего. Скоро сказка сказывается, да не скоро дело делается.

У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk’ов зашла речь про автотесты, и выяснилось, что «в реальном мире это не работает». Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема — разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста — вот это всё. Не хотят люди результаты разбирать — неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет «заставить» слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?

Сразу хочется задать кучу уточняющих вопросов, что же именно не работает и почему не работает и какой мир считается реальным и т.п., но не могу: не коллегу же спрашивать про чужие проблемы (слышал я эти Битлз — мне друг по телефону напел). Но понятно, что если на результаты автотестов не смотреть, то можно тогда автотесты и не использовать вообще. С точки зрения бездушной математики это то же самое.

С другой стороны, если сесть и вспомнить, то — ну да, всё так. Разбирать автотесты — это не вдохновляет. Как возникает эта задача, так сразу хочется чем-то другим заняться. На такой случай всегда найдётся Важное Дело, Которое Надо Сделать. То есть проблема не совсем выдуманная, и как-то же её решают те, кто живёт в нереальном мире.

Итак, возможные решения, только здесь и сейчас, спешить узнать.

Возможны противопоказания, проконсультируйтесь со своей командой.

От результата

Нам ведь не нужны результаты автотестов. Нам нужно квалифицированное и обоснованное знание о состоянии продукта. Не хочешь возиться с автотестами, можешь не возиться. Главное — это самое знание предоставь. Как — дело десятое. Можешь «руками» всё пройти, можешь еще как-то. Лишь бы работало, было воспроизводимо и в разумные сроки. В общем, ты сам кузнец своей задачи.

От процесса

Ты за автотесты, но ведь нудятина же невозможная? Да, всё так, согласен. Но уйти от рутины совсем — не получалось никогда и ни у кого. Кроме Карлсона, но супергерои не в счёт. Рутина есть и будет, на каждом сколько-нибудь долгом проекте; это надо принять как неизбежность. Но можно варьировать количество рутины на каждую персональную душу населения.

Простой вариант: ротировать ответственность. Две недели я отвечаю за разбор автотестов, две недели ты, потом отдадим третьему. Всё честно, все страдают по очереди. Но отлынивать в свою очередь — нельзя, результат должен быть готов в срок.

Другой вариант — поделить весь большой сет автотестов на куски. Самые приоритетные выделить в отдельный пул и сперва выполнять только их, а остальные — пореже и только если Top-Priority тесты «зеленые» (вы слышали, он сказал «build verification test», он правда это сказал). Этих самых Top-Pri тестов не должно много получаться. Если какой-то из Top-Pri тестов, будучи «красным», не блочит 10% общей массы тестов, то может он и не Top-Pri.

Вообще, вариантов подобного перераспределения рутины можно придумать немало — лишь бы помогали работе.

Издержки: как за всяким процессом, кто-то должен за ним следить: что он работает, не провисает, не начинает мешать ходу проекта и так далее.

От инструмента

А может, всё проще и достаточно допилить инструменты, чтоб они помогали разбору результатов АТ (о, вот она, Важная Задача, которой я буду отмазываться в следующий раз).

Как эти результаты выглядят? Легко ли отфильтровать из общей массы только «красные» тесты? Легко ли понять, что делал каждый «красный» тест и в каком месте свалился? Можно ли сгруппировать тесты, упавшие с похожими причинами? Можно ли указать для каждого теста соответствующий баг в трекере? Можно ли подтянуть для «красного» теста баг с прошлого запуска? Может ли разобраться в логике теста человек, не знакомый с внутренним устройством автотестов, — просто глядя на результаты выполнения?

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

От проблем

Да нет, говоришь, это всё понятно, говоришь, но что толку, если половина падений тестов — это не баги продукта?

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

Ну что тут скажешь. Время исправлять грехи молодости: стабилизировать АТ, разбираться с настройками, учить роботов…

Или — придумать как получать всё-таки пользу от таких АТ.

От себя

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

Специфику продукта никто не отменял, но вдруг есть способ лучше, чем просто страдать — то от того, что разбираешь автотесты, то от того, что автотесты не разобраны.

 

Сказка ложь, да.

Ну что, как там продукт, готов?

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

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

 

Quality Rating как идентификация готовности продукта к релизу

Всего лишь пара изменений

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

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?

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

Другой вопрос — как такая ситуация могла возникнуть. Есть варианты, да. Возможно, потихоньку идет процесс улучшения GUI и юзабилити продукта. Или — прилетел баг от клиента, и его починили в продукте, а тестировщик этого бага и не видел пока. Или — над продуктом работают несколько команд разработчиков и тестировщиков, каждая в своей песочнице, и время от времени их наработки добавляются в новые билды. Много чего возможно.

И вопрос — как эти изменения контролировать?

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

Сообщать об изменениях

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

Что именно сообщать — тоже во многом вопрос контекста, но в любом случае стоит упомянуть, в чем суть изменения, на каком основании оно сделано, с какого момента оно вступает в силу.

В принципе, так можно сообщать не только о неожидаемых изменениях, но и о готовности [части] фичи к тестированию. Понятно же, что не всякое изменение — фича, но всякая фича — изменение.

Ок, нам сообщили, можно жить и радоваться. Тестировщику — наверное, да, можно. А его начальнику, возможно, пора задуматься, как

Сохранять историю тестирования изменений

Мы же тестировщики; если что-то изменилось — наша работа проверить, что все продолжает работать как нужно.  А по итогам тестирования мы должны ответить — что было протестировано в контексте данного изменения, когда (в каких билдах), с каким результатом.

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

Впрочем, история — это хорошо и полезно, но иногда стоит еще и

Планировать тестирование изменений

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

Тут, правда, нужно как-то узнать, что планируется N изменений в данной части продукта, а это не всегда возможно. Про фичи-то мы знаем, конечно, а вот с мелкими изменениями и фичами других команд дела обстоят посложнее.

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

 

Контролировать изменения или нет, и как тщательно, — дело каждого отдельного проекта. Лишь бы изменения не засыпали проект с головой.

Удачи вам, внятных требований и контролируемых изменений.