Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 160/301
2.4.8.
Типичные ошибки при разработке чек-листов, тест-кейсов и
наборов тест-кейсов
Ошибки оформления и формулировок
Отсутствие заглавия тест-кейса или плохо написанное заглавие. В абсо- лютном большинстве систем управления тест-кейсами поле для заглавия вынесено отдельно и является обязательным к заполнению — тогда эта проблема отпадает.
Если же инструментальное средство позволяет создать тест-кейс без заглавия, возникает риск получить N тест-кейсов, для понимания сути каждого из которых нужно прочитать десятки строк вместо одного предложения. Это гарантированное убийство рабочего времени и снижение производительности команды на порядок.
Если заглавие тест-кейса приходится вписывать в поле с шагами и инстру- ментальное средство допускает форматирование текста, заглавие стоит писать
жирным шрифтом, чтобы его было легче отделять от основного текста.
Продолжением этой ошибки является создание одинаковых заглавий, по ко- торым объективно невозможно отличить один тест-кейс от другого. Более того, воз- никает подозрение, что одинаково озаглавленные тест-кейсы и внутри одинаковы.
Потому следует формулировать заглавия по-разному, при этом подчёркивая в них суть тест-кейса и его отличие от других, похожих тест-кейсов.
И, наконец, в заглавии недопустимы «мусорные слова» вида «проверка»,
«тест» и т.д. Ведь это заглавие тест-кейса, т.е. речь по определению идёт о про- верке, и не надо этот факт подчёркивать дополнительно. Также см. более подроб- ное пояснение этой ошибки ниже в пункте «Постоянное использование слов «про- верить» (и ему подобных) в чек-листах».
Отсутствие нумерации шагов и/или ожидаемых результатов (даже если таковой всего лишь один). Наличие этой ошибки превращает тест-кейс в «поток со- знания», в котором нет структурированности, модифицируемости и прочих полез- ных свойств (да, многие свойства качественных требований
{44}
в полной мере при- менимы и к тест-кейсам) — становится очень легко перепутать, что к чему отно- сится. Даже выполнение такого тест-кейса усложняется, а доработка и вовсе пре- вращается в каторжный труд.
Ссылка на множество требований. Иногда высокоуровневый тест-кейс
{120}
действительно затрагивает несколько требований, но в таком случае рекоменду- ется писать ссылку на максимум 2–3 самых ключевых (наиболее соответствующих цели тест-кейса), а ещё лучше — указывать общий раздел этих требований (т.е. не ссылаться, например, на требования 5.7.1, 5.7.2, 5.7.3, 5.7.7, 5.7.9, 5.7.12, а просто сослаться на раздел 5.7, включающий в себя все перечисленные пункты). В боль- шинстве инструментальных средств управления тест-кейсами это поле представ- ляет собой выпадающий список, и там эта проблема теряет актуальность.
Использование личной формы глаголов. Если вы пишете требования на русском, то пишите «нажать» вместо «нажмите», «ввести» вместо «введите», «пе- рейти» вместо «перейдите» и т.д. В технической документации вообще не рекомен- дуется «переходить на личности», а также существует мнение, что личная форма глаголов подсознательно воспринимается как «чужие бессмысленные команды» и приводит к повышенной утомляемости и раздражительности.
Использование прошедшего или будущего времени в ожидаемых ре-
зультатах. Это не очень серьёзная ошибка, но всё равно «введённое значение отображается в поле» читается лучше, чем «введённое значение отобразилось в поле» или «введённое значение отобразится в поле».
Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 161/301
Постоянное использование слов «проверить» (и ему подобных) в чек-
листах. В итоге почти каждый пункт чек-листа начинается с «проверить …», «про- верить…», «проверить…». Но ведь весь чек-лист — это и есть список проверок!
Зачем писать это слово? Сравните:
Плохо
Хорошо
Проверить запуск приложения.
Проверить открытие корректного файла.
Проверить модификацию файла.
Проверить сохранение файла.
Проверить закрытие приложения.
Запуск приложения.
Открытие корректного файла.
Модификация файла.
Сохранение файла.
Закрытие приложения.
Сюда же относится типичное слово «попытаться» в негативных тест-кейсах
(«попытаться поделить на ноль», «попытаться открыть несуществующий файл»,
«попытаться ввести недопустимые символы»): «деление на ноль», «открытие не- существующего файла», «ввод спецсимволов» намного короче и информативнее.
А реакцию приложения, если она не очевидна, можно указать в скобках (так будет даже информативнее): «деление на ноль» (сообщение «Division by zero detected»),
«открытие несуществующего файла» (приводит к автоматическому созданию файла), «ввод спецсимволов» (символы не вводятся, отображается подсказка).
Описание стандартных элементов интерфейса вместо использования
их устоявшихся названий. «Маленький крестик справа вверху окна приложения»
— это системная кнопка «Закрыть» (system button «Close»), «быстро-быстро два- жды нажать на левую клавишу мыши» — это двойной щелчок (double click), «ма- ленькое окошечко с надписью появляется, когда наводишь мышь» — это всплыва- ющая подсказка (hint).
Пунктуационные, орфографические, синтаксические и им подобные
ошибки. Без комментариев.
Логические ошибки
Ссылка на другие тест-кейсы или шаги других тест-кейсов. За исключе- нием случаев написания строго оговорённого явно обозначенного набора последо- вательных тест-кейсов
{148}
это запрещено делать. В лучшем случае вам повезёт, и тест-кейс, на который вы ссылались, будет просто удалён — повезёт потому, что это будет сразу заметно. Не повезёт в случае, если тест-кейс, на который вы ссы- лаетесь, будет изменён — ссылка по-прежнему ведёт в некое существующее ме- сто, но описано там уже совершенно не то, что было в момент создания ссылки.
Детализация, не соответствующая уровню функционального тестиро-
вания
{79}
.
Например, не нужно на уровне дымового тестирования
{79}
проверять ра- ботоспособность каждой отдельной кнопки или прописывать некий крайне слож- ный, нетривиальный и редкий сценарий — поведение кнопок и без явного указания будет проверено множеством тест-кейсов, объективно задействующих эти кнопки, а сложному сценарию место на уровне тестирования критического пути
{80}
или даже на уровне расширенного тестирования
{81}
(в которых, напротив, недостатком можно считать излишнее обобщение без должной детализации).
Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 162/301
Расплывчатые двусмысленные описания действий и ожидаемых ре-зультатов. Помните, что тест-кейс с высокой вероятностью будете выполнять не вы (автор тест-кейса), а другой сотрудник, и он — не телепат. Попробуйте дога- даться по этим примерам, что имел в виду автор:
• «Установить приложение на диск C». (Т.е. в «C:\»? Прямо в корень? Или как?)
• «Нажать на иконку приложения». (Например, если у меня есть ico-файл с иконкой приложения, и я по нему кликну — это оно? Или нет?)
• «Окно приложения запустится». (Куда?)
• «Работает верно». (Ого! А верно — это, простите, как?)
• «OK». (И? Что «OK»?)
• «Количество найденных файлов совпадает». (С чем?)
• «Приложение отказывается выполнять команду». (Что значит «отказыва- ется»? Как это выглядит? Что должно происходить?)
1 ... 19 20 21 22 23 24 25 26 ... 38
Аномалия (anomaly313) или инцидент (incident314, deviation) — любое от- клонение наблюдаемого (фактического) состояния, поведения, значения, результата, свойства от ожиданий наблюдателя, сформированных на ос- нове требований, спецификаций, иной документации или опыта и здра- вого смысла. Итак, мы вернулись к тому, с чего начинали в части этой главы, описывающей предельно упрощённый взгляд на дефекты. Ошибки, дефекты, сбои, отказы и т.д. являются проявлением аномалий — отклонений фактического результата от ожи- даемого. Стоит отметить, что ожидаемый результат действительно может основы- ваться на опыте и здравом смысле, т.к. поведение программного средства никогда не специфицируют до уровня базовых элементарных приёмов работы с компьюте- ром. Теперь, чтобы окончательно избавиться от путаницы и двусмысленности, до- говоримся, что мы будем считать дефектом в контексте данной книги: Дефект — отклонение (deviation314) фактического результата (actual re- sult315) от ожиданий наблюдателя (expected result316), сформированных на основе требований, спецификаций, иной документации или опыта и здра- вого смысла. Отсюда логически вытекает, что дефекты могут встречаться не только в коде приложения, но и в любой документации, в архитектуре и дизайне, в настройках тестируемого приложения или тестового окружения — где угодно. Важно понимать, что приведённое определение дефекта позволяет лишь поднять вопрос о том, является ли некое поведение приложения дефек- том. В случае, если из проектной документации не следует однозначного положительного ответа, обязательно стоит обсудить свои выводы с кол- легами и добиться донесения поднятого вопроса до заказчика, если его мнение по обсуждаемому «кандидату в баги» неизвестно. Хорошее представление о едва-едва затронутой нами теме теории надёжности можно получить, прочитав книгу Рудольфа Стапелберга «Руководство по надёжности, доступности, ремонтопригодности и без- опасности в инженерном проектировании» (Rudolph Frederick Stapelberg, «Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design»). А краткую, но достаточно подробную классификацию аномалий в про- граммных продуктах можно посмотреть в стандарте «IEEE 1044:2009 Standard Classification For Software Anomalies». 313Anomaly. Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from so meone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. See also bug, defect, deviation, error, fault, failure, incident, problem. [ISTQB Glossary]