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

Exploratory Testing Dynamics

James Bach опубликовал новый документ, описывающий Exploratory Testing. Очень интересный док. Чего только стоит: "Imagine a problem, then find it."
Рекомендую к прочтению.

http://www.satisfice.com/blog/wp-content/uploads/2009/10/et-dynamics22.pdf

пятница, 16 октября 2009 г.

Постановка задачи тестирования


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

Постановка задачи тестирования
1. Что именно нужно тестировать? (дистрибутив, ссылки на веб клиенты).

2. Вид тестирования (Функциональные (+уровни тестирования); Нефункциональные; Связанные с изменениями).

3. Как тестировать? (что конкретно должно быть протестировано, что должно быть проверено обязательно, что дополнительно, что "если останется время").

4. Где документация? (спецификация, требования).

5. Когда и как долго тестировать? (сроки, время начала, если сразу нельзя начать)?

6. Где тестировать? (адреса, ссылки, машины, ОСи, окружение)?

7. Чем тестировать? (инструменты, файлы)?

8. Где необходимые инструменты, артефакты? (файлы, базы, логины, пароли, учетные записи, сертификаты и т.д.).

9. К кому обращаться за дополнительной информацией?

11. Что делать с результатами?

12. Необходим ли отчет? (если да- см. заявку на отчет).

13. Критерии успешного (неуспешного) тестирования. (если необходимо дать оценку, заключение).

10. Дополнительные инструкции.

пятница, 9 октября 2009 г.

Заявка на получение отчета о тестировании.

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

То есть требуют "то, сами не знают что".
Ну да- бывают ситуации, когда руководители (делают вид, что) не в курсе, что "если хочешь получить от коллег или подчиненных результат,- убедись что: все знают что сделать, как сделать, у них есть желание и средства для этого".
Опустим философию. Итак- есть проблема: чего-то требуют, чего именно не объясняют, на наводящие вопросы не отвечают\отвечают уклончиво. (причины этого тоже опустим.)
Как решать?

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

Воспользовавшись ресурсами it4business.ru, статьей в блоге "255 ступеней" (http://blog.shumoos.com/archives/190) оформил вот такой список вопросов, ответы на которые нужно включить в постановку мне задачи о написании отчета о тестировании.

Заявка на получение отчета о тестировании.
Так как отчет о тестировании может быть сформирован множеством способов, зависящих от того, кому отчет? зачем? что на его основании будут делать?- при следующей необходимости написания отчета предлагаю вместе с постановкой такой задачи отвечать на вопросы:
кому отчет?
зачем?
что на его основании будут делать?
что нужно показать?
указать, что работает или что не работает?
другие комментарии.
А также следует ли отвечать на вопросы вида:
1) Это можно продавать/устанавливать или нужно доработать/выкинуть?
2) Какова степень уверенности?
3) Как называется то, о чем идет речь?

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

Что именно тестировать?
Как тестировать (что должно быть проверено обязательно, что дополнительно)?
Когда тестировать (сроки, время начала, если сразу нельзя начать)?
Где тестировать (адреса, ссылки)?
Чем тестировать (инструменты, файлы)?
Где необходимые приложения (файлы, базы, логины\пароли, учетки, сертификаты и т.д.)
Инструкции.
Другое.

вторник, 6 октября 2009 г.

Корректность фиксов багов

Должны ли разработчики проверять корректность своих фиксов?
Проблема обсуждалась неоднократно на форуме проекта it4business.ru , в блогах и т.д. Попробуем разобраться в ситуации.

Априори предполагаем наличие здравого смысла в организации процесса и ясность смысла проверок всем ясна. Итак, если проверки необходимы, то их кто-то должен делать- либо сами разработчики, либо тестировщики. Рассмотрим 2 варианта: 1- тестировщиков на проекте не достаточно; 2- тестировщиков достаточно для того, чтобы смотреть еще и за результатами фиксов, несмотря на то, что времени на тестирование всегда не хватает. Второй утопический случай можно смело отбросить) и поставить вопрос так: должны ли разработчики сами проверять не только корректность конкретного фикса, но и некоторое минимальное окружение вокруг этого фикса (бага)? То есть ограничиваться ли автору фикса проверкой только лишь того конкретного бага\проявления бага, который указан в баг репорте? Или все-таки включить мозг, попробовать другие действия, окружение и т.д.

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

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

Что получилось:

Вобщем я решил, что такой регламент должен быть коротким, чтобы разработчикам было не лень его читать и применять. Также чтобы он описывал только основные моменты.
Смысл его введения:
1. Разработчики дожны проверять, что то, что они сделали (написали\пофиксили), работает вообще.
2. Разработчики дожны проверять, что то, что они сделали, работает корректно.
3. Разработчики дожны проверять (хотя бы в минимальной степени), что то, что они сделали, не ломает существующий, корректно работающий функционал.
Можно переложить почти все эти проверки на тестировщиков при условии, что как максимум на 4 разработчиков будет 1 тестировщик. В нашем случае это без вариантов.
По опыту тестирования (конкретного софта) могу сказать, что очень много времени у меня уходило: на поиск существующих в системе баг трекинга баг репортов + их возвращение, комментирование; на запись похожих. При организации проверки фиксов разработчиками этого бы не понадобилось. А потраченное время я бы потратил на более серьезную проверку.

Проверка фикса (не только):
1. Время верификации каждого фикса не более 10-20 мин.
2. В первую очередь производится попытка воспроизведения бага (по описанным шагам).
3. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.).
4. Проверка этих областей.
5. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)).
6. Проверка этих методов.
Минимальное свободное тестирование (специфично для определенного софта):
7. Проверка работы с некорректными данными (например, сохранение, поиск по ним).
8. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт).
9. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными
обязательными полями).
10. Если, например, теструется установка дистрибутива или импорт данных, имеет смысл
использовать виртуальные машины для одновременной проверки разного функционала или
параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и быстрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).

Все это опять же- FYI.

пятница, 2 октября 2009 г.

Относительная плотность багов

Окунемся в теорию.
Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:

1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди);

2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);

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

Обозначились проблемы. Попробуем сделать выводы и найти решения проблем.
выводы:
1. четко регламентировать и описать процесс работы. (Что даст нам ускоренное знакомство с софтом, инструментами, людьми путем четкого распределения обязанностей (кто что делает и почему), источников информации (кто как делает, зачем делает и какими средствами).

2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).

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

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

5. ревью тестов. (Изменяем\дополняем проверками, методами, которые раньше не проводились. Тут можно подумать, что первичный вариант тестов был не полным или неграмотным. Имеется ввиду- изменить проверки на аналогичные.).

6. ротация людей по областям (не обязательно всех), взаимозаменяемость.

7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).

8. контроль предпринятых мер и мониторинг результатов. (Незачем продолжать неэффективные способы).

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

Отдельно стоит заострить внимание на пунктах 6 и 7. Возможности их осуществления должны быть заложены при планировании работы всей группы тестрования над тем или иным проектом. Если вы, например, решаете зафиксировать деятельность отдельных тестировщиков в проекте, то будет затруднительно менять направление деятельности каждого.

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

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

четверг, 1 октября 2009 г.

Круговорот документации

Примерно полгода назад получил задание создать (воплотить в картинке) примерную схему оборота (использования) документации при разработке. Дело было еще до внедрения TFS. Но могу сказать, что после ее внедрения радикальных изменений не стал бы вносить в эту схему. Вот что получилось: