Показаны сообщения с ярлыком техники. Показать все сообщения
Показаны сообщения с ярлыком техники. Показать все сообщения

среда, 3 октября 2012 г.

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

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

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

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

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

понедельник, 17 января 2011 г.

О тестировании документации

Documentation is like sex: when it is good, 
it is very, very good; and when it is bad, 
it is better than nothing.
Dick Brandon

Когда заходит речь о тестировании, обычно обсуждается тестирование приложения в том или ином виде. Функциональное тестирование, тестирование безопасности, нагрузочное тестирование, тестирование требований - все это относится к приложению. Это действительно важные аспекты поведения продукта, и количество уделяемого им внимания вполне обосновано. Тестирование документации, поставляемой вместе с приложением (неважно, каким именно способом - в виде книжки, PDF файла или базы знаний на сайте), нередко проводится по остаточному принципу. С одной стороны этот подход делает актуальной фразу вынесенную в эпиграф. С другой - соображения, высказанные в этой фразе могут стать причиной, почему документация так плоха.

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

Обычно документация не обновляется вся целиком. Появляются новые возможности в продукте, их описание добавляют в документацию, а потом назначенный человек (или несколько) проверяет, что "все в порядке". Это неплохой вариант, когда проверку выполняет опытный человек, хорошо знакомый с продуктом и прочим контекстом (предметной областью; языком, на котором написана документация; целевой аудиторией и так далее). Проблема в том, что часто нет никаких формальных подходов к выполнению таких проверок. Человек читает документацию, по сути - проверяя, не зацепится ли взгляд за что-то странное. Зацепился - хорошо: обсудил с окружающими, открыл баг. Не зацепился - никаких гарантий, что проблем действительно нет. 

вторник, 16 ноября 2010 г.

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

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

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

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

пятница, 15 октября 2010 г.

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

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

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

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

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

пятница, 5 февраля 2010 г.

Окно в работу

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

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

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

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

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