Что же происходит в развитых процессах тестирования?
Тест-дизайн! То есть, проектирование тестов оптимальным образом. При этом, в формальном подходе они документируются, в неформальном не документируются, но сути это не меняет. Главное - их вдумчивое проектирование, а не наличие бумажек!
Как же они делают это магическое действие, проектирование тестов? В первую очередь, тестировщики исследуют продукт. Для этого чаще всего используются интеллект-карты, или 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.Иногда требования всё-таки есть, и в этом случае наша задача - контроль их реализации.
Давайте разберём все три пункта по отдельности.
Требований нет, что делать??
Требования есть всегда, иначе как бы программисты выполняли свою работу? Просто они могут передаваться из уст в уста, без документирования. И в этом нет ничего страшного, иногда этого достаточно. Но что действительно важно - так это общее понимание требований всеми участниками процесса. Представьте себе, что аналитик хочет одну кнопочку, разработчик решил реализовать другую, а тестировщик заводит баги, потому что ожидал третью. Звучит смешно? Как бы не так, это реалии разработки ПО :)
Варианты действий тестировщика в данной ситуации:
·Попробовать написать требования самостоятельно и согласовать с аналитиком или РМ'ом. Что хорошего в таком варианте:
·Вы занимаете проактивную, ответственную позицию и неизбежно растёте в глазах коллег :)
·Вы получаете то, что так важно в тестировании - требования!
|
|
|
·Вы помогаете успешному релизу продукта, так как без продуманных требований шансы на успех не велики
·Выяснить требования на общем собрании, так, чтобы все участники проекта имели общее понимание продукта. Для этого необходимо собрать всю проектную команду, подготовить вопросы, запереть в одной комнате и узнать ответы, убедившись, что у всех одинаковое понимание "что делать?". Это хороший вариант для небольшого проекта, требования к которому можно удержать в голове. Что хорошо в этом подходе:
·Вы получаете все плюсы предыдущего подхода
·Помимо этого, вы не тратите время на бумажки и документацию, которые не нужны в случае небольшого проекта.
·"Забить" на требования. Что хорошего в этом подходе:
·Делать ничего не надо, тратить время не нужно. На этом плюсы заканчиваются!
Дата добавления: 2018-02-28; просмотров: 765; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!