->
Вы готовы?
Содержание
Гладиаторы, пришло время заняться делом. Цель этой статьи — показать вам, как выполнить проект тестирование.
Готовы? Есть четыре критических аспекта:
- Люди, ваша команда готова?
- Среды — есть ли у вас технологии, данные, устройства, интерфейсы для проведения значимых тестов?
- Знания — подготовили ли вы свои тесты с надлежащим уровнем детализации, или ваша команда готова и способна исследовать и тестировать систему динамически?
- Тестируемая система — доступно ли программное обеспечение или система, которую вы собираетесь тестировать?
Первые три аспекта либо находятся под вашим контролем, либо у вас есть средства для мониторинга, управления и координации действий по предоставлению людей, среды и знаний. Тестируемая система — другое дело. Если тестируемая система будет доставлена с опозданием, вы не сможете полноценно начать тестирование. Это классическое сжатие при тестировании.
Классическое сжатие при тестирование
Любой, кто тестировал системы, сталкивался с задержкой доставки системы для тестирования. Почти на каждом уровне, от компонентов до целых систем, разработчики сталкиваются с проблемами, а поставка либо задерживается, либо не завершается. В большинстве случаев, когда для проведения тестирования был назначен период времени, крайний срок не сдвигается, и тестирование сжимается.
Частичная и добавочная доставка
Хотя полная система не может быть доставлена для тестирования, некоторая функциональность — частичная система — может быть предоставлена при условии, что последующие версии будут содержать оставшуюся функциональность. В любое время статус функций в выпуске будет следующим:
- Завершено по мере необходимости: эти функции можно тестировать — по крайней мере, по отдельности.
- Неполные: функции не имеют функциональности и/или известны как неисправные.
- Отсутствует: отложен для доставки в более позднем выпуске.
Что касается доступных функций, возможно, их можно будет протестировать отдельно. Однако они могут зависеть от данных, созданных другими функциями, которые еще не доступны, что может затруднить их тестирование.
Функции могут быть доступны, но выходные данные этих функций не могут быть проверены другими функциями, которые еще не доступны, поэтому требуется изучение тестовой базы данных до и после. Почти наверняка ваши сквозные тесты, требующие тестируемых строк функций, будут в основном заблокированы.
Практически во всех отношениях тестирование частичных систем на системном уровне сильно затруднено.
Защита тестирования
Ваша команда должна добиться прогресса, какой бы упорной она ни была. Если система недоступна или доступна команде только частично, вам придется управлять ожиданиями и защищать свой план.
Ваш план тестирование в малом или большом масштабе зависит от доступной системы — это предположение — поэтому ваш план должен измениться. Вы можете не документировать формальные критерии входа, но сообщение остается тем же:
Критерии входа — это допущения при планировании. Если эти критерии не выполняются, ваши допущения при планировании неверны и план необходимо скорректировать.
Если вы ждете доставки системы или у вас есть доступ к частичной системе, у вас быстро закончатся полезные вещи. Затем вам предстоит сложный разговор с владельцем продукта или менеджером проекта. Если крайний срок завершения не сдвигается, вам придется проводить меньше тестов. Некоторые функции могут тестироваться меньше или вообще исключаться из области тестирования.
Менеджер может полагать, что вы сможете наверстать время позже, но на практике это вряд ли когда-либо достижимо.
Время тестирования, потерянное из-за поздних или неполных поставок, не может быть восстановлено за счет «усердной работы».
Почему задерживается тестирование? Есть много возможных причин, но они, как правило, следуют одному из следующих шаблонов:
- Среды не могут быть настроены вовремя. Люди начали поздно, были слишком заняты или не имели квалификации для создания значимой тестовой среды. То, что доступно, является частичным, неправильно настроенным или неполным.
- Доставка задерживается из-за недооценки масштаба работ.
- Доставка задерживается, потому что программное обеспечение содержит ошибки, его трудно тестировать и исправлять.
- Доставка задерживается из-за того, что команде разработчиков не хватает навыков, опыта или компетенции в области бизнеса или технологий, которые они используют.
- Доставка задерживается, потому что разработка началась с опозданием.
- Доставка задерживается, потому что требования постоянно меняются.
Из приведенного выше списка исключены стихийные бедствия и другие внешние факторы, не зависящие от команды проекта. Если руководитель проекта настаивает на том, чтобы крайний срок тестирования не менялся, а объем тестирования также был фиксированным, перед вами стоит серьезная задача. В каждом вышеприведенном случае причины поздних родов говорят в пользу проведения большего , а не меньшего количества тестов.
Если работу по разработке недооценивают, то, вероятно, недооценивают и тестирование. Если программное обеспечение содержит ошибки, тестирование займет больше времени. Если разработчикам не хватает навыков, то программное обеспечение, скорее всего, будет плохим и его тестирование займет больше времени. Если разработчики начали поздно (почему?), а объем не изменился, то зачем сокращать тестирование? Если требования меняются, скорее всего, ваши планы в любом случае неверны — работа по плохому плану неизбежно усложняет жизнь.
Сколько распространенных причин задержки родов предполагает, что требуется меньше тестов? Никто из них. Защитите свой план.
Отчет об успехах и неудачах
Большинство тестировщиков знают, что эффективное тестирование требует любознательности, настойчивости и чутья на проблему. Главной мотивацией является стимулирование сбоев и создание достаточного количества доказательств того, что сбои можно отнести к дефектам, которые затем можно исправить.
Хотя обнаружение (и исправление) дефектов хорошо влияет на качество продукта, сообщение о дефектах часто создает впечатление, что вы сообщаете кому-то плохие новости. Это может быть разработчик, который где-то допустил ошибку и должен ее исправить, или вы можете сообщать заинтересованным сторонам, что какая-то важная функциональность работает неправильно, и система будет задержана.
Никто не любит сообщать плохие новости, и естественно неохотно расстраивать других людей, особенно близких коллег. Но чувство, что ваши новости хорошие или плохие, не должно волновать посланника.
Дефекты всегда для кого-то плохие новости, но роль тестирования не в том, чтобы осуждать. В некотором отношении тестер подобен журналисту, ищущему правду. В рассказе Киплинга «Слонёнок» есть строки:
Я Держу шестерых честных слуг: (Они научили меня всему, что я знал)
Их имена Что и Где и Когда И Как и Почему и Кто.
Точно так же, как журналист рассказывает новости, вы рассказываете историю того, что вы обнаружили, тестируя систему.
Правда – новости – могут быть хорошими или плохими, но ваша обязанность состоит в том, чтобы как можно лучше выискивать как проблемы, так и успехи. Вы пытаетесь выяснить, что система делает и как она это делает.
В самом конце проекта цель состоит в том, чтобы сдать его в производство с как можно меньшим количеством нерешенных проблем. Вы хотите, чтобы все ваши тесты прошли, но на пути к успеху мешают сбои тестов, которые необходимо исследовать и устранять. Ваша тактическая цель — быстро найти проблемы, но ваша конечная цель — не иметь проблем, о которых нужно сообщать.
Вам нужно вести себя как журналист-расследователь — критически и независимо искать историю. Как писал Киплинг:
Если вы сможете встретиться с Триумфом и Бедствием и относиться к этим двум самозванцам одинаково…
Тогда вы будете держать голову и делать хорошую работу для вашего проекта и заинтересованных сторон.
Покрытие Эрозия
Какие бы целевые показатели охвата ни существовали в начале тестирования, несколько факторов снижают фактически достигнутый охват. Термин «эрозия» является подходящим для использования, поскольку он действительно отражает постепенное сокращение объема запланированных испытаний и неизбежное осознание того, что не все запланированные испытания могут быть выполнены в отведенное время.
Эрозия покрытия может быть вызвана несколькими причинами до проведения теста:
- Во-первых, планы тестирования определяют риски, которые необходимо устранить, и подход, который следует использовать для их устранения. Планы обычно предполагают бюджет на тестирование, что всегда является компромиссом.
- Плохие, нестабильные или незавершенные системные требования, проекты и спецификации усложняют спецификацию тестирования. Покрытие системы скомпрометировано отсутствием деталей спецификации.
- Поздняя доступность или неадекватность тестовых сред делают некоторые запланированные тесты непрактичными или бессмысленными. Более крупномасштабное интеграционное тестирование может быть невозможно выполнить в соответствии с планом, поскольку не все интерфейсы или системы сопряжения могут быть доступны.
- Тестирование производительности может быть скомпрометировано из-за того, что среда не масштабируется или не отражает производительность.
- Несвоевременная поставка тестируемого программного обеспечения означает, что, когда сроки остаются фиксированными, объем тестирования должен быть сокращен.
Разрушение покрытия выполнения теста во время выполнения теста также имеет несколько причин:
- Если качество тестируемого программного обеспечения низкое на входе в стадию тестирования, выполнение тестов может быть особенно разочаровывающим. Самые простые тесты могут не пройти, а обнаруженные ошибки могут быть настолько серьезными, что разработчикам потребуется больше времени для их исправления, чем кто-либо ожидал. Если тестирование приостановлено из-за слишком низкого качества программного обеспечения, вы опоздаете. Если крайний срок не сдвинется, некоторые тесты будут удалены.
- Там, где возникает больше ошибок, чем предполагалось, сам цикл исправления и повторного тестирования займет больше времени, и вам не хватит времени для завершения всех ваших тестов.
- Когда время истечет и будет принято решение о выпуске, не все ваше тестирование будет завершено. Либо некоторые тесты никогда не были выполнены в плане, либо какие-то оставшиеся ошибки блокируют завершение неудачных тестов. Если дата ввода в эксплуатацию не меняется, это классическое сжатие тестирования, упомянутое выше.
Борьба с эрозией тестового покрытия — одна из проблем, с которыми сталкиваются тестировщики во всех проектах. Вещи редко идут гладко, и сокращение времени на тестирование (и охват) обычно является единственным способом сохранить проект в нужном русле.
Нет ничего плохого в том, чтобы уменьшить количество тестов; только неправильно произвольно сокращать тестирование. Следовательно, при принятии решения о том, какие тесты следует сократить, необходимо проанализировать их влияние на цели тестирования и риски, которые необходимо устранить. Возможно, у вас возникнут неловкие разговоры с заинтересованными сторонами.
Там, где воздействие является значительным, вам может потребоваться организовать встречу тех, кто просит о сокращениях (как правило, руководство проекта), и тех, чьи интересы могут быть затронуты сокращениями (заинтересованные стороны). Ваша роль состоит в том, чтобы изложить ситуацию в отношении завершенных тестов, текущего известного состояния тестируемой системы, тестов, которые не пройдены и/или заблокировали выполнение, а также объема тестирования, которое еще предстоит выполнить.
Ваши планы и модели определяют первоначальный объем тестирования и очень важны для того, чтобы помочь заинтересованным сторонам и руководству понять пробелы и нерешенные риски и принять решение о продолжении тестирования или его прекращении.
Управление происшествиями
Как только проект переходит на этапы системного тестирования и приемочного тестирования, он в значительной степени определяется инцидентами, возникающими во время выполнения теста. Инциденты инициируют действия в оставшейся части проекта, и статистика инцидентов иногда может дать хорошее представление о статусе проекта. При классификации инцидентов нам необходимо заранее подумать о том, как эта информация будет использоваться позже.
Инцидент — это незапланированное событие, происходящее во время тестирования, которое может иметь некоторое отношение к успешному завершению тестирования, принятию решения или необходимости предпринять какое-либо другое действие.
Мы используем нейтральный термин для этих незапланированных событий — инцидент. Однако эти события часто обозначаются другими терминами; некоторые более нейтральны, чем другие.
Неудачные тесты могут называться наблюдениями, аномалиями или проблемами — нейтральными терминами, не предполагающими причин. Но иногда используются проблемы, ошибки, дефекты или сбои, что предполагает неисправность системы. Однако это может быть преждевременным выводом, и эти ярлыки могут ввести в заблуждение.
Мы предлагаем вам зарезервировать термины «ошибка», «дефект» или «ошибка» для результатов диагностики сбоев в построении тестируемой системы, которые обычно требуют доработки для группы разработчиков.
Инциденты проявляются двумя способами:
- Отказ системы: система ведет себя не так, как ожидалось при тестировании, т. е. она каким-то образом дает сбой или кажется, что она не соответствует какому-то требованию.
- Прерывание или подрыв тестирования или тестов: какое-либо событие, которое влияет на способность тестировщиков выполнять свои задачи, например, потеря или сбой тестовой среды, данных, интерфейсов или вспомогательных, интегрированных систем или служб, или какое-либо другое внешнее воздействие. .
Сбой системы
Эти инциденты часто вызывают непосредственное беспокойство, поскольку подрывают доверие к качеству системы.
Прерывания и недоработанные тесты
Некоторые организации вообще не рассматривают эти инциденты как инциденты — сбои являются частью неразберихи проектов, приближающихся к своему завершению. Подрывные тесты, в которых среда или настройка теста неверны, могут быть возложены на команду тестирования (за настройку или, по крайней мере, за непроверку настройки перед тестированием).
В обоих случаях это влияет на ход тестирования, и, если вы управляете процессом, вы несете ответственность за объяснение задержек. По этой причине вы должны либо фиксировать эти события как инциденты, либо попросить команду вести журнал тестирования и записывать сбои среды, проблемы с конфигурацией или отсутствие подходящих версий программного обеспечения для тестирования. Если вы этого не сделаете, вам будет трудно оправдать задержки в работе, и это может плохо отразиться на вас и вашей команде.
Регистрировать инциденты или нет?
С появлением гибких и непрерывных подходов традиционный взгляд на управление инцидентами был поставлен под сомнение. В поэтапных проектах инциденты рассматриваются как потенциальные рабочие пакеты для разработчиков, которые утверждаются в зависимости от серьезности и/или срочности.
Существует формальный, часто бюрократический процесс, в ходе которого инциденты анализируются, расставляются по приоритетам и принимаются действия командой разработчиков (или другой командой). Могут быть задействованы сложные инструменты управления инцидентами.
В небольших agile-командах отношения между тестировщиком и разработчиком близки. Команда в целом может собираться ежедневно для обсуждения более крупных инцидентов, но чаще всего ошибки выявляются, диагностируются, исправляются и повторно тестируются в неофициальном порядке без необходимости регистрации инцидента или привлечения других членов команды или внешнего бизнес- или ИТ-персонала. Более серьезные ошибки могут быть обсуждены и включены в работу над пользовательской историей или объединены в специальные итерации исправления ошибок или спринты.
Мы обсуждали цель и потребность в документации в предыдущей статье. Это обсуждение подходит и для инцидентов. Команде необходимо решить, требуются ли инструмент и процесс обработки инцидентов, полезен ли он для команды и/или необходим ли людям, не входящим в команду.
Большие команды склонны полагаться на процессы и инструменты для управления инцидентами по трем причинам:
- Чтобы инциденты не были забыты
- Серьезные проблемы рассматриваются заинтересованными сторонами и руководством проекта.
- Чтобы зафиксировать метрики, которые могут быть полезны во время и после проекта.
Отделение срочности от серьезности
Какой бы процесс управления инцидентами вы ни выбрали, мы рекомендуем присваивать всем вашим инцидентам как приоритет, так и код серьезности.
- Приоритет назначается с точки зрения тестирования и влияет на то, когда инцидент будет разрешен. Тестировщик должен решить, имеет ли инцидент высокий или низкий приоритет (или любую из разрешенных промежуточных степеней). Приоритет указывает на срочность этой ошибки для самих тестировщиков и основан на влиянии сбоя теста на остальную часть тестирования.
- Серьезность назначается с точки зрения пользователя и указывает на приемлемость или неприемлемость (обычно) дефекта. Конечные пользователи или их руководство должны назначать серьезность или (что более эффективно) при необходимости переопределять исходное представление тестировщиков. Серьезность отражает влияние этого дефекта на бизнес, если он не был устранен до поставки. Как правило, серьезный дефект делает систему неприемлемой. Если дефект имеет низкую серьезность, он может быть сочтен слишком тривиальным, чтобы нуждаться в исправлении перед вводом в эксплуатацию, но может быть исправлен в более позднем выпуске.
Если инцидент останавливает тестирование, а тестирование находится на критическом пути, то весь проект останавливается.
Инцидент с высоким приоритетом останавливает все тестирование и, как правило, проект.
При использовании схем классификации инцидентов важно помнить, что не каждый срочный инцидент является серьезным и не каждый серьезный инцидент является срочным.
Управление эндшпилем
Мы называем заключительные этапы нашего тестового процесса «конечной игрой», потому что управление тестовой деятельностью в эти последние, возможно лихорадочные и напряженные дни требует дисциплины, отличной от ранее, казалось бы, гораздо более спокойного периода планирования тестирования.
Помните, что цель тестирования — предоставить информацию заинтересованным сторонам, чтобы они могли принять решение — принять, исправить, отклонить, расширить проект или полностью отказаться от него.
Если у вас есть общее понимание моделей, которые будут использоваться для тестирования, гораздо проще объяснить, что «работает» (по отношению к модели), а также то, где что-то не работает, и риски этих сбоев. Заинтересованные стороны должны использовать эту информацию для принятия своих решений под вашим руководством.
Одно из достоинств подхода к тестированию, основанному на оценке рисков, заключается в том, что там, где тестирование сжимается на поздних этапах проекта, мы используем остаточный риск, чтобы привести аргумент в пользу продолжения тестирования или даже добавления дополнительных тестов.
Там, где руководство настаивает на сокращении объема тестирования, тестировщики должны просто представлять риски, которые «торгуются». Это намного проще, когда ранняя оценка риска была выполнена, использовалась для управления действиями по тестированию и отслеживалась на протяжении всего проекта. Когда руководство постоянно осведомлено об остаточных рисках, маловероятно, что оно вообще будет сокращать тестирование.
На этом все, удачи вам в тестировании!
