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

понедельник, 10 сентября 2012 г.

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

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

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

четверг, 7 апреля 2011 г.

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

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

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

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

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

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

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

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

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

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

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

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

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