Дошина, А. Д. Когда прекращать тестирование программ? Критерии работоспособности программ. Эвристики тестирования / А. Д. Дошина, В. В. Карлова, А. Е. Михайлова. — Текст : непосредственный // Молодой ученый. — 2015. — № 15 (95). — С. 54-56. — URL: https://moluch.ru/archive/95/21441/ (дата обращения: 19.06.2023).
Данная статья раскрывает понятие тестирования программного обеспечения, объясняет, для чего нужно тестирование, а также описывает наиболее интересные и эффективные способы тестирования программного обеспечения.
Одним из этапов создания программного обеспечения является его тестирование. Наверняка каждый разработчик в начале своего пути пытался выяснить, когда же процесс тестирования и отладки может быть завершен? В какой момент можно анализировать результаты и передавать проект в эксплуатацию?
Большинство разработчиков понимает, что программ без ошибок не бывает, но на определенном этапе тестирования возникает вопрос: «Стоит ли дальше искать ошибки, или можно оставить некоторые из них до следующего этапа разработки?».
Курсы тестировщиков онлайн. Урок 28. Когда заканчивать тестирование?
На сегодняшний день не существует такого метода тестирования, который бы позволил полностью обнаружить все дефекты и установить корректность функционирования исследуемого программного обеспечения.
Как говорил Эдгар Дейкстра (1970): «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие».
Ошибки бывают разные, и на поиск каждой ошибки уходит разное время. Зачастую, на полное тестирование программы просто не хватает времени, поэтому во всех режимах и со всеми параметрами оно трудно реализуемо.
Тестирование программного обеспечения — это процесс исследования, испытания программного продукта, для демонстрации разработчикам и заказчикам, что программа соответствует требованиям и (или) для выявления ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
За всю историю своего развития, процедура тестирования претерпела множество изменений, начиная от строго формализованного тестирования, которое использовалось для тестирования программ для нужд министерства обороны. В 1960-х внимание в основном уделялось полному тестированию, предполагающему полный проход всех алгоритмов с различными входными данными.
Позднее такое тестирование было признано невозможным. В 1970-х понятие тестирования определялось двойственно. С одной стороны, тестирование считалось успешным, когда программа демонстрировала корректную работу, но, с другой стороны, успешным считалось то тестирование, в результате которого были найдены некоторые ошибки в работе программы.
В 1980-е годы тестирование вышло на новый уровень. Тестированию подвергался не уже готовый продукт, а продукт в процессе всего цикла разработки. В это время появлялись первые инструменты для автоматизированного тестирования. В 1990-х начали появляться различные программные инструменты для поддержки процесса тестирования. В 2000-х появилось еще более широкая методология тестирования, которая предполагала максимизацию значимости всех этапов жизненного цикла программы.
Тестирование для дегенератов
Существует несколько подходов к тестированию, которые предлагают различные алгоритмы. Но в основном, это процесс творческий, который не всегда придерживается определенных правил.
Конечно, тестирование наиболее полезно на ранних этапах разработки проекта, так как это более экономично. Программа считается готовой к выпуску, когда устранены абсолютно все критические ошибки и ~85 % не критических ошибок. Считается, что дальнейшее тестирование экономически не целесообразно.
Так как у программного обеспечения (ПО) отсутствует эталон, к которому необходимо стремится, чтобы оно считалось полностью протестированным, то следует стремиться к некоторым уровням качества.
К таким уровням относятся:
— отсутствие остановок работы ПО;
— отсутствие синтаксических ошибок;
— выполнение функций ПО, описанных в техническом задании без ошибок;
— соответствие расчетных значений эталонным.
В тот момент, когда программное обеспечение соответствует всем вышесказанным уровням, оно считается протестированным и его можно передавать в эксплуатацию. Далее ПО будет передано на тестирование пользователям, которое будет продолжаться в течение всего времени пользования.
За все время существования программирования определилось несколько признаков, по которым принято производить тестирование программы: по объекту тестирования, по знанию системы, по степени автоматизации, по степени изолированности компонентов, по времени проведения тестирования, по признаку позитивности сценариев, по степени подготовленности к тестированию.
По уровням тестирования можно выделить несколько основных типов:
— модульное тестирование — тестируется минимальный компонент программы (класс, функция);
— интеграционное тестирование — тестируются межкомпонентные элементы;
— системное тестирование — тестирование всей системы на соответствие установленным требованиям;
— альфа-тестирование — штатные разработчики или потенциальные пользователи имитируют реальную работу с системой;
— бета-тестирование — распространение пробной версии программного обеспечения для большей группы лиц, с целью удостоверится в отсутствии ошибок.
Все технологии тестирования можно разделить на две большие группы: статическое и динамическое тестирование. В динамическом тестировании код исполняется, а в статическом — не выполняется. Здесь анализ программы происходит на основе исходного кода.
К наиболее интересным и эффективным техникам можно отнести тестирование белого ящика и тестирование черного ящика. Обе эти техники предполагают, что код исполняется, и разница состоит лишь в том, какой информацией владеет тестировщик.
При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения.
При тестировании чёрного ящика, тестировщик имеет доступ к программе только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования.
Так же эффективным во многих случаях может быть регрессионное тестирование. Эта технология тестирования позволяет подтвердить, что изменения, внесенные в программу при выпуске новой версии, не повлияли на работоспособность программы.
В некоторых случаях, тестировщики прибегают к тестовым скриптам. Тестовые скрипты пишутся для проверки компонентов, в которых высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.
Помимо технологий тестирования были разработаны несколько эвристик, которые предлагают ситуации для остановки тестирования. Эвристики — это быстрые, недорогие способы решения проблемы или принятия решения. Эвристики подвержены ошибкам, то есть они могут, как сработать, так и не сработать. Таких эвристик на данный момент существует 11 штук.
Каждая из них работает в определенном контексте, поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Рассмотрим их.
1. Эвристика «Время вышло!». Самая распространенная эвристика. Тестирование заканчивается, как только вышло отведенное на него время.
2. Эвристика «Мертвой лошади». Тестирование заканчивается, когда обнаруживается слишком много ошибок, и дальнейшее тестирование не имеет смысла.
3. Эвристика «Освежающей паузы» предполагает приостановку тестирования, когда стало скучно или пропало вдохновение. Так же пауза может возникнуть из-за появления ошибки большего приоритета.
4. Эвристика «Отсутствие продвижения». Любые тесты приводят к одним и тем же результатам.
5. Эвристика «Больше нет интересных вопросов». Все важные основные вопросы получили свои ответы. Используется обычно в дополнение с другими эвристиками.
6. Эвристика «Пиньяты». Тестирование прекращается в тот момент, когда возникает достаточно явная серьезная проблема.
7. Эвристика «Задание выполнено». Тестирование прекращается тогда, когда получены ответы на поставленные вопросы.
8. Эвристика «Отмена задания». К этой категории относится прекращение тестирование по требованию заказчика.
9. Эвристика «Зашел в тупик». Остановка тестирование происходит по причине того, что имеется блокирующая ошибка, которая не препятствует тестированию области программы. Проблема может исходить от недостатка оборудования или же от недостатка квалификации тестировщиков.
10. Эвристика «Привычного завершения». Тестирование завершается в соответствие с протоколом, задающим некоторое количество идей для тестирования или циклов тестирования.
11. Эвристика «Уклонения/безразличия». Такой вариант возможен в том случае, если тестировщикам не интересно как работает программа, или тестируемое ПО является первой версией, которую вскоре заменят.
Подводя итоги вышесказанному, тестирование программного обеспечения — это трудоемкий процесс, который не подвергается определенным правилам и не всегда следует по определенному алгоритму. Нельзя сказать, что для определенного типа программ больше подходит определенная технология тестирования. Для каждого определенного случая подбирается своя методика тестирования и свои эвристики остановки. Этот выбор зависит от многих критериев, таких как тип программного обеспечения, цели создания программного обеспечения, задачи, для выполнения которых создавалось данное программное обеспечение. Человек, занимающийся тестированием программного обеспечения должен обладать большим багажом знаний для эффективного и своевременного поиска ошибок.
1. Гленфорд Майерс, Том Баджетт, Кори Сандлер. Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. — М.: «Диалектика», 2012.
2. Канер Кем, Фолк Джек, Нгуен Енг Кек. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001.
3. Калбертсон Роберт, Браун Крис, Кобб Гэри. Быстрое тестирование. — М.: «Вильямс», 2002.
Основные термины (генерируются автоматически): программное обеспечение, тестирование, Эвристика, ошибка, технология тестирования, белый ящик, время, дальнейшее тестирование, тестирование программ, черный ящик.
Похожие статьи
Типовые задания при изучении студентами тестирования.
В ходе выполнения ряда лабораторных работ студент должен научиться производить тестирование программного обеспечения различными способами, основанными на принципе «белого ящика».
Исследование стратегий тестирования программного.
Бейзер Б. Тестирование “черного ящика” Технология функционального тестирования программного обеспечения.
Типовые задания при изучении студентами тестирования программного обеспечения по принципу «белого ящика».
Типовые задачи по тестированию программного обеспечения.
Дисциплина «Тестирование программного обеспечения», изучаемая студентами бакалавриата, обучающимися по направлению «Программная инженерия», является весьма актуальной.
Автоматизация процесса тестирования программного.
Автоматизация процесса тестирования программного обеспечения при использовании тестирования условий.
Целью семейства способов тестирования условий [1, 3] как одного из подходов к тестированию ПО, основанных на принципах «белого ящика», является.
Особенности тестирования программного обеспечения.
Дисциплина «Тестирование программного обеспечения», изучаемая студентами бакалавриата по направлению «Программная инженерия», весьма актуальна, поскольку тестирование является важнейшей составляющей поддержки качества программного.
Достоинства и недостатки современных видов тестирования.
Тестирование играет жизненно важную роль в разработке качественного программного обеспечения. Тем не менее, во многих компаниях, занимающихся разработкой ПО, процессы тестирования недостаточно организованы.
Технология интерактивного тестирования Plickers
В статье рассматриваются возможности сервиса Plickers, позволяющие реализовать быструю обратную связь от класса (аудитории родителей, слушателей), мобильное голосование и фронтальные опросы во время учебного занятия по пройденному или текущему материалу.
Особенности изучения способа тестирования базового пути.
Тестирование базового пути — это способ тестирования, который основан на принципе «белого ящика». Автор этого способа — Том МакКейб (1976 г.). Следует отметить, что при использовании тестирования «белого ящика» как одного из принципов тестирования.
Технология тестирования программных модулей
Белый ящик — это техника тестирования, которая позволяет проверить внутреннюю структуру программы, ее логику и корректность работы. Проводя тестирование Белого ящика, специалист руководствуется определенными знаниями программного кода.
- Как издать спецвыпуск?
- Правила оформления статей
- Оплата и скидки
Источник: moluch.ru
Тестирование ПО — Введение
Тестирование — это процесс оценки системы или ее компонентов (компонентов) с намерением определить, удовлетворяет ли она указанным требованиям или нет. Простыми словами, тестирование выполняет систему, чтобы идентифицировать любые пробелы, ошибки или отсутствующие требования в противоположность фактическим требованиям.
Согласно стандарту ANSI / IEEE 1059, тестирование можно определить как: процесс анализа элемента программного обеспечения для обнаружения различий между существующими и требуемыми условиями (дефектами / ошибками / ошибками) и для оценки характеристик элемента программного обеспечения.
Кто проводит тестирование?
Это зависит от процесса и заинтересованных сторон проекта (ов). В ИТ-индустрии крупные компании имеют команду, отвечающую за оценку разработанного программного обеспечения в контексте данных требований. Кроме того, разработчики также проводят тестирование, которое называется Unit Testing . В большинстве случаев следующие специалисты участвуют в тестировании системы в пределах своих соответствующих возможностей:
- Тестер программного обеспечения
- Разработчик программного обеспечения
- Руководитель проекта / менеджер
- Конечный пользователь
Различные компании имеют разные обозначения для людей, которые тестируют программное обеспечение на основе их опыта и знаний, таких как Software Tester, Software Quality Assurance Engineer, QA Analyst и т. д.
Невозможно протестировать программное обеспечение в любое время в течение его цикла. Следующие два раздела указывают, когда тестирование должно быть начато и когда его завершить во время SDLC.
Когда начинать тестирование?
Раннее начало тестирования снижает затраты и время на доработку и создает безошибочное программное обеспечение, которое доставляется клиенту. Однако в жизненном цикле разработки программного обеспечения (SDLC) тестирование может быть начато с этапа сбора требований и продолжено до развертывания программного обеспечения.
Это также зависит от используемой модели разработки. Например, в модели «Водопад» формальное тестирование проводится на этапе тестирования; но в инкрементной модели тестирование выполняется в конце каждого приращения / итерации, и все приложение тестируется в конце.
Тестирование выполняется в разных формах на каждой фазе SDLC:
- На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.
- Рассмотрение дизайна на этапе проектирования с целью улучшения дизайна также рассматривается как тестирование.
- Тестирование, выполняемое разработчиком по завершении кода, также классифицируется как тестирование.
Когда прекращать тестирование?
Трудно определить, когда прекратить тестирование, поскольку тестирование является бесконечным процессом, и никто не может утверждать, что программное обеспечение проверено на 100%. Для прекращения процесса тестирования необходимо учитывать следующие аспекты:
- Сроки тестирования
- Завершение выполнения тестового примера
- Завершение функционального и кодового покрытия до определенной точки
- Уровень ошибок падает ниже определенного уровня, и выявлены ошибки с высоким приоритетом
- Решение руководства
Проверка и проверка
Эти два термина очень сбивают с толку для большинства людей, которые используют их взаимозаменяемо. В следующей таблице показаны различия между верификацией и валидацией.
| Верификация | Проверка |
| Верификация затрагивает озабоченность: «Правильно ли вы строите?» | Валидация затрагивает озабоченность: «Вы строите правильную вещь?» |
| Обеспечивает, чтобы программная система отвечала всем функциональным возможностям. | Обеспечивает соответствие функциональности предполагаемому поведению. |
| Сначала выполняется проверка, включая проверку документации, кода и т. д. | Валидация происходит после проверки и в основном включает проверку всего продукта. |
| Сделано разработчиками. | Выполнены тестерами. |
| Он имеет статические действия, так как он включает сбор отзывов, пошаговых инструкций и проверок для проверки программного обеспечения. | Он имеет динамические действия, так как включает в себя выполнение программного обеспечения с учетом требований. |
| Это объективный процесс, и для проверки программного обеспечения не требуется никакого субъективного решения. | Это субъективный процесс и включает субъективные решения о том, насколько хорошо работает программное обеспечение. |
Источник: unetway.com
Когда заканчивается тестирование программы
Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – есть ли предел совершенству? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?
Причина для остановки: «Сроки поджимают! Время – деньги!»
Часто на проекте есть четко определенные сроки, которые заказчик не всегда готов передвинуть. В этом случае команда «заканчиваем тестирование!» зависит именно от установленных сроков, и это важный критерий. Да, такой сценарий нельзя назвать лучшим (так как времени всегда катастрофически не хватает для полной проверки, и часто страдает качество), но он тоже возможен.
Пример из практики. Вспоминается ситуация, когда из-за жестких сроков пострадало качество продукта. Тестировался интернет-магазин хозтоваров, и вместе с новой акционной скидкой только для зарегистрированных клиентов был внедрен баг: невозможность активировать несколько действующих на тот момент акций. Таким образом, релиз превратился в «релиз плюс еще пару напряженных дней баг-фикса». Наверное, гораздо лучше было подвинуть жесткие рамки на день-два и дать возможность дотестировать новый функционал… но в жизни встречаются разные ситуации.
Вывод. Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).
Причина для остановки: «Это не конечная, а промежуточная»
Бывает, что в ходе тестирования нужно сделать вынужденную остановку, так как «что-то» критично блокирует оптимальную оценку тестируемого объекта, и из-за этого в дальнейшем может «протухнуть» вся система проверки. В таком случае лучше остановиться и дождаться решения проблемы.
Пример из практики. Тестировалось довольно крупное медицинское программное обеспечение. На тестовом стенде не было возможности проверить в полном объеме новый функционал (отправку писем клиентам при заполнении формы и данных личного кабинета клиента).
Задача была довольно обширной и затрагивала многие аспекты: активацию отдельных разделов при полной загрузке документов, ограничения в доступе к разделам при определенной степени заполнения профиля и другие. На вопрос перед релизом «все ли проверено и можно ли заканчивать тестирование?» однозначный ответ дать было просто невозможно: проверка частично блокировалась из-за невозможности проверить факт получения части писем на тестовой среде.
В итоге при релизе на стороне клиента вылезли критические ошибки. Клиенту не поступали нужные уведомительные письма, а потому он не мог получить и полный доступ к своему профилю. Во избежание появления подобных ситуаций было найдено следующее решение: после доработки стали доступны опции отправки и получения писем на тестовом стенде, что позволило в дальнейшем проверять эту часть достаточно важного функционала. Включение этих проверок во все последующие прохождения регресса дало возможность более оптимально оценивать готовность продукта перед выпуском на клиентскую часть.
Вывод. Анализ ошибок позволил сделать верные выводы и устранить все блокирующие моменты. И все-таки, в подобной ситуации работа над оптимизацией средств и инструментов тестирования по итогу уже выявленных ошибок вряд ли может считаться хорошим вариантом. Несомненно, гораздо более уместной и правильной была бы остановка процесса тестирования и доработка изначально неполного функционала тестовой среды для предотвращения появления критических моментов уже на клиентской части.
Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»
Правильно ли исправлять баги прямо по ходу проверки, которая при этом не прерывается? Логика подсказывает, что процесс нужно остановить и начать с самого начала после внесения корректировки, так как любое исправление ошибки может повлечь за собой появление еще десятка новых.
Пример из практики. Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.
Вывод. В таких ситуациях разработчику важно своевременно сообщить о своих исправлениях тестировщику для того, чтобы тот остановил тестирование и повторно прошел тест-кейсы – все или только самые критичные и высокого приоритета (если времени остается не так уж и много). Это поможет избежать в дальнейшем неразберихи в вопросе: а откуда взялись новые дефекты в продукте, и кто за них отвечает?
Причина для остановки: «Поступил приказ отступать!»
Случается, что заказчик буквально на последнем этапе приостанавливает проверку. На это может быть масса причин: появление более важной задачи или функционала, который требует дальнейшего уточнения, переоценка приоритетов релиза, пересмотр плана на текущий момент. Наша задача при этом – приостановить процесс, но ничего не забыть!
Пример из практики. Случалось, что практически полностью протестированный релиз откладывался. Казалось бы, все готово – тщательно протестированы все блоки, сделаны все задачи, – и можно отдавать готовый продукт на радость пользователю, но заказчик вдруг решает, что лучше все сделать совершенно по-другому, а практически уже готовый релиз временно нужно остановить. Минусом такой ситуации является потраченное время тестировщика, плюсом – написанные тест-кейсы, которые могут быть использованы для проверки функционала другого ПО.
Вывод. Для тестировщика в таком случае важно написать качественные тест-кейсы, с которыми можно будет работать в дальнейшем либо на аналогичных задачах, либо (в случае возобновления работы) по отмененному/отложенному релизу.
Причина для остановки: «Все, устал, хватит!»
Остановка может произойти и просто из-за того, что напряжение достигло своего пика. Желание сделать как можно больше за максимально возможное время иногда негативно сказывается на результатах работы.
Пример из практики. На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела.
В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!
Вывод. В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».
Причина для остановки: «Есть сомнения? Остановись!»
Перед выходом каждого релиза тестировщик, оценивая проделанную работу и пройденный набор тест-кейсов, подводит итог: а все ли протестировано? Конечно, естественным состоянием будет желание продолжить процесс проверки, которое не всегда соответствует фактору времени. И все-таки обоснованные сомнения нужно по крайней мере озвучить. Даже если баг был «пойман» на последнем этапе, и его исправление задержит весь процесс релиза, – ни в коем случае нельзя оставлять ошибку без внимания, лучше остановить запущенный механизм и дать время на корректировку.
Пример из практики. В моем опыте были ситуация, когда ошибка обнаружилась уже на последних шагах (можно даже сказать, на последних минутах) регрессионного тестирования. Был ли это недочет тестировщика (то есть, мой)? Да, и это стало хорошим «пинком» для дальнейшей работы над своими ошибками. Но баг нужно было искоренять.
Задачу «выкинули» из релиза для доработки, сам релиз состоялся довольно успешно. Не забывайте: заказчик скорее оценит качество проверки, чем соблюдения сроков без сохранения качества.
Вывод. Каждый этап процесса тестирования важен. Неверная проработка материала или неполное покрытие задачи тест-кейсами может стать причиной того, что тестировщик упустит важный и критический баг. На каком бы этапе тестирования это не обнаружилось – важно понимать, что в таких случаях необходимо остановиться, оценить ситуацию и принять решение о дальнейшем плане работ!
Причина для остановки: «По моему хотению – остановитесь!»
В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).
По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»
Для тестировщика халатное отношение к процессу просто недопустимо. Все недочеты в итоге становятся явными, что в конечном итоге приводит к плачевным результатам.
Пример из практики. У меня и моих коллег, к счастью, таких ситуаций никогда не возникало: мы любим свою работу и с уважением относимся к конечным пользователям (ведь наши ошибки влияют на их опыт взаимодействия с продуктом). Надеюсь, подобного никогда и не случится. Главное – не забывать, что такое возможно, и избегать подобных случаев.
Вывод. Останавливать тестирование лишь по желанию тестировщика нельзя, каждая остановка должна быть обоснована. Решение об остановке процесса будет закономерным лишь в том случае, если оптимально и позитивно пройденным и тщательно проработанным оказывается целый набор параметров: написан полный объем тест-кейсов по задаче, правильно расставлены приоритеты для оценки времени в случае срочных или быстрых проверок, все задачи полностью проанализированы и сверены с техническими требованиями еще на начальных этапах ознакомления, все учтено на этапе планирования релиза.
И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»
При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам.
Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!
Пример из практики. К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой.
Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось. ). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.
Вывод. Для получения хорошего результата важно учитывать в работе все факторы. Оценка и анализ задачи, написание тест-кейсов для ее покрытия, расчет времени и максимальная внимательность гарантируют положительные результаты в работе.
Финал
Подводя итоги, можно сказать, что последний сценарий – это идеальный вариант остановки тестирования: в нем сочетаются верное планирование, детальное тестирование и итоговая положительная приемочная часть. В остальных случаях остановки происходят из-за ошибок тестировщика, по желанию заказчика, недостаточно продуманного плана тестирования, неверного расчета времени или просто из-за лени (кстати, недопустимого в нашей профессии качества).
Поэтому и остановки в таких случаях не влекут за собой того конечного положительного результата, которого всегда хочется добиться. В данной ситуации важно сделать правильные выводы и вычленить причину основной ошибки. Как правило, это неверное планирование времени, боязнь спросить разработчика о готовности исправлений (то есть, плохо налаженное общение между разработчиком и тестировщиком) и халатное написание тест-кейсов из-за неполного ознакомления со спецификациями и требованиями. Выявив слабые места на проекте или в личных качествах, можно приступить к проработке плана дальнейшей более результативной работы.
Для этого всегда необходимо учитывать основные критерии: условия и пожелания заказчика, установленные временные рамки и степень покрытия тест-кейсами требований, указанных и описанных в задаче. Каждый пункт должен быть четко проработан и обговорен как с заказчиком, так и с разработчиком. Тестировщик должен представлять объем работ: какое тестирование можно успеть осуществить в обозначенные сроки, сколько тест-кейсов потребуется, до какого момента допускаются баг-фиксы, когда начинается код фриз и допускает ли найденное количество багов сам выпуск продукта.
Конечно, каждый проект имеет свои особенности. Невозможно найти единый правильный эталонный метод решения. И все-таки учет указанных выше основных критериев приведет к тому, что выпускаемый продукт будет максимально соответствовать поставленным требованиям, а процесс и остановка тестирования будут понятны и закономерны.
Источник: quality-lab.ru