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