Исправление ошибок наиболее затратное на каких этапах

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

Определение заболевания

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

Передача изображения от сетчатки к зрительному анализатору в головном мозге происходит по своеобразному «кабелю», состоящему из множества нервных волокон и упакованному в «изоляцию». Толщина зрительного нерва не более 2 мм, однако в нем находится более миллиона волокон. Каждый участок изображения соответствует определенной их части, и когда некоторые из них перестают функционировать, в воспринимаемой глазом картинке появляются «немые зоны» (нарушение изображения).

При отмирании клеток нервных волокон они постепенно замещаются соединительной тканью либо нервной вспомогательной тканью (глией), которая в норме призвана защищать нейроны.

Виды

В зависимости от причинных факторов различают два вида атрофии зрительного нерва:

Классификацию проводят также по локализации поражения:

Также различают следующие виды атрофии: начальную, частичную, полную и неполную; одностороннюю и двустороннюю; стационарную и прогрессирующую; врожденную и приобретенную.

Причины возникновения

Частота различных патологических процессов в зрительном нерве составляет всего 1-1,5%, причем в 19-26% из них болезнь заканчивается полной атрофией и неизлечимой слепотой.

Причиной развития атрофии зрительного нерва может стать любое заболевание, следствием которого становится отек, сдавливание, воспаление, повреждение нервных волокон либо повреждение сосудистой системы глаз:

Какой бы ни была причина начала атрофии зрительного нерва, нервные волокна погибают безвозвратно, и главное при этом – оперативно провести диагностику, чтобы вовремя затормозить процесс.

Симптомы

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

Проявление симптомов может протекать в зависимости от остроты поражений несколько дней или месяцев, однако без своевременного реагирования неизменно приводит к полной слепоте.

Возможные осложнения

Диагноз «атрофия зрительного нерва» должен быть поставлен как можно раньше, в противном случае потери зрения (частичные или полные) неизбежны. Иногда заболевание поражает только один глаз – в этом случае последствия не столь тяжелы.

Рациональное и своевременное лечение заболевания, ставшего причиной атрофии, позволяет в ряде случаев (не всегда) сохранить зрение. Если диагноз поставлен на стадии уже развившейся болезни, прогноз чаще всего неблагоприятный.

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

Диагностика

Целенаправленное офтальмологическое обследование – первый обязательный шаг при подозрении на заболевание. Помимо этого, может потребоваться консультация нейрохирурга или невролога.

Для выявления атрофии зрительного нерва могут проводиться следующие виды обследований:

Для уточнения диагноза и дополнительных данных возможно проведение исследований: КТ, магнитно-ядерный резонанс, лазерная допплерография.

Лечение

При частичном повреждении нервных волокон лечение необходимо начинать быстро и интенсивно. В первую очередь усилия врачей направляются на устранение причины патологического состояния, чтобы остановить прогрессирование заболевания.

Медикаментозная терапия

Поскольку восстановление погибших нервных волокон невозможно, проводятся терапевтические мероприятия, призванные остановить патологический процесс всеми известными средствами:

• Сосудорасширяющие: Никотиновая кислота, Но-шпа, Дибазол, Эуфиллин, Компламин, Папаверин и др. Применение этих средств помогает стимулировать кровообращение;
• Антикоагулянты: Гепарин, Тиклид. Препараты препятствуют загущению крови и образованию тромбов;
• Биогенные стимуляторы: Стекловидное тело, Экстракт алоэ, Торфот. Усиливают метаболизм в нервных тканях;

Гепариновая мазь используется при лечении артофии зрительного нерва

• Витамины: Аскорутин, B1, B6, B2. Являются катализаторами большинства биохимических реакций, происходящих в тканях глаз, так же, как аминокислоты и ферменты;
• Иммуностимуляторы: Женьшень, Элеутерококк. Необходимы для стимуляции процессов регенерации и подавления воспаления при инфекционных поражениях;
• Гормональные средства: Дексаметазон, Преднизолон. Применяются при отсутствии противопоказаний для снятия симптомов воспаления;
• Улучшающие работу ЦНС: Эмоксипин, Ноотропил, Кавинтон, Церебролизин, Фезам.

Дексаметазон используют при лечении артофии зрительного нерва

В каждом конкретном случае лечение назначается индивидуально под контролем лечащего врача.

При отсутствии противопоказаний дополнительный эффект может быть достигнут использованием иглорефлексотерапии, а также методов физиотерапевтического лечения:

Такие процедуры могут оказать положительный эффект при неполной утрате нервными клетками своей функциональности.

Хирургически

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

Различные методики по хирургическому лечению с успехом практикуются в клиниках России, Израиля и Германии.

Народные средства

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

Использовать в лечении народные средства следует только после консультации офтальмолога, поскольку большинство растительных компонентов обладают аллергенным действием и могут оказывать неожиданный эффект при наличии некоторых системных патологий.

Профилактика

Для того чтобы избежать атрофии зрительного нерва, стоит уделять внимание мерам профилактики не только глазных, но и системных заболеваний:

• Своевременно лечить глазные и системные инфекционные болезни;
• Предупреждать глазные и черепно-мозговые травмы;
• Делать профилактические осмотры в онкологической клинике;
• Ограничить употребление или исключить из своей жизни алкоголь;
• Взять под контроль артериальное давление.

Видео

Выводы

Атрофия зрительного нерва – почти неизлечимое на поздних стадиях заболевание, которое грозит пациенту полной слепотой. Однако частичная атрофия может быть приостановлена, и главным направлением перед разработкой медицинской тактики должна стать обширная диагностика – ведь именно она позволит установить причину изменений и попытаться их остановить.

Поэтому постарайтесь уделить усиленное внимание не только здоровью глаз, но и всего организма. Ведь в нем все взаимосвязано, и болезни сосудов или нервов могут оказать влияние на качество зрения.

Как проходит восстановление после лазерной коррекции зрения

Вся основная информация воспринимается человеком с помощью зрения: оттенки, формы предметов и их отдаленность. Если зрение ухудшается, эта способность ослабевает и постепенно сходит на нет. И, чем хуже человек видит, тем хуже качество его жизни в целом. Этим и объясняется огромный спрос на процедуру по коррекции зрения.

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

• беременность,
• глаукома,
• катаракта,
• изменения глазного дна,
• сахарный диабет,
• артрит,
• СПИД и др.

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

Послеоперационный период

После данной операции необходимо следовать всем инструкциям лечащего врача, в том числе:

1. Не прикасаться к глазу до первого после выхода из клиники осмотра.
2. Первые несколько дней после операции нельзя умываться и принимать ванну.
3. Две недели не подвергать глаза яркому освещению и не находиться на холодном или горячем воздухе.
4. Полностью исключить применение косметических средств.
5. Нельзя сильно тереть прооперированный глаз.
6. Около 3-4 недель не посещать солярий, сауну или бассейн.
7. Применять капли в точном соответствии с графиком.
8. Полностью исключить алкоголь!
9. Перед процедурой закапывания капель руки должны быть чистыми.
10. Нельзя носить одежду с тесным горлом.
11. Беречь глаз от любых механических травм.
12. Необходимо избегать прямых солнечных лучей.
13. В солнечную погоду нужно всегда носить темные очки.
14. Запрещается купание в водоеме до завершения лечения.

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

Возможные осложнения

Любое операционное вмешательство имеет свои осложнения. Лазерная коррекция — не исключение. Однако, почти все они излечимы.

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

1. Недостаточная или большая близорукость или дальнозоркость. Даже очень тщательная подготовка не гарантирует отсутствия осложнений.
2. Изменившееся положение лоскута либо его полная потеря. Обычно это происходит во время проведения процедуры LASIK или после нее: из-за прикасания к глазу, из-за плохого соединения роговицы с лоскутом либо при механической травме глаза. Исправить это можно, возвратив лоскут в необходимое положение и прикрыв его линзой, либо наложив несколько швов. В данном случае существует опасность ухудшения полученного зрения. Если произошла потеря лоскута, восстановление проходит намного дольше.
3. Смещение центра лазером. Это возможно, если пациент сместил взгляд во время процедуры. Поэтому, выбирая клинику, нужно узнать какое оборудование в ней используется. Новейшее оборудование имеет специальную систему, следящую за каждым движением глаза и быстро останавливается при любом, даже самом малейшем движении. Большое смещение способно ухудшить зрение и вызвать двоение.
4. Дефекты эпителия. Обычно возникает во время процедуры LASIK и проявляется в ощущении постороннего предмета в глазу, сильной слезоточивости и боли при ярком освещении. Продолжается примерно около пяти дней.
5. Помутнение роговицы глаза. Может появиться исключительно при ФРК из-за возможного развития в роговице соединительной ткани из-за появившегося воспаления. Данная проблема решается с помощью шлифовки роговицы лазером.
6. Повышенная боязнь света. Возможна после каждой операции и исчезает сама примерно через один год.
7. Различное зрение в зависимости от времени суток. Встречается крайне редко, адаптируется через определенное время.
8. Возникновение инфекции. Также встречается очень редко. Возможно в случае несоблюдения необходимых инструкций после операции, также из-за недостаточного иммунитета или имеющейся инфекции в организме до проведения операции. Встречается примерно у 5% пациентов и продолжается до года. Лечится с помощью специальных капель.
9. Двоение в глазах. Также является редким явлением.

Материал по теме: Как избежать осложнений и побочных эффектов

Сроки восстановления в зависимости от типа операции

Существует несколько способов лазерной коррекции зрения, что объясняет разную продолжительность реабилитации после операции.

Фоторефрактивная кератэктомия (ФРК) — самая первая из всех лазерных методов коррекции. После данной операции роговица глаза восстанавливается в течении трех суток. Процесс довольно неприятный, так как возможно появление новой оптической кривизны. В случае необходимости проведения коррекции на оба глаза, оперировать второй можно только после полного восстановления первого глаза.

Лазерный кератомилез (LASIK). Данная методика дает возможность проведения операции на оба глаза в один день. Восстановление после нее происходит без какого-либо дискомфорта и продолжается около 24 часов. Существует еще один вид ЛАСИК: когда отделяется только эпительный слой роговицы, из-за чего не затрагиваются более глубокие ее слои. Это значительно снижает риск возможных осложнений.

Каждый из методов назначается врачом строго индивидуально, в зависимости от показаний.

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

Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.

Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software ». По этому поводу мы с Джеймсом устроили транспективную беседу . Колонку вы можете найти . Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.

Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

В общем, сейчас я расскажу все эвристики, которые мы нашли. Я подчеркиваю, что эти эвристики для остановки являются именно эвристиками
. Эвристики – это быстрые, недорогие способы решения проблемы
или принятия решения
. Эвристики подвержены ошибкам
, то есть они могут как сработать, так и не сработать. Эвристики недостаточно абстрактны , они могут перекрываться и пересекаться друг с другом. Также эвристики зависят от контекста
, поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Ниже я перечислил эвристики и для каждой из них указал некоторые вопросы, при помощи которых можно проверить правомочность её использования.

1. Эвристика
«Время
вышло
!»
. Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.

Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не
был
ли
срок
искусственным
, произвольным
? Будет
ли
выполняться
дополнительная
разработка
, которая
потребует
дополнительного
тестирования
?

Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – ? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?

Причина для остановки: «Сроки поджимают! Время – деньги!»

Часто на проекте есть четко определенные сроки, которые заказчик не всегда готов передвинуть. В этом случае команда «заканчиваем тестирование!» зависит именно от установленных сроков, и это важный критерий. Да, такой сценарий нельзя назвать лучшим (так как времени всегда катастрофически не хватает для полной проверки, и часто страдает качество), но он тоже возможен.

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

Вывод.
Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).

Причина для остановки: «Это не конечная, а промежуточная»

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

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

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

Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»

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

Пример из практики.
Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.

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

Причина для остановки: «Поступил приказ отступать!»

Случается, что заказчик буквально на последнем этапе приостанавливает проверку. На это может быть масса причин: появление более важной задачи или функционала, который требует дальнейшего уточнения, переоценка приоритетов релиза, пересмотр плана на текущий момент. Наша задача при этом – приостановить процесс, но ничего не забыть!

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

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

Причина для остановки: «Все, устал, хватит!»

Остановка может произойти и просто из-за того, что напряжение достигло своего пика. Желание сделать как можно больше за максимально возможное время иногда негативно сказывается на результатах работы.

Пример из практики.
На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела. В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!

Вывод.
В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».

Причина для остановки: «Есть сомнения? Остановись!»

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

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

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

Причина для остановки: «По моему хотению – остановитесь!»

В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).

По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»

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

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

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

И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»

При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам. Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!

Пример из практики.
К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой. Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось?!!!). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.

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

Финал

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

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

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

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

Читайте также: CASE -технологии, как новые средства для проектирования ИС. CASE — пакет фирмы PLATINUM, его состав и назначение. Критерии оценки и выбора CASE — средств. Iгруппа – Критерии основанные на дисконтированных оценках, т.е учитывают фактор времени:NPV,PI, IRR,DPP. PR в государственных структурах и ведомствах. PR в финансовой сфере. PR в коммерческих организациях социальной сферы (культуры, спорта, образования, здравоохранения) SCADA-система. ОРС. Организация взаимодействия с контроллерами. Автобус как средство передвижения. Организация автобусных туров, их география, известные туроператоры. Автоматизированные информационные системы и технологии в предприятиях и организациях различных организационных форм. Администрация муниципального образования как организация. Актерское мастерство и организация представлений в русской театральной культуре 19 века.

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

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

Кроме того, конкретные процессы тестирования должны быть ориен­тированы на конкретные этапы разработки. Это сосредотачивает каждый процесс тестирования на каком-либо шаге перевода, в результате чего фик­сируется определенный класс ошибок.

Соотношение между процессами разработки и тестирования.

Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.

Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры от­дельной программы.

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

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

Процесс тестирования завершают испытания ПО. Испытания позволя­ют проверить полноту решения функциональных задач, их качество и соот­ветствие ПО технической документации.

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

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

Существует несколько категорий тестов, каждая из которых направле­на на проверку определенных целей. К ним относятся тестирование полно­ты реализации, тестирование на предельных объемах, тестирование на пре­дельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совмес­тимости, тестирование надежности, тестирование восстановления, тестиро­вание удобства обслуживания, тестирование удобства установки и тестиро­вание документации.

Тестирование полноты реализации является наиболее очевидным ви­дом тестирования системы, который заключается в проверке выполнения каждого пункта исходного документа. Процедура проверки состоит в по­следовательном просмотре исходного документа — предложение за предло­жением. Если предложение содержит конкретную задачу, то определяют, выполняет ли программа эту задачу.

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

Тестирование на предельных нагрузках обусловлено тем, что потреб­ность в ресурсах памяти и быстродействии в процессе решения задачи на ЭВМ значительно изменяется в зависимости от состава объема исходных данных. При высокой интенсивности ввода исходных данных может нару­шаться временной баланс между длительностью решения совокупности задач ПО в реальном времени и реальной производительностью ЭВМ при решении этих задач. Цель тестирования на предельных нагрузках пока­зать, что ПО не удовлетворяет целям в области эффективности.

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

1. Можно ли приспособить разработанный интерфейс для информи­рования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
2. Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
3. Понятна ли диагностика ошибок?
4. Проявляет ли все множество пользовательских интерфейсов посто­янство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
5. Содержит ли система опции, число которых чрезмерно или исполь­зование которых маловероятно?
6. Выдает ли система какие-либо подтверждения на все входные со­общения?
7. Легко ли и приятно ли использовать ПО?

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

Тестирование конфигурации оборудования обусловлено тем, что опе­рационные системы, СУБД и коммуникационные системы должны поддер­живать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы прове­рить ПО на каждой из них. Однако программу следует тестировать по край­ней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необ­ходимо тестировать все возможные его конфигурации.

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

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

Для операционной системы, СУБД и средств телекоммуникации часто определяется, как система должна восстанавливать свою работоспособность после программных ошибок, неисправностей аппаратуры и ошибок в дан­ных. При тестировании системы требуется показать, что эти функции не выполняются. Для этого служит тестирование восстановления. Для этого можно намеренно ввести в систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры можно промоделировать. Ошибки в данных (помехи в линиях связи или неправильные значения указателей в базе данных) можно намеренно соз­дать или промоделировать.

В исходном документе иногда формируются специальные цели удоб­ства обслуживания или сопровождения ПО. Они могут определять средства обслуживания, которыми должно снабжаться ПО (например, программы выдачи дампов памяти, программы диагностики и т.п.), среднее время на­хождения ошибки, процедуры, связанные с сопровождением, и качество до кум стации о внутренней логике программы. Естественно, все эти цели должны быть протестированы. Для этого применяется тестирование удобств обслуживания.

Цель тестирования удобства установки — показать, что не удовлетво­ряются цели по части настройки ПО на конкретные условия эксплуатации.

В проверку системы входит и проверка точности пользовательской до­кументации. Большая часть этой проверки происходит при определении правильности представления предшествующих тестов системы. Кроме это­го, пользовательская документация должна быть подвергнута инспекции на предмет ее точности и ясности, аналогично инспекциям исходного текста. Любые примеры, приведенные в документации, должны быть оформлены как тест и проверены на ПО.

Критерии завершения тестирования.
При проведении тестирования встает вопрос о том, когда следует за­кончить тестирование программы, поскольку не представляется возможным определить, является ли выявленная ошибка последней.

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

Оба эти критерия недостаточно точны и логичны, так как первый кри­терий не содержит оценки качества тестирования и ему можно удовлетво­рить, ничего не делая, второй же не зависит от качества тестовых наборов данных.

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

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

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

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

Зависимость количества ошибок от продолжительности тестирования.

Из примера видно, что если время тестирования велико и с увеличени­ем времени тестирования число ошибок растет, то, естественно, тестирова­ние следует продолжить. Если в процессе тестирования в определенный момент наступило снижение числа выявления ошибок, если число выявлен­ных ошибок постепенно стремится к нулю или достигло нуля, то понятно, что процесс тестирования можно завершить.

Однако этот критерий тоже недостаточно эффективен, поскольку нет никакой уверенности в том, что в последнем случае в дальнейшем не после­дует увеличения числа обнаруживаемых ошибок.

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

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

Другой способ получения такой оценки основан на статических сред­них величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени заверше­ния кодирования (до проведения сквозного просмотра или инспекции) со­ставляет примерно 4 — 8 на 100 операторов программы.

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

Если в программу внесено случайным образом S ошибок, при проверке обнаружено n+V ошибок (n – число найденных собственных ошибок; V – число найденных внесенных ошибок), то предполагаемое число первона­чально находящихся в программе собственных ошибок может быть рассчитано по формуле: .

Например, при обнаружении 20 собственных и 10 привнесенных оши­бок, при общем числе первоначально внесенных ошибок, равном 25, значе­ние N=25*20/10 = 50; т.е. на данном этапе предполагается, что в про­грамме имелось 50 собственных ошибок и тестирование должно быть про­должено.

Оценку числа N можно проводить после каждого нового обнаружения ошибок.

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

где k — предполагаемое число собственных ошибок, S — число внесенных ошибок, n — число обнаруженных собственных ошибок.

Например, если утверждать, что в программе нет ошибок (k=0), и при внесении в программу 6 ошибок все они были обнаружены, а собственные ошибки обнаружены не были, то C=6/(6 + 0 + 1)=0,86. С другой сто­роны, чтобы достичь уровня доверия в 0,98 в программу необходимо ввести 39 ошибок: C=39/(39 + 0 + 1)=0,98.

Модель Миллса не лишена ряда недостатков, самые существенные из которых — это необходимость внесения искусственных ошибок (этот про­цесс плохо формализуем) и достаточно вольное допущение величины k (число собственных ошибок), которое основывается исключительно на интуиции человека, проводящего оценку, т.е. допускает большое влияние субъективного фактора.

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

В процессе тестирования каждая из групп фиксирует все найденные ею ошибки. При оценке числа оставшихся в программе ошибок результаты тестирования обеих групп собираются и сравниваются.

Получается, что первая группа обнаружила N 1 ошибок, вторая – N 2 ошибок, а N 12 — это ошибки, обнаруженные обеими группами.

Если обозначить через N неизвестное количество ошибок, присутст­вующих в программе до начала тестирования, то можно эффективность тестирования каждой из групп определить как

Предполагая, что возможность обнаружения всех ошибок одинакова для обеих групп, можно допустить, что, если первая группа обнаружила определенное количество всех ошибок, она могла бы определить то же ко­личество любого случайным образом выбранного подмножества.

В частности, можно допустить, что

Значение N 12 известно, а E 1 и Е 2 можно определить как N 12 /N 1 и N 12 /N 2 . Таким образом, неизвестное количество ошибок в про1рамме можно определить по формуле:

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

где P(N12i) — вероятность обнаружения N 12 «общих» ошибок тестирования программы двумя независимыми группами.

Определение ошибок, возникающих в процессе проектирования, ис­пользует данные, свидетельствующие о том, что в большом ПО примерно 40% всех ошибок составляют ошибки проектирования логики и кодирова­ния, а остальные сделаны на более ранних этапах проектирования.

Исходя из этого, рассмотрим пример. Допустим, что тестируется про­грамма размером 1000 операторов; число ошибок, остающихся после ин­спекции исходного текста, оценивается в 5 на 100 операторов. Цель тести­рования — обнаружить 98% ошибок кодирования и логики и 95% ошибок проектирования.

Общее число ошибок составляет 500. Предполагается, что 200 из них составляют ошибки кодирования и логики, а 300 — ошибки проектирования. Следовательно, требуется найти 196 ошибок кодирования и логики и 285 ошибок проектирования.

Из соображений здравого смысла логично так распределить процент­ное отношение найденных ошибок по этапам тестирования, как показано в таблице.

Процентное отношение найденных ошибок по этапам тестирования.

Исходя из этих чисел, можно определить следующие критерии.

1. На этапе тестирования модулей необходимо найти и исправить 130 ошибок (65% от оцененных 200 ошибок кодирования и логики).
2. На этапе тестирования системы необходимо найти и исправить 6 ошибок и 105 (3% от 200 и 35% от 300).

Другая очевидная проблема для этого вида критериев — это проблема переоценки. Что если в приведенном примере к моменту начала проверки функций остается менее 240 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возника­ет переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало оши­бок.

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

Начало — половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.

Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).

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

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

Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:

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

Допустим, стоит задача протестировать новый проект.

Начальные действия:

• Команда тестировщиков получает требования.
• Затем следует планирование и разработка.
• Подготавливается и проверяется документация по тестированию.
  

Тестирование, раунд #1)

Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.

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

Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.

Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к .

Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.

Тестирование, раунд #2)

Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.

Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.

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

Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.

Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.

Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.

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

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

Более того, такая задача не стоит. Цель тестирование ПО — убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.

У приложений может быть бесконечное множество дефектов, и проводить до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.

А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?

Попытаемся разобраться, какие факторы следует считать наиболее важными?

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

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

Пример

Сценарий тестирования:

Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.

Сценарий #1)

Первая неделя
: Вы добились успеха — в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.

Неделя 2
: Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.

Неделя 3
: К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.

Неделя 4
: К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.

Данные о проведенном тестировании помещаются в таблицу:

Недели #1-4	Работа
Неделя #1	Тестирование продолжилось.	Проверены 20 сценариев.
Неделя #2	Особое внимание к дефектам. Выполнение оставшихся сценариев тестирования. Повторное тестирование на предмет наличия дефектов.
Неделя #3	Осталось найти дефекты третьего уровня критичности.	Проверены 120 сценариев.
Неделя #4	Повторное тестирование дефектов высокого и среднего уровня. Выполнение тестовых сценариев.	Обнаружены несколько дефектов 3 уровня. Общее число проверенных сценариев 180.

Может этого уже достаточно?

Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:

• Сценарии проверены не все.
• Несколько потенциально опасных дефектов не тестировались ни разу.
• Все проверенные сценарии тестировались только раз.
• У ПО все еще есть дефекты.

Сценарий #2)

Неделя 1
: Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.

Результаты первой недели аналогичны примеру #1.

Неделя 2
: За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача — охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.

Неделя 3
: К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.

Теперь вы может сообщить только о дефектах второго и третьего уровня.

Данные о проведенном тестировании:

Недели #1-3	Работа	Результаты по истечении недели
Неделя #1	Первый день – обнаружен дефект Show Stopper. Тестирование остановилось до устранения опасного дефекта. Дефект устранен на четвертый день. Тестирование продолжилось до конца первой недели.	Обнаружены критические ошибки. Проверены 20 сценариев.
Неделя #2	Основной акцент на количестве сценариев, дабы наверстать упущенное время. Повторное тестирование устраненных дефектов.	Обнаружены еще несколько дефектов 1, 2 и 3 уровня. Общее количество завершенных тестов 70.
Неделя #3	Перепроверка и поиск основных дефектов. Выполнение оставшихся сценариев. Осталось найти дефекты третьего уровня.	Обнаружено несколько дефектов 1, 2 и 3 уровня. Проверены все сценарии.

Этого достаточно?

Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?

Не совсем:

• Все сценарии проверялись лишь по разу.
• У ПО все еще есть дефекты.
• Регрессионное тестирование не проводилось.

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

Критерии завершения или выхода

Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.

Что включает в себя критерий выхода?

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

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

Тестирование может быть завершено когда:

• Все 100% требований учтены.
• Дефекты установлены/ожидаемое число дефектов обнаружено.
• Все дефекты, относящиеся к классу Show Stopper или Blocker, устранены, ни у одного из критических дефектов нет статуса «открытый».
• Все дефекты с высоким приоритетом идентифицированы и исправлены.
• Defect Rate (скорость дефектообразования) ниже установленного допустимого уровня.
• Очень небольшое число дефектов среднего уровня критичности «открыты», их разбор проведен.
• Число «открытых» дефектов среднего уровня, которые не влияют на пользование системой, очень небольшое.
• Все дефекты с высоким уровнем приоритета закрыты и соответствующие регрессивные сценарии успешно проведены.

Охват теста:

• Охват теста должен быть на уровне 95%.
• Pass Rate текст-кейса также должен быть 95%. Для расчета этого процентного соотношения применяется формула:

(Общее число успешных текст-кейсов / общее число тест-кейсов) * 100.

• Все критически важные тест-кейсы оказались успешными
• 5% тест-кейсов могут быть провалены, но это относится к низкоприоритетным кейсам.
• Достигнуто полное покрытие функционала.
• Все крупные функциональные дефекты успешно устранены.

Сроки:

Срок, отведенный на тестирование, истек.

Документация по тестированию:

Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.

Бюджет:

• Бюджет, выделенный на тестирование, полностью израсходован.
• Совещания в формате «Go / No Go» проведены, решение о релизе продукта принято.

И в заключение, пожалуйста, ответьте на несколько вопросов

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

• Были ли все тест-кейсы проверены по меньшей мере один раз?
• Установлен ли показатель успешности тест-кейса (Test Case Pass)?
• Достигнут ли полный охват тестирования?
• Все функциональные/бизнес «потоки» проверены как минимум раз?
• Найдено ли установленное число дефектов?
• Устранены и «закрыты» ли все дефекты с высоким приоритетом?
• Все ли дефекты прошли повторную проверку и считаются «закрытыми»?
• Регрессивное тестирование проведено для всех «открытых» дефектов?
• Закончился ли выделенный на тестирование бюджет?
• Истекли ли сроки проведения тестирования?
• Вся ли документация по тестированию проверена и опубликована?

Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – ? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?

Причина для остановки: «Сроки поджимают! Время – деньги!»

Часто на проекте есть четко определенные сроки, которые заказчик не всегда готов передвинуть. В этом случае команда «заканчиваем тестирование!» зависит именно от установленных сроков, и это важный критерий. Да, такой сценарий нельзя назвать лучшим (так как времени всегда катастрофически не хватает для полной проверки, и часто страдает качество), но он тоже возможен.

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

Вывод.
Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).

Причина для остановки: «Это не конечная, а промежуточная»

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

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

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

Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»

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

Пример из практики.
Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.

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

Причина для остановки: «Поступил приказ отступать!»

Случается, что заказчик буквально на последнем этапе приостанавливает проверку. На это может быть масса причин: появление более важной задачи или функционала, который требует дальнейшего уточнения, переоценка приоритетов релиза, пересмотр плана на текущий момент. Наша задача при этом – приостановить процесс, но ничего не забыть!

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

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

Причина для остановки: «Все, устал, хватит!»

Остановка может произойти и просто из-за того, что напряжение достигло своего пика. Желание сделать как можно больше за максимально возможное время иногда негативно сказывается на результатах работы.

Пример из практики.
На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела. В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!

Вывод.
В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».

Причина для остановки: «Есть сомнения? Остановись!»

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

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

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

Причина для остановки: «По моему хотению – остановитесь!»

В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).

По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»

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

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

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

И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»

При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам. Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!

Пример из практики.
К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой. Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось?!!!). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.

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

Финал

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

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

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

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

Начало — половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.

Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).

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

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

Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:

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

Допустим, стоит задача протестировать новый проект.

Начальные действия:

• Команда тестировщиков получает требования.
• Затем следует планирование и разработка.
• Подготавливается и проверяется документация по тестированию.
  

Тестирование, раунд #1)

Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.

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

Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.

Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к .

Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.

Тестирование, раунд #2)

Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.

Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.

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

Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.

Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.

Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.

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

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

Более того, такая задача не стоит. Цель тестирование ПО — убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.

У приложений может быть бесконечное множество дефектов, и проводить до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.

А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?

Попытаемся разобраться, какие факторы следует считать наиболее важными?

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

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

Пример

Сценарий тестирования:

Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.

Сценарий #1)

Первая неделя
: Вы добились успеха — в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.

Неделя 2
: Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.

Неделя 3
: К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.

Неделя 4
: К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.

Данные о проведенном тестировании помещаются в таблицу:

Недели #1-4	Работа
Неделя #1	Тестирование продолжилось.	Проверены 20 сценариев.
Неделя #2	Особое внимание к дефектам. Выполнение оставшихся сценариев тестирования. Повторное тестирование на предмет наличия дефектов.
Неделя #3	Осталось найти дефекты третьего уровня критичности.	Проверены 120 сценариев.
Неделя #4	Повторное тестирование дефектов высокого и среднего уровня. Выполнение тестовых сценариев.	Обнаружены несколько дефектов 3 уровня. Общее число проверенных сценариев 180.

Может этого уже достаточно?

Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:

• Сценарии проверены не все.
• Несколько потенциально опасных дефектов не тестировались ни разу.
• Все проверенные сценарии тестировались только раз.
• У ПО все еще есть дефекты.

Сценарий #2)

Неделя 1
: Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.

К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.

Результаты первой недели аналогичны примеру #1.

Неделя 2
: За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача — охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.

Неделя 3
: К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.

Теперь вы может сообщить только о дефектах второго и третьего уровня.

Данные о проведенном тестировании:

Недели #1-3	Работа	Результаты по истечении недели
Неделя #1	Первый день – обнаружен дефект Show Stopper. Тестирование остановилось до устранения опасного дефекта. Дефект устранен на четвертый день. Тестирование продолжилось до конца первой недели.	Обнаружены критические ошибки. Проверены 20 сценариев.
Неделя #2	Основной акцент на количестве сценариев, дабы наверстать упущенное время. Повторное тестирование устраненных дефектов.	Обнаружены еще несколько дефектов 1, 2 и 3 уровня. Общее количество завершенных тестов 70.
Неделя #3	Перепроверка и поиск основных дефектов. Выполнение оставшихся сценариев. Осталось найти дефекты третьего уровня.	Обнаружено несколько дефектов 1, 2 и 3 уровня. Проверены все сценарии.

Этого достаточно?

Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?

Не совсем:

• Все сценарии проверялись лишь по разу.
• У ПО все еще есть дефекты.
• Регрессионное тестирование не проводилось.

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

Критерии завершения или выхода

Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.

Что включает в себя критерий выхода?

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

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

Тестирование может быть завершено когда:

• Все 100% требований учтены.
• Дефекты установлены/ожидаемое число дефектов обнаружено.
• Все дефекты, относящиеся к классу Show Stopper или Blocker, устранены, ни у одного из критических дефектов нет статуса «открытый».
• Все дефекты с высоким приоритетом идентифицированы и исправлены.
• Defect Rate (скорость дефектообразования) ниже установленного допустимого уровня.
• Очень небольшое число дефектов среднего уровня критичности «открыты», их разбор проведен.
• Число «открытых» дефектов среднего уровня, которые не влияют на пользование системой, очень небольшое.
• Все дефекты с высоким уровнем приоритета закрыты и соответствующие регрессивные сценарии успешно проведены.

Охват теста:

• Охват теста должен быть на уровне 95%.
• Pass Rate текст-кейса также должен быть 95%. Для расчета этого процентного соотношения применяется формула:

(Общее число успешных текст-кейсов / общее число тест-кейсов) * 100.

• Все критически важные тест-кейсы оказались успешными
• 5% тест-кейсов могут быть провалены, но это относится к низкоприоритетным кейсам.
• Достигнуто полное покрытие функционала.
• Все крупные функциональные дефекты успешно устранены.

Сроки:

Срок, отведенный на тестирование, истек.

Документация по тестированию:

Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.

Бюджет:

• Бюджет, выделенный на тестирование, полностью израсходован.
• Совещания в формате «Go / No Go» проведены, решение о релизе продукта принято.

И в заключение, пожалуйста, ответьте на несколько вопросов

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

• Были ли все тест-кейсы проверены по меньшей мере один раз?
• Установлен ли показатель успешности тест-кейса (Test Case Pass)?
• Достигнут ли полный охват тестирования?
• Все функциональные/бизнес «потоки» проверены как минимум раз?
• Найдено ли установленное число дефектов?
• Устранены и «закрыты» ли все дефекты с высоким приоритетом?
• Все ли дефекты прошли повторную проверку и считаются «закрытыми»?
• Регрессивное тестирование проведено для всех «открытых» дефектов?
• Закончился ли выделенный на тестирование бюджет?
• Истекли ли сроки проведения тестирования?
• Вся ли документация по тестированию проверена и опубликована?

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

Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.

Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software ». По этому поводу мы с Джеймсом устроили транспективную беседу . Колонку вы можете найти . Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.

Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

В общем, сейчас я расскажу все эвристики, которые мы нашли. Я подчеркиваю, что эти эвристики для остановки являются именно эвристиками
. Эвристики – это быстрые, недорогие способы решения проблемы
или принятия решения
. Эвристики подвержены ошибкам
, то есть они могут как сработать, так и не сработать. Эвристики недостаточно абстрактны , они могут перекрываться и пересекаться друг с другом. Также эвристики зависят от контекста
, поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Ниже я перечислил эвристики и для каждой из них указал некоторые вопросы, при помощи которых можно проверить правомочность её использования.

1. Эвристика
«Время
вышло
!»
. Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.

Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не
был
ли
срок
искусственным
, произвольным
? Будет
ли
выполняться
дополнительная
разработка
, которая
потребует
дополнительного
тестирования
?

Читайте также: CASE -технологии, как новые средства для проектирования ИС. CASE — пакет фирмы PLATINUM, его состав и назначение. Критерии оценки и выбора CASE — средств. Iгруппа – Критерии основанные на дисконтированных оценках, т.е учитывают фактор времени:NPV,PI, IRR,DPP. PR в государственных структурах и ведомствах. PR в финансовой сфере. PR в коммерческих организациях социальной сферы (культуры, спорта, образования, здравоохранения) SCADA-система. ОРС. Организация взаимодействия с контроллерами. Автобус как средство передвижения. Организация автобусных туров, их география, известные туроператоры. Автоматизированные информационные системы и технологии в предприятиях и организациях различных организационных форм. Администрация муниципального образования как организация. Актерское мастерство и организация представлений в русской театральной культуре 19 века.

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

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

Кроме того, конкретные процессы тестирования должны быть ориен­тированы на конкретные этапы разработки. Это сосредотачивает каждый процесс тестирования на каком-либо шаге перевода, в результате чего фик­сируется определенный класс ошибок.

Соотношение между процессами разработки и тестирования.

Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.

Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры от­дельной программы.

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

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

Процесс тестирования завершают испытания ПО. Испытания позволя­ют проверить полноту решения функциональных задач, их качество и соот­ветствие ПО технической документации.

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

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

Существует несколько категорий тестов, каждая из которых направле­на на проверку определенных целей. К ним относятся тестирование полно­ты реализации, тестирование на предельных объемах, тестирование на пре­дельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совмес­тимости, тестирование надежности, тестирование восстановления, тестиро­вание удобства обслуживания, тестирование удобства установки и тестиро­вание документации.

Тестирование полноты реализации является наиболее очевидным ви­дом тестирования системы, который заключается в проверке выполнения каждого пункта исходного документа. Процедура проверки состоит в по­следовательном просмотре исходного документа — предложение за предло­жением. Если предложение содержит конкретную задачу, то определяют, выполняет ли программа эту задачу.

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

Тестирование на предельных нагрузках обусловлено тем, что потреб­ность в ресурсах памяти и быстродействии в процессе решения задачи на ЭВМ значительно изменяется в зависимости от состава объема исходных данных. При высокой интенсивности ввода исходных данных может нару­шаться временной баланс между длительностью решения совокупности задач ПО в реальном времени и реальной производительностью ЭВМ при решении этих задач. Цель тестирования на предельных нагрузках пока­зать, что ПО не удовлетворяет целям в области эффективности.

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

1. Можно ли приспособить разработанный интерфейс для информи­рования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
2. Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
3. Понятна ли диагностика ошибок?
4. Проявляет ли все множество пользовательских интерфейсов посто­янство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
5. Содержит ли система опции, число которых чрезмерно или исполь­зование которых маловероятно?
6. Выдает ли система какие-либо подтверждения на все входные со­общения?
7. Легко ли и приятно ли использовать ПО?

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

Тестирование конфигурации оборудования обусловлено тем, что опе­рационные системы, СУБД и коммуникационные системы должны поддер­живать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы прове­рить ПО на каждой из них. Однако программу следует тестировать по край­ней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необ­ходимо тестировать все возможные его конфигурации.

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

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

Для операционной системы, СУБД и средств телекоммуникации часто определяется, как система должна восстанавливать свою работоспособность после программных ошибок, неисправностей аппаратуры и ошибок в дан­ных. При тестировании системы требуется показать, что эти функции не выполняются. Для этого служит тестирование восстановления. Для этого можно намеренно ввести в систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры можно промоделировать. Ошибки в данных (помехи в линиях связи или неправильные значения указателей в базе данных) можно намеренно соз­дать или промоделировать.

В исходном документе иногда формируются специальные цели удоб­ства обслуживания или сопровождения ПО. Они могут определять средства обслуживания, которыми должно снабжаться ПО (например, программы выдачи дампов памяти, программы диагностики и т.п.), среднее время на­хождения ошибки, процедуры, связанные с сопровождением, и качество до кум стации о внутренней логике программы. Естественно, все эти цели должны быть протестированы. Для этого применяется тестирование удобств обслуживания.

Цель тестирования удобства установки — показать, что не удовлетво­ряются цели по части настройки ПО на конкретные условия эксплуатации.

В проверку системы входит и проверка точности пользовательской до­кументации. Большая часть этой проверки происходит при определении правильности представления предшествующих тестов системы. Кроме это­го, пользовательская документация должна быть подвергнута инспекции на предмет ее точности и ясности, аналогично инспекциям исходного текста. Любые примеры, приведенные в документации, должны быть оформлены как тест и проверены на ПО.

Критерии завершения тестирования.
При проведении тестирования встает вопрос о том, когда следует за­кончить тестирование программы, поскольку не представляется возможным определить, является ли выявленная ошибка последней.

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

Оба эти критерия недостаточно точны и логичны, так как первый кри­терий не содержит оценки качества тестирования и ему можно удовлетво­рить, ничего не делая, второй же не зависит от качества тестовых наборов данных.

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

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

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

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

Зависимость количества ошибок от продолжительности тестирования.

Из примера видно, что если время тестирования велико и с увеличени­ем времени тестирования число ошибок растет, то, естественно, тестирова­ние следует продолжить. Если в процессе тестирования в определенный момент наступило снижение числа выявления ошибок, если число выявлен­ных ошибок постепенно стремится к нулю или достигло нуля, то понятно, что процесс тестирования можно завершить.

Однако этот критерий тоже недостаточно эффективен, поскольку нет никакой уверенности в том, что в последнем случае в дальнейшем не после­дует увеличения числа обнаруживаемых ошибок.

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

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

Другой способ получения такой оценки основан на статических сред­них величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени заверше­ния кодирования (до проведения сквозного просмотра или инспекции) со­ставляет примерно 4 — 8 на 100 операторов программы.

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

Если в программу внесено случайным образом S ошибок, при проверке обнаружено n+V ошибок (n – число найденных собственных ошибок; V – число найденных внесенных ошибок), то предполагаемое число первона­чально находящихся в программе собственных ошибок может быть рассчитано по формуле: .

Например, при обнаружении 20 собственных и 10 привнесенных оши­бок, при общем числе первоначально внесенных ошибок, равном 25, значе­ние N=25*20/10 = 50; т.е. на данном этапе предполагается, что в про­грамме имелось 50 собственных ошибок и тестирование должно быть про­должено.

Оценку числа N можно проводить после каждого нового обнаружения ошибок.

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

где k — предполагаемое число собственных ошибок, S — число внесенных ошибок, n — число обнаруженных собственных ошибок.

Например, если утверждать, что в программе нет ошибок (k=0), и при внесении в программу 6 ошибок все они были обнаружены, а собственные ошибки обнаружены не были, то C=6/(6 + 0 + 1)=0,86. С другой сто­роны, чтобы достичь уровня доверия в 0,98 в программу необходимо ввести 39 ошибок: C=39/(39 + 0 + 1)=0,98.

Модель Миллса не лишена ряда недостатков, самые существенные из которых — это необходимость внесения искусственных ошибок (этот про­цесс плохо формализуем) и достаточно вольное допущение величины k (число собственных ошибок), которое основывается исключительно на интуиции человека, проводящего оценку, т.е. допускает большое влияние субъективного фактора.

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

В процессе тестирования каждая из групп фиксирует все найденные ею ошибки. При оценке числа оставшихся в программе ошибок результаты тестирования обеих групп собираются и сравниваются.

Получается, что первая группа обнаружила N 1 ошибок, вторая – N 2 ошибок, а N 12 — это ошибки, обнаруженные обеими группами.

Если обозначить через N неизвестное количество ошибок, присутст­вующих в программе до начала тестирования, то можно эффективность тестирования каждой из групп определить как

Предполагая, что возможность обнаружения всех ошибок одинакова для обеих групп, можно допустить, что, если первая группа обнаружила определенное количество всех ошибок, она могла бы определить то же ко­личество любого случайным образом выбранного подмножества.

В частности, можно допустить, что

Значение N 12 известно, а E 1 и Е 2 можно определить как N 12 /N 1 и N 12 /N 2 . Таким образом, неизвестное количество ошибок в про1рамме можно определить по формуле:

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

где P(N12i) — вероятность обнаружения N 12 «общих» ошибок тестирования программы двумя независимыми группами.

Определение ошибок, возникающих в процессе проектирования, ис­пользует данные, свидетельствующие о том, что в большом ПО примерно 40% всех ошибок составляют ошибки проектирования логики и кодирова­ния, а остальные сделаны на более ранних этапах проектирования.

Исходя из этого, рассмотрим пример. Допустим, что тестируется про­грамма размером 1000 операторов; число ошибок, остающихся после ин­спекции исходного текста, оценивается в 5 на 100 операторов. Цель тести­рования — обнаружить 98% ошибок кодирования и логики и 95% ошибок проектирования.

Общее число ошибок составляет 500. Предполагается, что 200 из них составляют ошибки кодирования и логики, а 300 — ошибки проектирования. Следовательно, требуется найти 196 ошибок кодирования и логики и 285 ошибок проектирования.

Из соображений здравого смысла логично так распределить процент­ное отношение найденных ошибок по этапам тестирования, как показано в таблице.

Процентное отношение найденных ошибок по этапам тестирования.

Исходя из этих чисел, можно определить следующие критерии.

1. На этапе тестирования модулей необходимо найти и исправить 130 ошибок (65% от оцененных 200 ошибок кодирования и логики).
2. На этапе тестирования системы необходимо найти и исправить 6 ошибок и 105 (3% от 200 и 35% от 300).

Другая очевидная проблема для этого вида критериев — это проблема переоценки. Что если в приведенном примере к моменту начала проверки функций остается менее 240 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возника­ет переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало оши­бок.

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

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

Методика включает 60 незаконченных предложений, условно разделенных на 15 групп, которые характеризуют Ваше отношение к:

Друзьям;

Представителям своего и противоположного пола;

Сексуальным отношениям;

Власти и подчинению;

Прошлому и будущему.

Некоторые группы предложений также затрагивают страхи и опасения, которые влияют на Вашу жизнь, указывают на непрожитую вину, а также проливают свет на жизненные цели.

Без обработки тестирование занимает от 20 минут и более.

Инструкция:
На бланке теста необходимо закончить предложения одним или несколькими словами.

Бланк теста

1. Думаю, что мой отец редко…

2. Если все против меня, то…

3. Я всегда хотел/хотела…

4. Если бы я занимал руководящий пост…

5. Будущее кажется мне…

6. Мое начальство…

7. Знаю, что глупо, но боюсь…

8. Думаю, что настоящий друг…

9. Когда я был/была ребенком…

10. Идеалом женщины (мужчины) для меня является…

11. Когда я вижу женщину рядом с мужчиной…

12. По сравнению с большинством других семей моя семья…

13. Лучше всего мне работается с…

14. Моя мать и я…

15. Сделал/сделала бы все, чтобы забыть…

16. Если бы мой отец только захотел…

17. Думаю, что я достаточно способен/способна, чтобы…

18. Я мог/могла бы быть очень счастливым/счастливой, если бы…

19. Если кто-нибудь работает под моим руководством…

20. Надеюсь на…

21. В школе мои учителя…

22. Большинство моих друзей не знают, что я боюсь…

23. Не люблю людей, которые…

24. Когда-то…

25. Считаю, что большинство юношей (девушек)…

26. Супружеская жизнь кажется мне…

27. Моя семья обращается со мной, как с…

28. Люди, с которыми я работаю…

29. Моя мать…

30. Моей самой большой ошибкой было…

31. Я хотел/хотела бы, чтобы мой отец…

32. Моя наибольшая слабость заключается в том…

33. Моим скрытым желанием в жизни…

34. Мои подчиненные…

35. Наступит тот день, когда…

36. Когда ко мне приближается мой начальник…

37. Хотелось бы мне перестать бояться…

38. Больше всех люблю тех людей, которые…

39. Если бы я снова стал/стала молодым…

40. Считаю, что большинство женщин (мужчин)…

41. Если бы у меня была нормальная половая жизнь…

42. Большинство известных мне семей…

43. Люблю работать с людьми, которые…

44.Считаю, что большинство матерей…

45. Когда я был/была молодым/молодой, то чувствовал/чувствовала вину, если…

46. Думаю, что мой отец…

47. Когда мне не везет, я…

48. Больше всего в жизни я хотел/хотела бы…

49. Когда я даю другим поручение…

50. Когда буду старым/старой…

51. Люди, превосходство которых над собой я признаю…

52. Мои опасения не раз заставляли меня…

53. Когда меня нет, мои друзья…

54. Моим самым живым воспоминанием детства является…

55. Мне очень не нравится, когда женщины (мужчины)…

56. Моя половая жизнь…

57. Когда я был/была ребенком, моя семья…

58. Люди, которые работают со мной…

59. Я люблю свою мать, но…

60. Самое худшее, что мне случилось совершить, это…

Обработка и интерпретация результатов

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

Например, Будущее кажется мне:

1) мрачным, плохим, странным (2)

2) интересным, интригующим (1)

3) неясным, неизвестным (0)

Такая количественная оценка облегчает выявление дисгармоничной системы отношений. Но более важно, конечно, качественное изучение завершенных предложений.

Ключ

1 группа
. Отношение к отцу 1, 16, 31, 46.
2 группа
. Отношение к себе 2, 17, 32, 47.
3 группа
. Нереализованные возможности 3, 18, 33, 48.
4 группа
. Отношение к подчиненным 4, 19, 34, 49.
5 группа
. Отношение к будущему 5, 20, 35, 50.
6 группа
. Отношение к вышестоящим лицам 6, 21, 36, 51.
7 группа
. Страхи и опасения 7, 22, 37, 52.
8 группа
. Отношение к друзьям 8, 23, 38, 53.
9 группа
. Отношение к своему прошлому 9, 24, 39, 54.
10 группа
. Отношение к лицам противоположного пола 10, 25, 40, 55.
11 группа
. Сексуальные отношение 11, 26, 41, 56.
12 группа
. Отношения к семье 12, 27, 42, 57.
13 группа
. Отношение к сотрудникам 13, 28, 43, 58.
14 группа.
Отношение к матери 14, 29, 44, 59.
15 группа.
Чувство вины 15, 30, 45, 60.

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

Проводить дымовое и санитарное тестирование начинают сразу же после выхода очередной версии проекта. Для многих молодых тестировщиков этот процесс кажется абсолютным хаосом. Узнал себя? Тогда эта статья для тебя. Сейчас мы рассмотрим определения дымового и санитарного тестирования, а также покажем разницу между ними на легких для понимания примерах.

Дымовое тестирование:

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

Именно этот вид тестирования не даст потратить время впустую. Логично, что тестирование всего приложения не имеет смысла, если есть проблемы с ключевыми характеристиками и не исправлены критичные баги.

Санитарное тестирование:

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

Пример для лучшего понимания разницы между дымовым и санитарным тестированием:

Есть проект, для которого запланирован первоначальный релиз. Команда разработчиков выпускает билд на тестирование, команда тестировщиков начинает работу. Самое первое тестирование — это тестирование на пригодность. Нужно выяснить, можно работать с этой версией или нет. Это и есть дымовое тестирование. Если команда дает добро на дальнейшую работу с билдом, он отправляется на более глубокие стадии тестирования. Представим, что у билда есть три модуля: “Логин”, “Админ” и “Сотрудник”. Команда тестировщиков проверяет работоспособность исключительно основных функций каждого из модулей, не углубляясь в проверку частностей. Это будет санитарное тестирование.

Еще несколько различий между дымовым и санитарным тестированием:

• Дымовое тестирование проводится и разработчиками, и тестировщиками;
• Санитарное тестирование проводится только тестировщиками.

• Дымовое тестирование охватывает весь основной функционал приложения от начала до конца;
• Санитарное тестирование проверяет только определенный компонент приложения.

• Дымовое тестирование проходит как стабильный, так и не стабильный билд;
• Санитарное тестирование проходит относительно стабильная версия сборки.

Кирилл Флягин, геймдизайнер, QA Lead

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

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

Примеры

1. Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.
2. Ошибки при соединении с базой данных, актуально для архитектуры клиент-сервер .

История

Первое своё применение этот термин получил у печников, которые, собрав печь , закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест.

Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.

Автоматизация

Smoke Tests
легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами. Чем раньше становится известно о проблеме, тем легче её устранить.
Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции .

Напишите отзыв о статье «Smoke test»

Ссылки

• на Jargon File (англ.)
• msdn.microsoft.com/ru-ru/library/ms182613(VS.90).aspx — Правила по кратким тестам от Майкрософт.

Отрывок, характеризующий Smoke test

Весь день она жила только надеждой того, что ночью она уввдит его. Но теперь, когда наступила эта минута, на нее нашел ужас того, что она увидит. Как он был изуродован? Что оставалось от него? Такой ли он был, какой был этот неумолкавший стон адъютанта? Да, он был такой. Он был в ее воображении олицетворение этого ужасного стона. Когда она увидала неясную массу в углу и приняла его поднятые под одеялом колени за его плечи, она представила себе какое то ужасное тело и в ужасе остановилась. Но непреодолимая сила влекла ее вперед. Она осторожно ступила один шаг, другой и очутилась на середине небольшой загроможденной избы. В избе под образами лежал на лавках другой человек (это был Тимохин), и на полу лежали еще два какие то человека (это были доктор и камердинер).
Камердинер приподнялся и прошептал что то. Тимохин, страдая от боли в раненой ноге, не спал и во все глаза смотрел на странное явление девушки в бедой рубашке, кофте и вечном чепчике. Сонные и испуганные слова камердинера; «Чего вам, зачем?» – только заставили скорее Наташу подойти и тому, что лежало в углу. Как ни страшно, ни непохоже на человеческое было это тело, она должна была его видеть. Она миновала камердинера: нагоревший гриб свечки свалился, и она ясно увидала лежащего с выпростанными руками на одеяле князя Андрея, такого, каким она его всегда видела.
Он был таков же, как всегда; но воспаленный цвет его лица, блестящие глаза, устремленные восторженно на нее, а в особенности нежная детская шея, выступавшая из отложенного воротника рубашки, давали ему особый, невинный, ребяческий вид, которого, однако, она никогда не видала в князе Андрее. Она подошла к нему и быстрым, гибким, молодым движением стала на колени.
Он улыбнулся и протянул ей руку.

Для князя Андрея прошло семь дней с того времени, как он очнулся на перевязочном пункте Бородинского поля. Все это время он находился почти в постояниом беспамятстве. Горячечное состояние и воспаление кишок, которые были повреждены, по мнению доктора, ехавшего с раненым, должны были унести его. Но на седьмой день он с удовольствием съел ломоть хлеба с чаем, и доктор заметил, что общий жар уменьшился. Князь Андрей поутру пришел в сознание. Первую ночь после выезда из Москвы было довольно тепло, и князь Андрей был оставлен для ночлега в коляске; но в Мытищах раненый сам потребовал, чтобы его вынесли и чтобы ему дали чаю. Боль, причиненная ему переноской в избу, заставила князя Андрея громко стонать и потерять опять сознание. Когда его уложили на походной кровати, он долго лежал с закрытыми глазами без движения. Потом он открыл их и тихо прошептал: «Что же чаю?» Памятливость эта к мелким подробностям жизни поразила доктора. Он пощупал пульс и, к удивлению и неудовольствию своему, заметил, что пульс был лучше. К неудовольствию своему это заметил доктор потому, что он по опыту своему был убежден, что жить князь Андрей не может и что ежели он не умрет теперь, то он только с большими страданиями умрет несколько времени после. С князем Андреем везли присоединившегося к ним в Москве майора его полка Тимохина с красным носиком, раненного в ногу в том же Бородинском сражении. При них ехал доктор, камердинер князя, его кучер и два денщика.

• Tutorial

Доброго времени суток!

Хочу собрать всю самую необходимую теорию по тестирвоанию, которую спрашивают на собеседованиях у trainee, junior и немножко middle. Собственно, я собрал уже не мало. Цель сего поста в том, чтобы сообща добавить упущенное и исправить/перефразировать/добавить/сделатьЧтоТоЕщё с тем, что уже есть, чтобы стало хорошо и можно было взять всё это и повторить перед очередным собеседованием про всяк случай. Вообщем, коллеги, прошу под кат, кому почерпнуть что-то новое, кому систематизировать старое, а кому внести свою лепту.

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

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

Тестирование программного обеспечения
— проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality)
— это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Верификация (verification)
— это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation)
— это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе .
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Цели тестирвоания

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

Этапы тестирования:

1. Анализ
2. Разработка стратегии тестирования
и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Тест план (Test Plan)
— это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана

В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) StafÞng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн
— это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

Эквивалентное Разделение (Equivalence Partitioning — EP)
. Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Анализ Граничных Значений (Boundary Value Analysis — BVA)
. Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Причина / Следствие (Cause/Effect — CE)
. Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

Исчерпывающее тестирование (Exhaustive Testing — ET)
— это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Traceability matrix
— Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый случай (Test Case)
— это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Случаев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

Чек-лист (check list)
— это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании.

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

Error
— ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect)
— ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure
— сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report)
— это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.
…
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.

Severity vs Priority

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority — менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)

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

S2 Критическая (Critical)

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

S3 Значительная (Major)

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

S4 Незначительная (Minor)

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

S5 Тривиальная (Trivial)

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

Градация Приоритета дефекта (Priority)

P1 Высокий (High)

Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)

Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)

Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

1. Модульное тестирование (Unit Testing)

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)

Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

3. Системное тестирование (System Testing)

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

4. Операционное тестирование (Release Testing).

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

5. Приемочное тестирование (Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

Функциональные виды тестирования

Функциональное тестирование (Functional testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

Все виды тестирования производительности:
o нагрузочное тестирование (Performance and Load Testing)
o стрессовое тестирование (Stress Testing)
o тестирование стабильности или надежности (Stability / Reliability Testing)
o объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Повторное тестирование (Re-testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Функциональное тестирование
рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Тестирование безопасности
— это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.

Тестирование взаимодействия (Interoperability Testing)
— это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

Нагрузочное тестирование
— это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

Стрессовое тестирование (Stress Testing)
позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.

Объемное тестирование (Volume Testing)
. Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing)
. Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

Тестирование установки
направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

Тестирование удобства пользования
— это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
Тестирование пользовательского интерфейса (англ. UI Testing) — это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.
User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

Тестирование на отказ и восстановление (Failover and Recovery Testing)
проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

Конфигурационное тестирование (Configuration Testing)
— специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

Дымовое (Smoke)
тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

Повторное тестирование
— тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.

Тестирование сборки или Build Verification Test
— тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

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

Предугадывание ошибки (Error Guessing — EG)
. Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

Подходы к интеграционному тестированию:

Снизу вверх (Bottom Up Integration)

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

Сверху вниз (Top Down Integration)

Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.

Большой взрыв («Big Bang» Integration)

Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

Принципы тестирования

Принцип 1
— Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.

Принцип 2
— Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.

Принцип 3
— Раннее тестирование (Early testing)
Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.

Принцип 4
— Скопление дефектов (Defects clustering)
Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.

Принцип 5
— Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.

Принцип 6
— Тестирование зависит от контекста (Testing is concept depending)
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.

Принцип 7
— Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

Cтатическое и динамическое тестирование

Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестирвоанию относится тестирования спецификации и прочей документации.

Исследовательское / ad-hoc тестирование

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

Требования
— это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.

Требования к требованиям:

Корректность
Недвусмысленность
Полнота набора требований
Непротиворечивость набора требований
Проверяемость (тестопригодность)
Трассируемость
Понимаемость

Жизненный цикл бага

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

Программный продукт проходит следующие стадии:
анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.

Каждой стадии разработки ПО присваивается определенный порядковый номер. Также каждый этап имеет свое собственное название, которое характеризует готовность продукта на этой стадии.

Жизненный цикл разработки ПО:

Пре-альфа
Альфа
Бета
Релиз-кандидат
Релиз
Пост-релиз

Таблица принятия решений (decision table)
— великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.

После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть перетестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:

— Дымовое тестирование
(Smoke Testing)

— Регрессионное тестирование
(Regression Testing)

— Тестирование сборки
(Build Verification Test)

— Санитарное тестирование или проверка согласованности/исправности
(Sanity Testing)

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

Регрессионное тестирование
– это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде (см. также Санитарное тестирование или проверка согласованности/исправности). Регрессионными могут быть как функциональные,
так и нефункциональные
тесты.

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

Сам по себе термин «Регрессионное тестирование», в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа
регрессионного тестирования:

— Регрессия багов (Bug regression)
– попытка доказать, что исправленная ошибка на самом деле не исправлена.

— Регрессия старых багов (Old bugs regression)
– попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.

— Регрессия побочного эффекта (Side effect regression)
– попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) –
это узконаправленное тестирование, достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.

Отличие санитарного тестирования от дымового.
В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование – это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

Тестирование сборки
(Build Verification Test) – это тестирование, направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

Тестирование Установки (Installation Testing) –
направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. В настоящий момент наиболее распространена установка ПО при помощи инсталляторов
(специальных программ, которые сами по себе так же требуют надлежащего тестирования). В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки. В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll–back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя – это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.

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

В Badoo релизы происходят довольно часто. Например, серверная часть наравне с desktop web релизится дважды в день. Так что мы не понаслышке знаем, что сложное и медленное тестирование – камень преткновения разработки. Быстрое же тестирование – это счастье. Итак, сегодня я расскажу о том, как в компании Badoo устроено smoke-тестирование.

Что такое smoke-тестирование

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

В оригинальном своём применении smoke-тестирование предназначено для проверки самых простых и очевидных кейсов, без которой любой другой вид тестирования будет неоправданно излишним.

Давайте рассмотрим простой пример. Предпродакшн нашего приложения находится по адресу bryak.com (любые совпадения с реальными сайтами случайны). Мы подготовили и залили туда новый релиз для тестирования. Что стоит проверить в первую очередь? Я бы начал с проверки того, что приложение всё ещё открывается. Если web-сервер нам отвечает «200», значит, всё хорошо и можно приступать к проверке функционала.

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

Наш первый smoke-тест

В Badoo серверная часть написана по большей части на PHP. Unit-тесты по понятным причинам пишутся на нём же. Итого у нас уже есть PHPUnit. Чтобы не плодить технологии без необходимости, мы решили писать smoke-тесты тоже на PHP. Помимо PHPUnit, нам потребуется клиентская библиотека работы с URL (libcurl) и PHP extension для работы с ней – cURL.

По сути, тесты просто делают нужные нам запросы на сервер и проверяют ответы. Всё завязано на методе getCurlResponse() и нескольких типах ассертов.

Сам метод выглядит примерно так:

Когда запрос отправлен и ответ получен, мы логируем запрос, чтобы в дальнейшем при необходимости легко воспроизвести цепочку событий, если тест упадёт или сломается. Я об этом расскажу ниже.

Самый простой тест выглядит примерно так:

Public function testStartPage()
{
$url = ‘bryak.com’;
$response = $this->getCurlResponse($url);
$this->assertHTMLPresent(«

Такой тест проходит менее чем за секунду. За это время мы проверили, что стартовая страница отвечает «200», и на ней есть элемент body. С тем же успехом мы можем проверить любое количество элементов на странице, продолжительность теста существенно не изменится.

Плюсы таких тестов:

• скорость – тест можно запускать так часто, как это необходимо. Например, на каждое изменение кода;
• не требуют специального софта и железа для работы;
• их несложно писать и поддерживать;
• они стабильные.

По поводу последнего пункта. Я имею в виду – не менее стабильные, чем сам проект.

Авторизация

Представим, что с момента, как мы написали наш первый smoke-тест, прошло три дня. Само собой, за это время мы покрыли все неавторизованные страницы, какие только нашли, тестами. Немного посидели, порадовались, но потом осознали, что всё самое важное в нашем проекте находится за авторизацией. Как бы получить возможность это тоже тестировать?

Самый просто вариант – авторизационная cookie. Если добавить её к запросу, то сервер нас «узнает». Такую cookie можно захардкодить в тесте, если её время жизни довольно большое, а можно получать автоматически, отправляя запросы на страницу авторизации. Давайте подробнее рассмотрим второй вариант.

Нас интересует форма, куда надо ввести логин и пароль пользователя.

Открываем эту страницу в любом браузере и открываем инспектор. Вводим данные пользователя и сабмитим форму.

В инспекторе появился запрос, который нам надо имитировать в тесте. Можно посмотреть, какие данные, помимо очевидных (логин и пароль), отсылаются на сервер. Для каждого проекта по-разному: это может быть remote token, данные каких-либо cookies, полученных ранее, user agent и так далее. Каждый из этих параметров придётся предварительно получить в тесте, прежде чем сформировать запрос на авторизацию.

В инструментах разработчика любого браузера можно скопировать запрос, выбрав пункт copy as cURL. В таком виде команду можно вставить в консоль и рассматривать там. Там же её можно опробовать, поменяв или добавив параметры.

В ответ на такой запрос сервер вернёт нам cookies, которые мы будем добавлять в дальнейшие запросы, чтобы тестировать авторизованные страницы.

Поскольку авторизация – довольно долгий процесс, авторизационную cookie я предлагаю получать только один раз для каждого пользователя и сохранять где-то. У нас, например, такие cookies хранятся в массиве. Ключом является логин пользователя, а значением – информация о них. Если для следующего пользователя ключа ещё нет, авторизуемся. Если есть – делаем интересующий нас запрос сразу.

Public function testAuthPage()
{
$url = ‘bryak.com’;
$cookies = $this->getAuthCookies(‘[email protected]’, ‘12345’);
$response = $this->getCurlResponse($url, [‘cookies’ => $cookies]);
$this->assertHTMLPresent(«

Разбор падающих тестов

Из вышесказанного следует, что такой тест – это набор запросов к серверу. Делаем запрос, совершаем манипуляцию с ответом, делаем следующий запрос и так далее. В голову закрадывается мысль: если такой тест упадёт на десятом запросе, может оказаться непросто разобраться в причине его падения. Как упростить себе жизнь?

Прежде всего я бы хотел посоветовать максимально атомизировать тесты. Не стоит в одном тесте проверять 50 различных кейсов. Чем тест проще, тем с ним проще будет в дальнейшем.

Ещё полезно собирать артефакты. Когда наш тест падает, он сохраняет последний ответ сервера в HTML-файлик и закидывает в хранилище артефактов, где этот файлик можно открыть из браузера, указав название теста.

Например, тест у нас упал на том, что не может найти на странице кусочек HTML:

Link

Мы заходим на наш коллектор и открываем соответствующую страницу:

С этой страницей можно работать так же, как с любой другой HTML-страничкой в браузере. Можно при помощи CSS-локатора попытаться разыскать пропавший элемент и, если его действительно нет, решить, что либо он изменился, либо потерялся. Возможно, мы нашли баг! Если элемент на месте, возможно, мы где-то ошиблись в тесте – надо внимательно посмотреть в эту сторону.

Ещё упростить жизнь помогает логирование. Мы стараемся логировать все запросы, которые делал упавший тест, так, чтобы их легко можно было повторить. Во-первых, это позволяет быстро руками совершить набор аналогичных действий для воспроизведения ошибки, во-вторых – выявить часто падающие тесты, если такие у нас имеются.

Помимо помощи в разборе ошибок, логи, описанные выше, помогают нам формировать список авторизованных и неавторизованных страниц, которые мы протестировали. Глядя на него, легко искать и устранять пробелы.

Последнее, но не по важности, что могу посоветовать – тесты должны быть настолько удобными, насколько это возможно. Чем проще их запустить, тем чаще их будут использовать. Чем понятнее и лаконичнее отчет о падении, тем внимательнее его изучат. Чем проще архитектура, тем больше тестов будет написано и тем меньше времени будет занимать написание нового.

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

На словах мысль кажется очевидной, согласен. Но на деле всем нам есть куда стремиться. Так что упрощайте и оптимизируйте свои творения и живите без багов.

Итоги

На данный момент у нас *открываю Тимсити* ого, уже 605 тестов. Все тесты, если их запускать не параллельно, проходят чуть меньше, чем за четыре минуты.

За это время мы убеждаемся, что:

• наш проект открывается на всех языках (которых у нас более 40 на продакшене);
• для основных стран отображаются корректные формы оплаты с соответствующим набором способов оплаты;
• корректно работают основные запросы к API;
• корректно работает лендинг для редиректов (в том числе и на мобильный сайт при соответствующем юзер-агенте);
• все внутренние проекты отображаются правильно.

Тестам на Selenium WebDriver для всего этого потребовалось бы в разы больше времени и ресурсов.
Добавить метки