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

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

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

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

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

4k+ знаков про ТО

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

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

Правильный багрепорт 2: точность описания и исследование проблем

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

В прошлом посте про качество багрепортов я писал, как не забыть упомянуть в описании проблемы важную информацию, которая в момент описания бага кажется очевидной (для тестировщика, находящегося в контексте собственных действий). Я тогда предлагал простое техническое решение, которое напоминало, что помимо самой проблемы нужно еще упомянуть ряд параметров окружения и ожидания тестировщика от поведения приложения. Однако подобным образом можно перечислить только небольшой набор самых общих параметров, упоминание которых необходимо, но зачастую недостаточно для исследования/понимания сути проблемы. Набор данных, которые стоит упомянуть в описании проблемы, разнится от проблемы к проблеме - где-то достаточно сделать скриншот, где-то нужно добавить логи, нередко и в базу данных заглянуть полезно. Как же понять, что писать, а что нет? Ведь избыток информации тоже может запутать разработчика.

Рунглиш. Новояз. Жаргон.

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

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

Профессиональный жаргон - дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT - просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами:

Почему-то не я, а он

В дни перемен, в дни тяжких раздумий практически всегда находятся недовольные. Причин для недовольсства обычно находится масса - неудобные новые утилиты или процессы, заброшенные старые инструменты, необходимость учить новое и так далее.
В данный момент речь пойдет о недовольстве карьерными решениями.
"Почему на место ушедшего руководителя назначили Михаила? Ему даже и тридцати еще нет, а мне уже 32, а я простой инженер. Не ценят меня."
"Саше присвоили новую категорию, а мне нет. А ведь вместе пришли сюда, и работу примерно одинаковую делаем."
"Ну вот, опять зарплату не повысили. Ишачишь тут, ишачишь..."
Зачастую, если спросить такого недовольного: "а почему продвигать надо было тебя?", ответ будет примерно "Ну я же хорошо работаю". Довольно странное обоснование на самом деле. Человека наняли на работу, очертили ему круг деятельности. Зачем его продвигать, если он всего лишь хорошо делает свою работу? Работа разная бывает, но в часто в ней много рутины, которая уже через полгода не требует участия мозга. Так чем заслужил поощрение человек, который просто сидит и не включая мозг повторяет день за днем примерно одни и те же действия?
Вот если человек растет, экономит свое и чужое время, упрощая рутинную работу, изучает новое (полезное для работы) и рассказывает другим узнанное, если он думает на шаг вперед - тут уже есть повод для продвижения и поощрения. Но почему-то не так уж много народу додумывается до этой простой мысли. Обычно наоборот: "Вы мне зарплату увеличьте, тогдя я может и подумаю, а не пошевелиться ли мне тут".
Тут есть еще один нюанс - важно, чтобы руководитель знал о достижениях своего подчиненного. Иначе у руководителя так и не появится повода похвалить :).

В общем, по сути речь идет о двух аспектах:
1. Не надо ждать, что вас станут продвигать за красивые глаза и просто хорошую работу. Взбивайте масло из этой сметаны и будьте готовы предъявить результаты.
2. Постарайтесь, чтобы человек, принимающий решения о поощрении/продвижении знал, как здорово вы развиваетесь и чего достигли.

Мысли не новые, но банальные истины не перестают быть истинами :)

Окно в работу

Каждый день мы работаем над своими задачами, и каждый день нас от них отвлекают. То начальник, то коллега; то аська, то письмо; то вопросом, то ссылкой на видеоролик.

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

Если по-простому, то коммуникационное окно – это время, когда человека дергают по минимуму. Идеальное коммуникационное окно – время с пяти утра и до девяти. Все спят, отвлекать некому, можно спокойно работать. Тут только одна проблема – проснуться :). Впрочем, это из разряда крайностей и экстрима. Вариант попроще – например, не читать почту сразу после получения. Если возможно – вообще открывать почту примерно раз в час. E-mail по определению несрочный вид общения, и час промедления обычно не так уж важен. Опять же, если человеку так уж нужен срочный ответ, а запрос проще послать почтой, он может прийти ногами или позвонить и попросить срочного ответа. Не стоит, кстати, впадать в другую крайность и прекращать читать почту вообще. За это тоже спасибо не скажут.

В целом, на самом деле, организовывать такие коммуникационные окна в течение рабочего дня непросто. Почту можно не читать сразу, но от телефона никуда не денешься. В аське можно сидеть в инвизибле, но со временем на это перестанут обращать внимание. Можно ставить большие плакаты «Не беспокоить! Работа мозга!», но гарантии, что это поможет, нет.

С другой стороны, при желании можно выбить себе час спокойствия в день; может поэтому многие программисты и любят несколько сдвинутые относительно «с 9 до 18» графики. Основная проблема с этими коммуникационными окнами в другом: они хороши, если работа не требует участия других людей – дополнительной информации, консультаций, результатов чужой работы и так далее. А такое случается далеко не всегда. Но если случилось – техника полезная :)

Граничные условия

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

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

Успешные компании постоянно совершенствуют все, что можно – процессы, логистику, людей (тренинги, а как же), схемы продаж и т.д.

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

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

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

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

Ну и, конечно, не надо выдумывать новые бессмысленные ограничения. Вполне достаточно следования тем, что проверены веками :)