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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SUT с человеческим именем

Допустим я тестирую продукт, который работает [в том числе] с «человеческими данными».

Где-то для чего-то указываются и хранятся имена, емейлы, логины, телефоны и тому подобное. Есть формы, где можно данные редактировать, потом эти данные где-то показываются и используются. Есть и прочие вещи, слабо связанные с этими данными, например, возможность давать пользователю разные права: тут не обойтись без объекта «пользователь», но всякие атрибуты вроде имени/телефона обычно не важны. Другими словами, при тестировании можно указать любую белиберду, которую система согласна принять.

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

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

Например, вдруг оказалось, что в некоторых местах даже не очень длинные имена банально не влезают в отведённое пространство. Тут средней длины имя домена, тут фамилия пользователя, и вот емейл созданный по шаблону либо вылезает за границу поля, либо не виден полностью, либо появляется горизонтальная прокрутка на сайте, или ещё какое чудо случается. В первый раз очень удивляет: «обычный!»-то pb@pb1209.com нормально помещался, ничего не съезжало.

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

То же и при работе с названиями учреждений и компаний. Например, список ВУЗов города содержит много записей с одинаковым началом «Китежгородский государственный …» а до остального еще поди дотянись глазом. С выдуманными названиями можно и не обратить внимания, а с настоящими сразу приходит мысль, что хорошо бы указывать ещё и аббревиатуру на видном месте: тогда проще не спутать КГУ, КГИТ, КГМУ и т.п. То есть [почти] настоящие имена и названия помогают увидеть, обо что споткнётся пользователь — и вовремя улучшить эти коварные места.

Что до классов эквивалентности, то отчасти и их можно тестить с помощью настоящих имён. Так, по интернетам ходят слухи, что самое длинное имя содержит более 1000 символов. Как, обработает такое имя наш продукт? Или — имя не может быть длиннее 128 символов (БД ведь не резиновая)? А как насчёт имён, состоящих из нескольких слов и включающих в себя пробелы? Понятно, что индустрия таких людей не балует, они уже не ждут многого от IT и давно научились указывать краткое имя. С другой стороны — толика уважения, возможность указать полное имя, — такие вещи подкупают людей.

Так что теперь я использую имена и названия похожие на настоящие. Или — просто настоящие. Это привело к паре побочных эффектов. Первый из них: продукт тоже стал «более настоящим». Используя фейковые и тестовые имена я не мог отделаться от ощущения, что я не коммерческий продукт работаю, а играю в kind of компьютерной игры. Найди проблемы в продукте и добейся чтоб починили. Ачивку нарисуешь себе сам. А вот поверить, что продукт кто-то где-то по-настоящему использует — толком не получалось. То есть я знал, я видел проблемы утекшие к клиентам, обсуждал случившиеся на продакшенах фейлы, но ощущения что «всё по-настоящему» не было. С нормальными именами это ощущение стало появляться. Потому что в списках, формах и т.д. — не ерунда какая-то, не «абырвалг», а человеческие имена, адреса, телефоны, названия и прочая «ГлавРыба». К ним уважения и сочувствия больше.

Второй сайдэффект — для некоторых любимых имён потихоньку вырисовываются роли и профили. Что этот конкретный Имя Фамилия знает, любит, не любит, что хочет от продукта и как к нему относится. Всякая такая вот ерунда. Понятно, что эта Америка давно открыта, и подобные персонажи уже классика UX. Просто тут это само собой появляется, всего лишь оттого, что используются нормальные имена, которые сами навевают ассоциации. И да, нет необходимости формально определять и расписывать персонажей. Иногда они живут всего лишь одну-две тестовых сессии. Но успевают помочь по-разному глянуть на продукт.

Как по мне, вполне достаточная польза, чтоб использовать [почти] настоящие имена, названия и прочие атрибуты.

Напоследок пара слов о том, где взять эти самые имена: не тратить же время на выдумывание прямо во время тестирования.

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

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

Уважение к старшим

С легаси кодом не просто.

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

Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой — лучше к нему не прикасаться.

Так вот знаешь, что? Уважай его.

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

Серьёзно, без него у тебя не было бы этой работы.

Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде — это следы древних багов. Будешь небрежен — и те же баги повторятся уже в новом коде.

Это легаси. Уважай его.

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

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

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

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

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

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

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

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

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

От процесса

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

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

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

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

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

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

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

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

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

От проблем

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

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

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

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

От себя

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

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

 

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

Разработка и Продажи

Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи    (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи    (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи    (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь):  Вот  черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: «Об Разработку!»
Занавес

 

P.S. Основано на вымышленных событиях

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

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

Ниже — перевод статьи «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 как идентификация готовности продукта к релизу

Марти Лэйни. Преимущества интровертов

 

 introvert-advantage Марти Лэйни. Преимущества интровертов
Marti Laney. The Introvert Advantage
«Манн, Иванов и Фербер» , 2013
ISBN  978-5-91657-817-1

Отличная книга про интровертов и для интровертов. Очень крутая, правда.

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

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

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

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

Ниже — набор наблюдений, идей и советов, найденных в книжке (неполный, конечно).

Статистика и модель

По некоторым исследованиям, до 75% людей — экстраверты.

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

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

Что свойственно интровертам

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

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

У интроверта и экстраверта разные источники энергии

  • Интроверт — внутренний мир идей, эмоций, впечатлений
  • Экстраверт — внешний мир

Интроверту следует

  • Ограничить социальные контакты, чтоб не быть опустошенным и измотанным
  • Бывать в социуме, иначе теряется видение перспективы и взаимосвязи

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

Интроверты общительны. Но им нужны не многочисленные контакты, а — более тесные связи.
Интроверт не получит удовольствия от «праздных» бесед. Он предпочитает беседы по существу, в которых для него есть пища и энергия.
Интроверты не говорят просто ради того, чтоб что-то сказать. Они озвучивают свои мысли (испытывая при этом некоторые трудности при точном их формулировании). И — озвучивают не всегда, так как опасаются отнять слишком много времени и пространства у других.

Интроверты меньше раскрываются и меньше объясняют свои действия

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

Немножко о мозге

Темперамент человека берет начало в генах.
Его реакция на мир и поведение зависит от того, какие участки мозга активированы

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

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

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

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

Немножко странного

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

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

Интроверты помнят много и хорошо, но им нужно время, чтобы вспомнить.

Интроверт на публике

Интроверты находят удовольствие в испытанном и проверенном. Они не склонны к спонтанным приключениям.

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

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

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

Интроверты часто не осознают, что нравятся людям, поэтому общение не приносит им особого удовольствия

Несколько советов интроверту

Время от времени полезно «включать» свободные ассоциации — разрешать мозгу просто прыгать с одного предмета на другой. Это позволяет интроверту вспомнить о себе много «позабытого»

Собираясь на вечеринку, публичный прием
— Запланируй время на восстановление сил
— Оставь себе возможность уйти пораньше если потребуется

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

Иногда интроверты отказываются от чего-либо просто «по инерции», из-за закрепленного стремления, чтоб их оставили в покое. Если сильно преуспеть в этом стремлении, интроверт может впасть в депрессию.
Нужно иногда пересиливать такую инерцию и говорить «да», соглашаться на новые предложения.

Стратегии «экстравертного» поведения

  • [Иногда] говори первое, что пришло в голову.
  • Не прокручивай старые события вновь и вновь. Лучше продолжай движение вперед
  • Выделяй время на пополнение энергии — в течение дня, в течение недели, перед/после важных событий
  • Обращай внимание на смешные стороны жизни. Юмор помогает выходить за рамки, видеть разные стороны жизни.

Напоследок

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

100500 конфигураций

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

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

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

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

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

Начнем с относительно простой ситуации, когда заказчик и покупатель у нас один. Этот случай проще, так как мы можем довольно точно узнать, как [будет] настроена его система, и отбросить остальные варианты. Даже в этом случае возможны проблемы: не всегда удается в тестовой лабе воспроизвести масштаб и сложность боевой системы. Ок, давайте тестировать в «похожем окружении».

Вот тут важный вопрос – что такое это «похожее окружение»? Чем оно похоже на боевое, а чем отличается? Если ответ неизвестен – то и результат тестирования не вполне понятен. Зная ответ – уже можно понять, что мы можем адекватно проверить, а что нет, в каких местах могут потом появиться проблемы; можно подумать, как все-таки проверить эти проблемные точки (возможно – за пределами тестовой лабы).

Если покупателей много, то они обычно используют продукт по-разному – в разных условиях, с разными настройками. Чаще всего проверить все условия/настройки в срок невозможно, зато мы можем как-то расставить приоритеты. Более популярные конфигурации тестировать тщательней, менее используемые – поверхностно. Цель в том, чтоб избавить от проблем основную массу пользователей. Да, мы что-то можем упустить для редко используемого случая, но это заметят сравнительно немногие.

Опять важный момент: хорошо бы представлять, сколько их, тех немногих, и кто они; какие конфигурации популярны, а какие нет. Можно, конечно, пытаться угадать (не, не угадаете), лучше – как-то собирать эту информацию.

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

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

Если есть возможность – можно устроить какой-то вариант альфа/бета-тестирования. Договориться с крупным клиентом, что специфические особенности будут проверены в его тестовой лабе. Раздать продукт сотрудникам и спросить их мнение. Выложить бету в публичный доступ и собирать отзывы и баги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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