А наша сегодняшняя тема выпуска - тест-дизайн

Что такое тест-дизайн? Это проектирование тестов, или тестовых наборов. Их задача - эффективное покрытие программы тестами без излишних трудозатрат.

В неразвитых процессах тестировщики занимаются так называемым monkey-clicking: нажимают на кнопочки и ищут баги. В результате, времени они тратят много, а ошибки всё равно пропускают.

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

Что же происходит в развитых процессах тестирования?

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

Как же они делают это магическое действие, проектирование тестов? В первую очередь, тестировщики исследуют продукт. Для этого чаще всего используются интеллект-карты, или mind maps. (При первом использовании их все ругают, но не торопитесь! Со временем от них за уши не оттащить, потому что это очень удобно!). В этих картах они выписывают все действия, которые выполняют программы. Все-все. И да, зачастую их согласовывают с программистами, аналитиками, РМами, чтобы убедиться, что ничего не пропущено.

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

Итак, супер, действия выяснили, параметры определили, входные значения выбрали. Что дальше? А дальше самое страшное - комбинаторика! К сожалению, не все дефекты вызываются определённым входным значением, иногда они бывают при их комбинации. К примеру, сложение отрицательных чисел работает, дробных работает, а отрицательных дробных - нет!

Что делать? Комбинировать! Существуют различные техники комбинации входных значений: атомарные проверки, или полный перебор, или попарный перебор (pairwise)... Мы всегда можем выбрать оптимальный способ, исходя из критичности проверяемой функции и времени, которое у нас есть на тестирование.

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

Где подробнее узнать о техниках тест-дизайна?

Книги:

·Моя любимая, Lee Copeland, "A Practitioner's Guide to Software Test Design": http://testbooks.ru/?p=144

· Ещё одна дельная книга, хотя и чуть менее практичная: Glenford J. Myers, "The Art of Software Testing": http://testbooks.ru/?s=art

Курсы:

·Школа Тестировщиков, Наташеньки Руколь:) http://software-testing.ru/trainings/catalogue/online/118-school-for-testers

·Практикум по тест-дизайну, Лёши Баранцева: http://software-testing.ru/trainings/catalogue/online/113-td

Внимание! Для участников рассылки скидка на эти курсы 10%! Обязательно напомните об этом при регистрации:)

Про интеллект-карты:

·Про карты, без привязки к тестированию: http://www.mind-map.ru/

·Ссылка на скачивание самого функционального инструмента по созданию Mind Maps: http://thepiratebay.org/torrent/5793238/Mindjet.MindManager.v9.0.246

И напоминаю, что книги и курсы - это только помощь! Помните 4й выпуск? Вы можете выбрать себе "подопечный" сайт для экспериментов, создать по нему тестовый набор и обсудить на форуме!:)

До связи!

Выпуск #6: Как работать с требованиями к ПО?

Привет,

Вот уже 6й выпуск нашей рассылки, и тема этого выпуска - работа с требованиями.

Вообще-то, требования пишут аналитики, разрабатывают программисты, проверяют тестировщики. Но, увы и ах, в жизни всё не так просто!

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

2.Требования не всегда пишутся хорошо, и в этом случае задача тестирования - их проверка, мягкая критика, и приведение к должному виду.

3.Иногда требования всё-таки есть, и в этом случае наша задача - контроль их реализации.

Давайте разберём все три пункта по отдельности.

Требований нет, что делать??

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

Варианты действий тестировщика в данной ситуации:

· Попробовать написать требования самостоятельно и согласовать с аналитиком или РМ'ом. Что хорошего в таком варианте:

·Вы занимаете проактивную, ответственную позицию и неизбежно растёте в глазах коллег:)

·Вы получаете то, что так важно в тестировании - требования!

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

· Выяснить требования на общем собрании, так, чтобы все участники проекта имели общее понимание продукта. Для этого необходимо собрать всю проектную команду, подготовить вопросы, запереть в одной комнате и узнать ответы, убедившись, что у всех одинаковое понимание "что делать?". Это хороший вариант для небольшого проекта, требования к которому можно удержать в голове. Что хорошо в этом подходе:

·Вы получаете все плюсы предыдущего подхода

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

· "Забить" на требования. Что хорошего в этом подходе:

· Делать ничего не надо, тратить время не нужно. На этом плюсы заканчиваются!

Требования есть, но они неполные или некорректные. Что делать??

Это очень распространённая ситуация. Безответственные тестировщики пользуются ею, чтобы иметь оправдания плохому тестированию "а что я, у нас даже требований нормальных нет, я об этом не знал" и т.д. Если наша задача - качественный продукт, а не отмазки, давайте посмотрим, что мы можем сделать:

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

·Вы структурируете работу аналитика. Ему тоже тяжело, он не всегда может решить проблему "нет требований". Зато, он может решить конкретные баги - это значительно проще!

· Вы всегда можете оперировать количеством дефектов на требования - это мотивирует к их исправлению!

· Проводить тестирование требований. Причём, это наиболее полезно делать ДО разработки. Каким образом тестировать требования? Проверять их на понятность, непротиворечивость, полноту, тестируемость. А иногда и сразу делать по ним предложения "это лучше было бы сделать по-другому, вот так". Причём, для тестирования требований не обязательно их документирование! Если у вас принято передавать их из уст в уста, то это тоже можно тестировать! Что это даёт:

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

· Если мы заранее начинаем знакомиться с требованиями и анализируем их, то к моменту готовности кода мы уже хорошо понимаем, как его тестировать! А это тоже экономия времени.

Требования есть, ура! Надо ли что-то делать?

Редко, но такое тоже бывает. У нас есть требования, документированные или устные, возможно, полученные благодаря нам на первом или втором варианте. Что дальше?

Дальше важно оценивать тестовое покрытие. Чем вообще отличается тестирование от поиска дефектов? Поиск дефектов предназначен для заведения как можно большего количества багов, но при этом не гарантирует качество продукта! Что же такое тестирование? Это проверка, что весь функционал реализован, соответствует требованиям пользователя и готов к использованию на требуемых окружениях. Для этого нам надо не просто искать баги - нам надо оценивать состояние продукта!

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

Если у нас есть требования в задокументированном виде, мы можем сделать так называемую traceability matrix, или связать требования и тесты. Или же мы просто можем сделать табличку с перечнем требований, чтобы по каждому указывать статус работоспособности. Нет документированных требований? Всё равно можем сделать табличку на основании нашего знания о работе продукта:)

Истина #11: эффективно работая с требованиями, мы можем повысить эффективность и скорость разработки нашего продукта, принести пользу проекту и пропускать меньше дефектов! При этом, требования не обязательно должны быть кем-то документированы, при отсутствии документации мы можем сделать это сами!

Где подробнее узнать о работе тестировщиков с требованиями?

·В моей статье про работу с требованиями (полезнее для тест-менеджеров, но применимо на любом уровне ответственности)

·Статья на википедии про требования (даёт замечательный список характеристик требований, на соответствие которым их полезно тестировать)

До связи!

Выпуск #7: Что есть баг, или 5 школ тестирования

Привет,

Сегодня я хочу рассказать про 5 школ тестирования. Насколько мне известно, впервые информацию про них структурировал Bett Pettichord в своейпопулярной презентации, до этого информация про различные школы мелькала в блогах таких именитых тестировщиков, как Джеймс Бах, Рекс Блэк, Сэм Канер и многих других.

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

Что же это за школы, и чем они заслуживают наш интерес?

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

Дата добавления: 2015-05-28