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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От процесса

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

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

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

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

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

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

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

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

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

От проблем

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

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

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

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

От себя

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

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

 

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

Связанные многочисленными ниточками

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

Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.

Стоит потратить пять минут на чтение. Начали.

Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

1 Введение
В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.
Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.


2 Структура команды
Разработка продукта в salesforce.com состоит из трех подразделений: Applications, Platform и Core Infrastructure. Эти три подразделения суммарно содержат более 30 Scrum-команд. В каждой Scrum-команде есть разработчики, тестировщики и Product Owner, а также Scrum Master (обычно это руководитель разработчиков или тестировщиков либо Program Manager). Для сложных фич Scrum-команды также привлекают представителей других функциональных команд, например System Testing, Documentation, UI Design, Usability, Technology Operations, Release Engineering.
Обычно все Scrum-команды работают над одним и тем же релизом в одной и той же ветке кода. Наши продукты связаны между собой, поэтому фичи разных команд могут очень тесно переплетаться — как функционально, так и технически. С точки зрения технической реализации многие команды используют общий код. С точки зрения функциональности команды, работающие над фичами для одного и того же конечного пользователя, должны тесно сотрудничать, чтоб создать гармоничный и согласованный user experience.

3 Почему управлять зависимостями трудно?
Когда столько команд работают над одним релизом, внедряя общие фичи и меняя общий код, невозможно предвидеть все проблемы, неожиданности, изменения, провалы и успехи, которые встретятся в процессе разработки. Такая непредсказуемость — одна из причин, почему управлять зависимостями так трудно. Далее в этом разделе мы отметим еще несколько причин. Любые решения должны быть направлены на эти основополагающие конфликты и вызовы.

3.1 Сложность системы
Выявление зависимостей — первый шаг к управлению ими. Подобно многим зрелым продуктам, системы salesforce.com слишком сложны, чтобы один человек или команда были способны знать и помнить все взаимосвязи. Чтобы выявить и осознать зависимости, нам все чаще приходится полагаться на коллективные знания множества людей. Крайне важно объединять такие знания и связывать людей, обладающих информацией, с людьми, нуждающимися в ней. Ключевую роль в определении зависимостей и последствий предлагаемых изменений играют эксперты с широким пониманием системы. Однако по мере роста и усложнения системы трудно избежать специализации и дробления знаний. К тому же при текущем количестве изменений нецелесообразно просить экспертов проверять детали каждой новой фичи. Нужен способ выявлять изменения, с высокой вероятностью влияющие на (или зависящие от) работу других команд, чтобы уделить таким изменениям особое внимание. Конечно, сделать это не так просто, поскольку порой сравнительно небольшие изменения серьёзно влияют на всю систему.

3.2 Конфликт приоритетов
Зависимости могут приводить к конфликтам между командами. Если одна команда хочет, чтоб другая команда что-то сделала, то Product Owner’ы этих команд обсуждают и определяют приоритет этой работы. Если по итогам обсуждения удается договориться о сроках выполнения, то в дальнейшем управлять этой зависимостью довольно просто. Если внятное соглашение не достигнуто, или если приоритет работы все еще низок, то неопределённость и уровень рисков вокруг данной зависимости возрастают.
Также конфликты возникают, когда одна команда вносит изменение, добавляющее работу другой команде. Например, когда одна команда изменяет архитектуру, так что остальным надо приспособиться к этим изменениям. Изменение не всегда приносит очевидную пользу другим командам, так что иногда люди обижаются и возмущаются появлением дополнительной работы, особенно когда она появляется внезапно. Мы стараемся выявлять такие зависимости на ранних этапах, но некоторые из них неизбежно появляются позже — вследствие уже внесенных изменений либо после пересмотра приоритетов.

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

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

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

  • Сделать общеизвестным — планы на релиз, взаимосвязи, проекты, статус билдов, и т.д.;
  • Организовать площадки для обсуждений и обмена знаниями между командами;
  • Поощрять самоорганизацию и децентрализованное управление взаимосвязями;
  • Автоматизация, автоматизация и еще раз автоматизация.

4.1 Старт релиза
Примерно за месяц до выпуска текущего мажорного релиза мы устраиваем стартовое собрание для следующего релиза. На собрании присутствуют все сотрудники компании. Вице-президенты бизнес-подразделений рассказывают в общих чертах, над какими фичами планирует работать каждая команда в новом релизе. Это собрание заметно помогает управлять взаимосвязями. Прежде всего, оно побуждает команды подготовить их начальные планы на релиз к намеченной дате. Если у какой-то команды остается незавершенная работа из текущего релиза, то эта команда начинает задерживать планирование следующего релиза; в этом случае собрание помогает выполнить планирование к сроку. Трудно выявлять зависимости и обсуждать обязательства с командой, которая понятия не имеет, что она будет делать. Стартовое собрание служит точкой синхронизации команд и помогает обеспечить продуктивное обсуждение межкомандных взаимосвязей.
Кроме того, после собрания планы команды на релиз становятся общеизвестными. Мы стремимся добиться высокой осведомленности о том, чем занимаются все команды, поскольку верим, что это заставляет людей обдумывать и обсуждать взаимосвязи. В стартовом собрании участвуют все руководители R&D, что помогает привлечь людей и сосредоточить внимание на планировании релиза. Высокий уровень участия помогает согласовать ожидания и информировать правление о планах на релиз.
Конечно, планы могу меняться и меняются в процессе работы. Не так давно мы начали проводить обзор обновленной презентации стартового собрания во время ежемесячных обзоров спринтов. Обновленная презентация показывает, какие фичи были исключены или добавлены, и очень помогает поддерживать ясность и публичность планов в течение релиза.

4.2 Сессия выявления взаимосвязей
Приготовив начальные планы на релиз, команды могут более предметно обсуждать взаимосвязи, и множество таких обсуждений возникает спонтанно. В дополнение к этому мы сочли весьма ценным проведение более формальной сессии выявления взаимосвязей, когда совместно работают представители всех команд. Полезней всего проводить такую сессию незадолго до стартового собрания релиза, чтобы повысить качество планов, анонсируемых на этом собрании.
Сессия выявления взаимосвязей устроена довольно просто. Представители (чаще всего Scrum Master или Product Owner) всех Scrum-команд собираются в комнате с большой доской. В первой части сессии все участники одновременно рисуют на доске две диаграммы зависимостей между командами. Одна диаграмма изображает команды, которым нужно, чтоб другая команда сделала что-то для них. Вторая диаграмма изображает команды, делающие нечто, что повлияет на работу других команд. Мы используем несколько простых правил для этих диаграмм:

  • Круг обозначает команду;
  • Стрелка между кругами обозначает зависимость. На первой диаграмме стрелка проводится от команды, выполняющей работу, к команде, которой нужен результат этой работы. На второй стрелка указывает на команду, на которую влияет чужая работа;
  • Метка на стрелке описывает суть зависимости;
  • Если зависимость согласована (то есть другая команда согласна выполнить свою часть работы), мы рисуем рамку вокруг метки.

Поначалу царит неразбериха, пока каждый рисует свои взаимосвязи, а наблюдатели задают вопросы и указывают на дополнительные зависимости. Минут через двадцать диаграмма стабилизируется, а комментарии иссякают. После этого мы просим представителя каждой команды коротко рассказать об их зависимостях.
За очень короткое время мы создаем полную картину взаимосвязей в релизе. На рис. 1 показан типичный результат сессии после приведения в более читабельный вид. Сразу выявляются горячие точки (то есть команды с большим количеством зависимостей). Также видны команды, имеющие несогласованные зависимости. Такие команды больше всех рискуют не достичь своих планов, пока их взаимосвязи не согласованы.

CrossTeamDepends

Рис.1. Пример диаграммы межкомандных зависимостей 

4.3 Открытые обсуждения
С недавних пор в течение недели после стартового собрания мы проводим открытые встречи, главная цель которых — создать площадку для обсуждения вопросов и проблем, связанных с планами команды на релиз. Мы просим, чтоб на этих встречах был хотя бы один представитель от каждой Scrum-команды, в остальном они необязательны для посещения. Обычно в начале открытой встречи участники предлагают темы для обсуждения. Далее в течение 45 минут проходят обсуждения тем в группах, а затем группы рассказывают остальным о результатах обсуждения. Чаще всего участники хотят узнать детали новой и полезной функциональности, а также об изменениях, которых повлияют на другие команды. Участники открытых встреч отметили поучительность таких обсуждений, кроме того людям оказалось интересно общаться с коллегами из других команд, с которыми они не взаимодействуют в обычной работе. Открытые встречи пока что новый формат для нас, так что мы пробуем разные варианты, чтоб понять, что работает лучше, например:

  • Предлагать идеи тем до начала встречи;
  • Привлекать к участию высокое начальство;
  • Менять количество и длительность дискуссий.

4.4 Обзор дизайна
Основная цель собраний по обзору дизайна функциональности — повысить общий уровень качества и удобства наших продуктов, с помощью:

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

Эти межкомандные собрания сосредоточены на дизайне функциональности и пользовательского взаимодействия для фич, которые мы считаем ключевыми, наиболее сложными или особо подверженными рискам. На таких собраниях мы стремимся проанализировать и выявить ранее незамеченные несоответствия и зависимости.
Существует два основных типа таких собраний. На ранних этапах релиз-цикла участники фокусируются на концепциях дизайна и стремятся достичь согласованности и эффективного взаимодействия между существующими и новыми фичами. На этой стадии в собраниях обычно участвуют Product Owner’ы и дизайнеры пользовательского интерфейса (UI), и изредка представители других функциональных команд, таких как разработка и QA.
Примерно в середине релиз-цикла состав участников меняется: теперь это в основном представители QA и отчасти разработки, а обсуждения сосредоточены на деталях реализации. Эти встречи обеспечивают понимание и ясность относительно:

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

4.5 Виртуальная команда архитектуры
Виртуальная команда архитектуры (Virtual Architecture Team, VAT) — «виртуальна», поскольку включает в себя разработчиков из всех Scrum-команд. Члены команды работают в VAT без отрыва от основных обязанностей в рамках Scrum-команды из бизнес-подразделений Applications, Platform или Core Infrastructure.
VAT отвечает за поддержку и развитие архитектуры нашего ПО. Команда определяет дорожную карту (road map) развития архитектуры, проводит обзор серьезных изменений с точки зрения архитектуры, определяет стандарты кодирования, чтобы обеспечить совместимость и поддерживаемость кода.
VAT управляет бэклогом важных архитектурных проектов и необходимого рефакторинга. По мере развития продукта нам приходится перепроектировать фичи и избавляться от старого неоптимального кода. Порой разработчики не хотят менять уже работающие программы, даже когда они понимают, что код программы оставляет желать лучшего. Product Owner’ы предпочитают видеть, как разрабатываются новые фичи, а не как переделывается нечто уже работающее. Чтобы противостоять таким настроениям, каждое наше бизнес-подразделение обязано запланировать не меньше 20% времени в каждом релизе на изменения рекомендованные VAT.
VAT собирается дважды в неделю на два часа для обзора технической реализации продуктов и фич, создаваемых Scrum-командами. Команды, работающие над наиболее сложными фичами релиза обязаны представить их VAT. VAT дает Scrum-команде обратную связь о том, как их технические решения затронут остальные команды, и какие разработки других команд могут повлиять на фичу. VAT сосредоточена прежде всего на технической реализации, особенно на аспектах масштабируемости и производительности. Если дизайн фичи требует серьезных изменений, то Scrum-команда обязана повторно представить фичу в том же релиз-цикле и показать VAT, как они изменили свой дизайн.

4.6 Непрерывная интеграция
Наша веб-инфраструктура автоматизированной сборки, тестирования и сортировки (triage) обеспечивает непрерывную интеграцию билд-системы и позволяет отслеживать состояние каждой строчки кода. Эта инфраструктура — ключевой аспект, позволяющий всем разработчикам и QA инженерам работать с общей базой кода.
Главный набор тестов построенный на расширении JUnit дает возможность создавать функциональные тесты с помощью API Force.com. Кроме того, у нас есть фреймворк для тестирования пользовательского интерфейса, использующий Selenium для автоматизации тест кейсов, которые нужно выполнять через UI.
Вот несколько фундаментальных принципов, определяющих наш подход к автоматизации:

  1. Давать разработчикам быструю обратную связь, чтобы они видели результаты своих изменений. Каждый коммит запускает сборку билда и выполнение набора тестов. В случае ошибки ответственные инженеры сразу же получают сообщение о сбое. Базовый набор тестов выполняется за полчаса, и разработчик получает результаты проверки внесенных им изменений. Периодически в течение дня выполняется расширенный набор тестов;
  2. Быстро чинить сборку и сбои тестов. Для этого у нас есть роль «мастера сборки», меняющая владельцев каждую неделю. Обычно эту роль выполняют два тесно взаимодействующих человека — менеджер разработки и старший разработчик. Мастер сборки отвечает за проверку результатов сборки, отслеживание тестовой истории и сбоев на различных строчках кода, а также назначение багов конкретным разработчикам для починки. У нас есть специальная панель, отображающая различные метрики исходя из собранных в базе данных результатов тестов (доля успешных тестов, время сборки, количество сбоев и т.д.). Мастер сборки использует эти данные при подготовке отчета о состоянии сборки;
  3. Поддерживать высокий уровень покрытия автоматизированными тестами. Обычно Scrum-команды стремятся покрыть автоматизированными тестами 70-80% кода. Один из наших важнейших активов — большой набор автотестов, играющий ключевую роль в поставке качественных релизов в срок каждые 3-4 месяца.

4.7 Scrum-of-Scrums
В каждом бизнес-подразделении еженедельно проводится собрание Scrum-of-Scrums, существует и » Scrum-of-Scrum-of-Scrums». Иногда мы организуем дополнительный Scrum-of-Scrums для группы команд, тесно взаимодействующих при работе над общей целью. Мы опробовали несколько различных форматов проведения Scrum-of-Scrums. Мы начали со стандартного формата «4 вопроса», когда команды сообщали, что они сделали, что собираются делать, что их блокирует, и делают ли они что-то влияющее на работу других команд. Поначалу это работало, но вскоре стало утомительным и скучным из-за большого количества команд. Тогда мы перешли к более открытому формату самоорганизации, когда участники предлагали темы для обсуждения, выписывая их на доске в начале собрания. Это заставило участников взять на себя ответственность за содержание митинга и привело к более продуктивным обсуждениям. Вопрос межкомандных зависимостей часто поднимается во время Scrum-of-Scrums, особенно на ранних стадиях разработки. Сессия распознавания взаимосвязей проводится во время Scrum-of-Scrums, и в последующие две-три недели на этом собрании часто обсуждаются изменения в межкомандных зависимостях.

4.8 Отчеты о состоянии
Когда команда переходит на Scrum, письменные отчеты часто становятся не нужны, поскольку ясность состояния теперь обеспечивается за счет других вещей (обзоры спринтов, burndown chart, ежедневные стендап-митинги). Когда мы перешли на Scrum, то решили сохранить облегченные еженедельные отчеты о статусе, которые готовит каждый Scrum мастер. Это выглядело избыточно пока мы использовали формат «4 вопроса» для Scrum-of-Scrums. Однако при нынешнем открытом формате Scrum-of-Scrums еженедельные отчеты стали важным дополнением к этому собранию. Мы не обсуждаем состояние каждой команды во время Scrum-of-Scrums, если только это не вынесено как отдельный вопрос, однако этот статус всегда доступен в еженедельном отчете. В отчете обозначены все зависимости, блокеры и риски. Конечно, такие отчеты требуют немного дополнительных усилий от Scrum мастеров, но ясность, которую они обеспечивают, оправдывает затраты на их создание.

5 Заключение
Salesforce.com доказала, что масштабирование Scrum осуществимо, и мы уверены, что сможем продолжать такое масштабирование по мере роста компании. По мере роста количества команд, управление взаимосвязями и межкомандная координация становятся непростой задачей. Критически необходима надежная инфраструктура сборки и автоматизированного тестирования. Очень помогает повышение осведомленности и синхронизация с помощью стартового собрания, сессии выявления взаимосвязей, Scrum-of-Scrums и облегченных отчетов о состоянии. В конечном итоге это приводит к эффективному общению, взаимодействию и обмену знаниями между командами. Такие подходы, как виртуальная команда архитектуры, открытые обсуждения и Scrum-of-Scrums призваны помочь общению и поддержать взаимодействие.

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

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

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

 

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

4k+ знаков про тестовое окружение

Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.

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

Говорят, хороший интерфейс ПО – тот, который пользователь «не замечает», а просто решает свои задачи, работая с программой. Про ТО можно сказать что-то подобное: чем проще подготовка и выполнение тестов, воспроизведение дефектов, работа с прочими артефактами, тем лучше ТО. Чем меньше мы спотыкаемся о разложенные нами же грабли, не относящиеся к тестируемому продукту, тем больше мы спотыкаемся о грабли в продукте, разбросанные разработчиками. А этого от нас и ждут, ага.

Создание такого ТО, понятно, требует труда. По сути, это такой сопутствующий проект – со своими требованиями, дедлайнами и потребителями. Скорее всего, этот проект будет длиться не меньше, чем собственно разработка system under test (SUT). От этого проекта серьёзно зависит успех производимого продукта.

Можно выделить несколько требований, актуальных для большинства ТО.

Применимость

ТО должно отвечать поставленным задачам. Железо должно соответствовать требованиям к SUT. Хорошо бы, чтоб конфигурации были подобны тем, что используются в боевом режиме (или мы хотя бы знали diff).

Конечно, ТО должно позволять выполнить необходимые тесты и прочие активности. Должна быть возможность проверить различные важные конфигурации (поддерживаемые ОС, БД, локализации, и т.д.). В общем, тестировщики должны иметь возможность тестировать, иначе зачем всё?

Изолированность

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

Подобная изолированность защищает, с одной стороны, от особенностей конфигурации отдельных машин. С другой – от потери данных из-за нестабильности SUT. С третьей – упрощает контроль за состоянием SUT и конфигурациями, обеспечивает воспроизводимость тестов. Ладно, даёт шанс обеспечить воспроизводимость.

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

Доступность и простота

Если нет каких-то особых причин для обратного, ТО должно быть легко доступно для всех, кто с ним работает – тестировщиков, программистов, аналитиков и других интересующихся.

Не должно быть проблем с созданием нового экземпляра SUT в требуемой конфигурации.

Нам нужна возможность без особых затрат отслеживать состояние и использование ТО – что где находится и почему, кто использует тот или иной объект (например, копию SUT), где у нас есть свободные ресурсы, и т.д.

По возможности следует исключить конфликты использования общих ресурсов/объектов.

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

Управляемость

ТО должно быть управляемо. Добавление или замена серверов должны происходить максимально просто. Внезапные падения старых машин не должны вести к фатальным последствиям (ну, хотя бы не всегда). Перенос данных между серверами тоже не должен становиться проблемой.

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

Стабильность

Пусть SUT сколь угодно нестабильна, ей можно, а ТО должно быть здоровым и непотопляемым. Тут стоит задействовать практики рекомендованные системным администраторам (кстати, невредно с ними проконсультироваться, если есть с кем) – мониторинг состояния железа, контроль нагрузки на сервера, регулярные бэкапы и подготовка сценариев на случай внезапной смерти Самого Важного Сервера…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Правильный багрепорт для всех и каждого

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

Если тестировщик не может ясно сформулировать, что он имеет в виду; если он путается в терминах, забывает указать важные нюансы и не может совладать с эмоциями, то из его багрепорта зачастую мало что можно понять. Баг возвращается обратно (а их и так уже много вернулось), начинается пинг-понг, все нервничают и не любят друг друга.

Проблема

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

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

Решение

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

Более правильный подход: сделать шаблон, которым будет удобно пользоваться. А лучше бы — такой, каким не получится не воспользоваться. За свою карьеру тестировщика я видел несколько вариантов подобных шаблонов.

История вопроса

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

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

Далее: мне стало лень каждый раз копировать информацию из текстового файла, и я вгляделся в интерфейс багтрекера (в моем случае это была Bugzilla). Оказалось, что там есть чудесная кнопка [Remember values as bookmarkable template]. При нажатии на нее Bugzilla генерит ссылку, которую можно добавить в закладки браузера; вкусность в том, что в этой сслыке сохраняются значения всех полей, в том числе текст введенный в поле для описания проблемы. Естественно, я тут же перенес данные из текстового файла в форму багтрекера и создал закладку. На качестве багрепортов это сказалось не сильно, но теперь на каждый баг я тратил чуть меньше времени.

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

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

Выгода

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

Впрочем, не только новичкам.

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

Тестировщик выдыхает, пишет в багтрекер пару фраз и довольный идет пить кофе. А возвратившись обнаруживает, что баг вернули, потому что «ничего непонятно, ты о чем вообще?». И хорошо еще если баг вернули в тот же день, пока память о битве свежа, и логи под рукой.

Что произошло? Все просто: тестировщик сильно погрузился в контекст проблемы и забыл написать, что проблема заключается в том, что котенок не может перемещаться по наклонной поверхности с углом в 14 градусов, потому что при таком угле лапы уже скользят, а когти еще не выдвигаются. И актуально это для котят 17го поколения. А написал он просто: при 14ти градусах когтей еще нет. Что он хотел сказать? Непонятно. Ведь может и хорошо, что их нет.

А вот если бы багтрекер сразу предлагал шаблон бага, то тестировщик не смог бы описать баг только парой невнятных фраз. Само наличие шаблона уже слегка возвращает к реальной жизни, и человек задумывается: Ожидаемый результат? А кстати, что я ожидал-то? А, да: что котенок будет ходить, и когти выдвинет, если нужно. Как повторить проблему? Посадить котенка на доску и наклонить ее под нужным градусом. И так далее.

Резюме

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

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

Харизму, инструкции и рубли это не отменяет — просто не всегда они нужны, иногда все проще решается.