Ознакомившись с SDLC многие уже поняли, что тестирование важно на протяжении всего проекта. Но именно на начальной стадии, при тестировании документации (требований к продукту, в том числе), можно обнаружить критические ошибки, например в логике разрабатываемой информационной системы, и тем самым избежать их. Поэтому нужно помнить об увеличении стоимости ошибки в процессе разработки. Чем позднее была обнаружена ошибка, тем сложнее, дольше и дороже будет её исправление.
Но что же такое "ошибка"? Чем она отличается от "дефекта"?
Ошибка (error, mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — любое отклонение изготовленной продукции (в нашем случае ПО) от требований, установленных нормативно-технической документацией (определение ГОСТ 15467-79).
Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.
Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.
Также стоит выделить понятие инцидента:
Инцидент (incident, deviation) — любое сообщение о сбое/отказе или дефекте системы, поступившее от пользователя системы через службу технической поддержки.
На ошибки человека повлиять мы не можем, но в наших руках уменьшить вероятность возникновения инцидентов на промышленной среде. Тем самым, одной из целей тестирования является обнаружение дефектов и отказов.
Каковы же цели тестирования?
- Оценить продукт на соответствие требованиям и стандартам;
- Проверить завершился ли объект тестирования;
- Обнаружить отказы и дефекты;
- Снизить уровень риска ненадлежащего качества продукта;
- Обеспечить соблюдение договорных, правовых или нормативных требований.
Отличие верификации от валидации.
Верификация в тестировании ПО – процесс просмотра документации, дизайна, кода и программы для того, чтобы проверить, было ли программное обеспечение создано в соответствии с требованиями или нет.
Валидация в разработке ПО – динамический механизм тестирования и проверки того, действительно ли программный продукт соответствует точным потребностям заказчика или нет.
Очень часто студенты и соискатели на должности в тестировании знают эти определения, но сформулировать разницу между ними затрудняются.
Для раскрытия этих терминов всегда рекомендую два отличных объяснения:
Когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Валидация — это доказательство, что продуктом, оборудованием или процессом можно пользоваться по назначению.
Верификация — общая проверка технических требований к продукту. Даже если продукт прошел ее — не факт, что конечные покупатели смогут им успешно пользоваться.
Стартап Juicero разработал машину для розлива пакетированных соков. Она отвечала техническим характеристикам, которые заложили разработчики, — прошла верификацию.
Когда машину поставили на рынок, оказалось, что она неэффективно работает. Пользователям было проще выдавливать пакеты с фруктами и овощами вручную, чем купить для этого технику за 400 $. То есть валидацию продукт не прошел.
В следующей части мы обсудим и разберем основные ошибки при составлении ключевого артефакта (документа) тестирования - баг-репорта.
Продолжаю радоваться вашей обратной связи и вашим вопросам!