Когда все тестеры в вашей команде исчерпаны и все запланированные тесты выполнены, проводится подробный тест (также называемый полным тестом). Это метод проверки качества, при котором все сценарии или данные тестируются для тестирования. Более понятным образом, исчерпывающее тестирование означает, что в конце фазы тестирования не будет обнаружено необнаруженных сбоев.
За исключением тривиальных случаев, тестирование всего (все комбинации входов и предварительных условий) неосуществимо. Как тестировщики, мы часто говорим: «Ну, у меня никогда не было достаточно времени для тестирования». Даже если у вас есть все время в этом мире, у вас все еще не хватает времени для тестирования всех возможных комбинаций ввода и вывода.
Исчерпывающая стратегия тестирования
Тестирование — это не поиск ошибок!
Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?
7 принципов тестирования — в чем их смысл
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Что такое поиск ошибок?
Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.
Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.
Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?
Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.
Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.
Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.
Тестирование Программного Обеспечения — урок №3 — сообщения об ошибках
Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
- из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
- команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
- в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
- количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:
1. Анализ продукта и документирование тестов
Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
- Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
- Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
- Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.
Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.
2. Оценка тестирования
Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.
3. Обсуждение целей тестирования с командой
Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!
4. Понимание пользователей и их бизнес-процессов
- Как этот продукт используется?
- Зачем он вообще нужен, какие проблемы решает?
- Какая средняя квалификация у пользователей?
- В каких условиях работают пользователи? На каких окружениях, оборудовании?
5. Техническая квалификация и понимание архитектуры
Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.
Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт. Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!
Выводы
Очень многие разработчики не любят тестировщиков. И правильно делают!
Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!
Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.
И да пребудет с вами сила!
- тестирование
- поиск багов
- горе-тестировщики
- тестировщики-котики
Источник: habr.com
Лекция 7. Тестирование и отладка
Как показывает опыт программирования, несмотря на тщательное проведение этапов проектирования и использование современных технологий программирования, не удается разработать полностью безошибочную программу. Основными активными методами поиска и устранения ошибок являются тестирование и отладка. Тестирование — процесс выявления имеющихся в программе ошибок, а отладка — процесс их устранения.
При тестировании проверяется, работает ли программа и все ее ветви в соответствии со своей спецификацией. Для того чтобы убедиться в том, что программист правильно понимает функции программы, и обеспечить полный и эффективный контроль всех ее ветвей, заранее разрабатывается стратегия тестирования.
Особенности процесса тестирования программы состоят в том, что:
- отсутствует эталон программы, которому должны соответствовать все результаты тестирования проверяемой программы;
- принципиально невозможно создать тестовый набор для исчерпывающей проверки;
- отсутствуют формализованные критерии качества программ и процесса тестирования;
- необходимо создавать тесты, которые находят ошибки, а не демонстрируют правильность работы программы;
- необходимо привлекать для тестирования сторонних специалистов;
- необходимо избегать невоспроизводимых тестов.
- автономная разработка каждого физического модуля с имитацией вызывающего модуля и использованием модулей-заглушек;
- совместное редактирование связей уже проверенных модулей — комплексное тестирование.
Источник: studfile.net