Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Логические ошибки Выдуманные дефекты. Одной из наиболее обидных для тестировщика при- чин отклонения отчёта о дефекте является так называемое «описанное поведение не является дефектом» («not a bug»), когда по какой-то причине корректное пове- дение приложения описывается как ошибочное. Но ещё хуже, когда «якобы ожидаемое поведение» просто… придумывается из головы. То есть нигде в требованиях не сказано, что приложение должно что-то такое делать, но при этом создаётся отчёт о дефекте из-за того, что приложение этого не делает. И ладно бы это были некие спорные случаи или случайно попав- шие в отчёты о дефектах предложения по улучшению, но нет — от приложения начинают требовать каких-то совершенно нелогичных, нерациональных, безумных вещей. Откуда это? Зачем? Просто не делайте так. Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 202/298 Отнесение расширенных возможностей приложения к дефектам. Самым ярким примером этого случая является описание как дефекта того факта, что при- ложение запускается под операционными системами, не указанными явно в списке поддерживаемых. Лишь в очень редких случаях при разработке неких системных утилит и тому подобного ПО, крайне зависящего от версии ОС и потенциально спо- собного «поломать» неподдерживаемую, это можно считать ошибкой (с точки зре- ния общего здравого смысла такое приложение действительно должно показывать предупреждение или даже сообщение об ошибке и завершать работу на неподдер- живаемой ОС). Но что плохого в том, что детская игрушка запустилась на ОС предыдущего поколения? Это реально проблема?! Сомнительно. Неверно указанные симптомы. Это не смертельно, всегда можно подпра- вить, но если изначально отчёты будут сгруппированы по симптомам, их неверное указание создаёт множество раздражающих неудобств. Чрезмерно заниженные (или завышенные) важность и срочность. С этой бедой достаточно эффективно борются проведением общих собраний и пере- смотром отчётов о дефектах силами всей команды (или хотя бы нескольких чело- век), но если эти показатели занижены именно чрезмерно, есть высокая вероят- ность, что пройдёт очень много времени, прежде чем до такого отчёта просто дой- дёт очередь на следующих собраниях по пересмотру. Концентрация на мелочах в ущерб главному. Здесь стоит упомянуть хре- стоматийный пример, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользовательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое «перед смертью» показывало приложе- ние, была опечатка). Всегда думайте о том, как произошедшая с приложением не- приятность повлияет на пользователей, какие сложности они могут из-за этого ис- пытать, насколько это для них важно, — тогда шанс увидеть реальную проблему резко повышается. Техническая безграмотность. Да, вот так безапелляционно и жёстко. В не- которых случаях она просто вызывает грустную улыбку, но в некоторых… Пред- ставьте себе такое краткое описание (оно же идентично продублировано в подроб- ном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не со- ответствует реальной глубине вложенности каталога». А что, должно? Это ведь по- чти то же самое, что «цвет кошки не соответствует её размеру». Ещё несколько показательных примеров (это примеры из разных, никак не связанных между собой отчётов о дефектах): • Краткое описание: «По умолчанию выбран каталог аудиозаписи». (На самом деле в выпадающем списке «Что искать» выбрано значение «Аудиофайлы».) • Пояснение в подробном описании: «У каталога не может быть даты и вре- мени создания». (Хм. Может.) • Ожидаемый результат: «Приложение верно распознало неподдерживаемую файловую систему и показало список файлов». (Ого! С этим приложением, скорее всего, можно будет и на философские темы побеседовать, если оно способно на такую магию.) Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 203/298 Указание в шагах воспроизведения информации, неважной для воспро- изведения ошибки. Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс национальной валюты. Сравните: Плохо Хорошо 1. Создать на диске «J:» каталог «Data». 2. Разместить в созданном каталоге «Data» прилагаемые файлы «song1.mp3» разме- ром 999.99 Kb и «song2.mp3» размером 888.88 Kb. 3. В поле «Где искать» указать «J:\Data». 4. В выпадающем списке «Что искать» вы- брать «Аудиофайлы». 5. Нажать кнопку «Искать». Дефект: указанные в пункте 2 файлы не найдены. 1. В произвольном месте на локальном диске разместить один (или более) файл с рас- ширением «.mp3». 2. Установить параметры поиска («Что ис- кать» -> «Аудиофайлы», «Где искать» -> место расположения файла(ов) из пункта 1). 3. Произвести поиск. Дефект: приложение не обнаруживает файлы с расширением «.mp3». Действительно ли для воспроизведения дефекта важно, чтобы поиск произ- водился на диске «J:»? Действительно ли важно производить поиск именно файлов с такими именами и размерами в таком каталоге? Возможно, в некоем бесконечно маловероятном случае и да, тогда вопрос снимается. Но, скорее всего, это совер- шенно не важно, и нет никакой необходимости записывать эту информацию. Для большей уверенности можно провести дополнительное исследование. Отсутствие в шагах воспроизведения информации, важной для воспро- изведения дефекта. Нет, мы не издеваемся, этот пункт действительно строго про- тивоположен предыдущему. Дефекты бывают разными. Очень разными. Иногда ка- кой-то ключевой «мелочи» не хватит, чтобы разработчику удалось воспроизвести дефект или даже просто понять его суть. Несколько реальных примеров (подчёрк- нуты те детали, отсутствие которых долго не позволяло воспроизвести дефект): • Приложение не сохраняло пользовательские настройки в случае, если в пути к каталогу для их сохранения были пробелы (два и более подряд пробела). • Приложение некорректно завершало работу при открытии файлов, размер которых не позволял прочитать их целиком в оперативную память, доступ- ный объём которой, в свою очередь, определяется значением параметра memory_limit в настройках среды исполнения. • Приложение отображало неверную статистику работы пользователей, если в системе был хотя бы один пользователь, роль которого не была явно ука- зана (NULL-значение в таблице БД, неверная работа подзапроса). Как понять, насколько подробно надо описывать такие детали? Исследова- нием. Мало просто обнаружить некий единичный случай неверного поведения при- ложения, нужно понять закономерность такого поведения и его источник. Тогда не- обходимая степень детализации становится очевидной. Сюда же можно отнести пресловутую воспроизводимость «иногда». Нужно продолжать искать причины, смотреть код, консультироваться с коллегами, прово- дить дополнительные тесты, исследовать похожую функциональность в других ча- стях приложения, исследовать аналогичные приложения, «гуглить» и т.д. и т.п. Да, часть дефектов оказывается сильнее даже самых упорных тестировщиков, но вот процент таких дефектов можно очень сильно приблизить к нулю. Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 204/298 Игнорирование т.н. «последовательных дефектов». Иногда один дефект является следствием другого (допустим, файл повреждается при передаче на сер- вер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: прило- жение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба дефекта. Оценка трудозатрат, планирование и отчётность Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 205/298 2.6. Оценка трудозатрат, планирование и отчётность 2.6.1. Планирование и отчётность В главе «Логика создания эффективных проверок» {149} мы на примере «Кон- вертера файлов» рассуждали о том, как при минимальных трудозатратах получить максимальный эффект от тестирования. Это было достаточно просто, т.к. наше приложение смехотворно по своим масштабам. Но давайте представим, что тести- ровать приходится реальный проект, где требования в «страничном эквиваленте» занимают сотни и даже тысячи страниц. Также давайте вспомним главу «Подроб- ная классификация тестирования» {66} с её несколькими десятками видов тестирова- ния (и это без учёта того факта, что их можно достаточно гибко комбинировать, получая новые варианты) и подумаем, как применить все эти знания (и открывае- мые ими возможности) в крупном проекте. Даже если допустить, что мы идеально знаем все технические аспекты пред- стоящей работы, неотвеченными остаются такие вопросы, как: • Когда и с чего начать? • Всё ли необходимое для выполнения работы у нас есть? Если нет, где взять недостающее? • В какой последовательности выполнять разные виды работ? • Как распределить ответственность между участниками команды? • Как организовать отчётность перед заинтересованными лицами? • Как объективно определять прогресс и достигнутые успехи? • Как заранее увидеть возможные проблемы, чтобы успеть их предотвратить? • Как организовать нашу работу так, чтобы при минимуме затрат получить мак- симум результата? Эти и многие подобные им вопросы уже лежат вне технической области — они относятся к управлению проектом. Эта задача сама по себе огромна, потому мы рассмотрим лишь малую её часть, с которой многим тестировщикам приходится иметь дело, — планирование и отчётность. Вспомним жизненный цикл тестирования {27} : каждая итерация начинается с планирования и заканчивается отчётностью, которая становится основой для пла- нирования следующей итерации — и так далее (см. рисунок 2.6.а). Таким образом, планирование и отчётность находятся в тесной взаимосвязи, и проблемы с одним из этих видов деятельности неизбежно приводят к проблемам с другим видом, а в конечном итоге и к проблемам с проектом в целом. Рисунок 2.6.a — Взаимосвязь (взаимозависимость) планирования и отчётности Работа Отчётность Планирование Планирование и отчётность Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 206/298 Если выразить эту мысль чётче и по пунктам, получается: • Без качественного планирования не ясно, кому и что нужно делать. • Когда не ясно, кому и что нужно делать, работа выполняется плохо. • Когда работа выполнена плохо и не ясны точные причины, невозможно сде- лать правильные выводы о том, как исправить ситуацию. • Без правильных выводов невозможно создать качественный отчёт о резуль- татах работы. • Без качественного отчёта о результатах работы невозможно создать каче- ственный план дальнейшей работы. • Всё. Порочный круг замкнулся. Проект умирает. Казалось бы, так и в чём же сложность? Давайте будем хорошо планировать и писать качественные отчёты — и всё будет хорошо. Проблема в том, что соответ- ствующие навыки развиты в достаточной мере у крайне небольшого процента лю- дей. Если вы не верите, вспомните, как учили материал в ночь перед экзаменом, как опаздывали на важные встречи и… повторяли это раз за разом, так и не сделав выводов. (Если в вашей жизни такого не было, можно надеяться, что вам повезло оказаться в том небольшом проценте людей, у которых соответствующие навыки развиты хорошо.) Корень проблемы состоит в том, что планированию и отчётности в школах и университетах учат достаточно поверхностно, при этом (увы) на практике часто вы- холащивая эти понятия до пустой формальности (планов, на которые никто не смотрит, и отчётов, которые никто не читает; опять же, кому-то повезло увидеть строго обратную ситуацию, но явно немногим). Итак, к сути. Сначала рассмотрим классические определения. Планирование (planning 326 ) — непрерывный процесс принятия управлен- ческих решений и методической организации усилий по их реализации с целью обеспечения качества некоторого процесса на протяжении дли- тельного периода времени. К высокоуровневым задачам планирования относятся: • снижение неопределённости; • повышение эффективности; • улучшение понимания целей; • создание основы для управления процессами. Отчётность (reporting 327 ) — сбор и распространение информации о ре- зультатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации). К высокоуровневым задачам отчётности относятся: • сбор, агрегация и предоставление в удобной для восприятия форме объек- тивной информации о результатах работы; • формирование оценки текущего статуса и прогресса (в сравнении с планом); • обозначение существующих и возможных проблем (если такие есть); • формирование прогноза развития ситуации и фиксация рекомендаций по устранению проблем и повышению эффективности работы. 326 Planning is a continuous process of making entrepreneurial decisions with an eye to the future, and methodically organizing the effort needed to carry out these decisions. There are four basic reasons for project planning: to eliminate or reduce uncertainty; to improve efficiency of the operation; to obtain a better understanding of the objectives; to provide a basis for monitoring and controlling work. [«Project Management: A Systems Approach to Planning, Scheduling, and Controlling», Harold Kerzner] 327 Reporting — collecting and distributing performance information (including status reporting, progress measurement, and fore- casting). [PMBOK, 3 rd edition] Планирование и отчётность Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 207/298 Как и было упомянуто ранее, планирование и отчётность относятся к области управления проектом, которая выходит за рамки данной книги. Если вас интересуют детали, рекомендуется ознакомиться с двумя фун- даментальными источниками информации: • «Project Management: A Systems Approach to Planning, Scheduling, and Controlling», Harold Kerzner. • PMBOK («Project Management Body of Knowledge»). Мы же переходим к более конкретным вещам, с которыми приходится рабо- тать (пусть и на уровне использования, а не создания) даже начинающему тести- ровщику. Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 208/298 2.6.2. Тест-план и отчёт о результатах тестирования Тест-план Тест-план (test plan 328 ) — документ, описывающий и регламентирующий перечень работ по тестированию, а также соответствующие техники и под- ходы, стратегию, области ответственности, ресурсы, расписание и ключе- вые даты. К низкоуровневым задачам планирования в тестировании относятся: • оценка объёма и сложности работ; • определение необходимых ресурсов и источников их получения; • определение расписания, сроков и ключевых точек; • оценка рисков и подготовка превентивных контрмер; • распределение обязанностей и ответственности; • согласование работ по тестированию с деятельностью участников проектной команды, занимающихся другими задачами. Как и любой другой документ, тест-план может быть качественным или обла- дать недостатками. Качественный тест-план обладает большинством свойств каче- ственных требований {41} , а также расширяет их набор следующими пунктами: • Реалистичность (запланированный подход реально выполним). • Гибкость (качественный тест-план не только является модифицируемым с точки зрения работы с документом, но и построен таким образом, чтобы при возникновении непредвиденных обстоятельств допускать быстрое измене- ние любой из своих частей без нарушения взаимосвязи с другими частями). • Согласованность с общим проектным планом и иными отдельными планами (например, планом разработки). Тест-план создаётся в начале проекта и дорабатывается по мере необходи- мости на протяжении всего времени жизни проекта при участии наиболее квалифи- цированных представителей проектной команды, задействованных в обеспечении качества. Ответственным за создание тест-плана, как правило, является ведущий тестировщик («тест-лид»). В общем случае тест-план включает следующие разделы (примеры их наполнения будут показаны далее, потому здесь — только перечисление). • Цель (purpose). Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования {36} , но здесь информация пода- ётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения каче- ства). • Области, подвергаемые тестированию (features to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. • Области, не подвергаемые тестированию (features not to be tested). Пере- чень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной об- 328 Test plan. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 209/298 ласти из списка тестируемых могут быть самыми различными — от пре- дельно низкой их важности для заказчика до нехватки времени или иных ре- сурсов. Этот перечень составляется, чтобы у проектной команды и иных за- интересованных лиц было чёткое единое понимание, что тестирование та- ких-то особенностей приложения не запланировано — такой подход позво- ляет исключить появление ложных ожиданий и неприятных сюрпризов. • |