среда, 21 декабря 2011 г.

Идея для парного тестирования

      Уже некоторое время ношусь с идеей для парного тестирования, но пока нет возможности опробовать ее на практике. Делюсь - может кому пригодится.
      Сразу уточним: под парным тестированием в данном случае имеется в виду не то тестирование, когда двое сидят за одним компьютером и один тестирует, а другой смотрит.
Тогда о чем это мы? А вот о чем:

вторник, 18 октября 2011 г.

Заметки об управлении дефектами


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

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

     Итак, список полезностей в управлении дефектами:

понедельник, 3 октября 2011 г.

Зачем нужны тестировщики? Презентация

- А как вы развлекаетесь?
- Графики рисуем.
(один известный фильм)

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



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

Как тестировщикам получать ответы у программистов. Часть 2

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

Начало здесь: Грабля №1: Программисты не любят внезапных прерываний.


Грабля №2: Программисты не любят «глупых» вопросов

    Я пишу слово «глупых» в кавычках, потому что тут уместнее было бы написать «ленивых». Бывают ленивые вареники, но я не уверена правильно ли так говорить о вопросах. Но мы сейчас к этому подойдем.
    Вы знаете, что такое меритократия? Если не знаете - не страшно. Большинство программистов тоже не знает, но они все без исключения этому следуют. Грубо и обобщенно говоря, это аристократия, основанная на способностях (некоторые меритократы могут захотеть меня опровернуть, но я не стану вступать в дисскуссию). Как и в любом профессиональном сообществе, авторитет и уважение в IT основаны не на должностях, - не на том, что вы тест-менеджер, а коллега – рядовой кодер, -  а на интеллекте, знаниях, умениях. Умные люди не любят дураков и лентяев. Именно поэтому в IT терпеть не могут:

среда, 14 сентября 2011 г.

Как тестировщикам получать ответы у программистов. Часть 1

      Каждому тестировщику жизненно необходима информация о ПО, что предстоит тестировать. Мы спрашиваем программистов о том, как работает та или иная функция, советуемся, как лучше её проверять, иногда прибегаем к их помощи в автоматизации и так далее. Без нормального общения тестеров и девелоперов успешная работа над проектом невозможна.
      В какой-то период времени я обнаружила, что в общении с программистами есть грабли, наступание на которые карается раздражением в мой адрес, ухудшением отношений, пустой растратой сил, времени и нервов, бойкотом моих вопросов и просьб и тому подобным. Но с нервами можно справиться; хуже было, когда выяснялось, что из-за нехватки информации или неправильного понимания я тестирую не то или не так. Общение с коллегами показало, что не одна я сталкиваюсь с такой проблемой. Иногда тестировщикам просто мучительно больно добиваться ответов у программистов.
      Поэтому, вдохновившись примером Джоэла Сполски, несколько постов я посвящу тому, как тестировщикам получать ответы у программистов малой кровью :).
      Для начала давайте рассмотрим, какие грабли бывают при задавании вопросов программистам, и разберемся, как избежать наступания на них.

понедельник, 4 июля 2011 г.

Исследование дефекта

Итак, мы обнаружили проблему. Что дальше?

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

вторник, 19 апреля 2011 г.

Как быть с минорными дефектами

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

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

Но! 

четверг, 31 марта 2011 г.

Тест-дизайн - это удаление тестов

Задача тест-дизайнера - уменьшить множество возможных тестов до их приемлемого количества.

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

среда, 16 марта 2011 г.

"Серебряная пуля" тест-дизайнера

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

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

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

пятница, 4 марта 2011 г.

Минусы тестирования по плану

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

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

четверг, 3 марта 2011 г.

Доводить действие функции до логического конца

В общем случае проектируя тест, следует не останавливать его шаги на действиях в диалоговом окне, а проследить выполнение функции до её логического конца.
 
Ошибку не доведения действия функции до конца часто совершают начинающие, и я сама не раз на этом попадалась. Тестировщик в первую очередь сосредоточенно тестирует поля ввода в диалоговом окне, например, сохраняются ли галочки на правах у данной группы пользователей. Однако это второстепенно. А первостепенно - отработка этих настроек системой. Действительно ли пользователю доступна запись, если в его настройках прав установлен флаг "Запись"?
Вывод: целесообразно сначала тестировать логику, потом - детали ее реализации в GUI.

суббота, 26 февраля 2011 г.

Тест-дизайн: теория vs практика


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

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

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

Где ты, Сканави для тестировщиков?

вторник, 8 февраля 2011 г.

Как извлекать пользу из семинаров/ тренингов не посещая их


Если хочется принять участие в семинаре или тренинге, но не получается их посетить, из этих мероприятий все равно можно извлечь пользу, причем совершенно бесплатно.
Пользу можно получить читая программу тренинга или семинара или что там мы себе выбрали. Например, нас заинтересовал тренинг Алексея Баранцева "Тест-дизайн от А до Я". Открываем анонс и читаем: