что такое качество исследования тест
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Тестирование или управление качеством. Часть 3. Что такое качество?
В двух последних постах Что такое тестирование? и Организация тестирования я поделилась своими соображениями об испытаниях. Хотя между понятиями «тестирование» и «качество» есть тесная связь, одно из них не обязательно подразумевает второе. Тестирование лишь дает нам какое-то представление о качестве.
Я хотела завершить эту серию публикаций постом, полностью посвященным качеству и управлению качеством, но у меня оказалось так много мыслей на эту тему, что его пришлось разделить на две части. В первой из них я расскажу о своем взгляде на качество.
Я предпочитаю использовать в отношении него термин «управление», а не «обеспечение» (QA), потому что информация, полученная в ходе тестирования, может помочь улучшить качество продукта, но не может «обеспечить» его. Проходя сертификацию на менеджера по качеству в Американском обществе качества (ASQ), я узнала, что QA подразумевает прежде всего правильную организацию процессов. Сейчас значение термина QA искажено, и зачастую он употребляется неверно, поэтому я не думаю, что он по-прежнему применим, — по крайней мере, в сфере разработки ПО.
Существует множество разных контекстов, каждый из которых требует отдельного взгляда на качество. Но в любом случае оно, как характеристика, должно быть «встроено» в продукт с самого начала, и мне нравится, когда клиенты становятся участниками этого процесса.
Самое популярное определение, которое я слышала, принадлежит Джеральду Вайнбергу: «Качество — это ценность для определенного человека». Оно мне нравится, но кажется слишком упрощенным и оставляющим за скобками некоторые параметры, которые следует иметь в виду.
Вот уже несколько лет Алан Пейдж (Alan Page) и Брент Дженсен (Brent Jensen) обсуждают современные принципы проведения тестирования. Пятый из этих принципов звучит так: «Клиент — единственный, кто может судить о качестве нашего продукта и оценивать его». На мой взгляд, как и в случае с определением Джеральда, это чересчур простая концепция. Мне хотелось чего-то более содержательного, поэтому я решила сосредоточиться на том, какой должна быть стратегия качества для продукта, над которым я работаю.
Вернемся в прошлое. Уильям Эдвардс Деминг определял хорошее качество как «предсказуемый уровень единообразия, надежности и соответствия стандартам клиента». И здесь мы также видим ориентацию на клиента. Многие из 14 принципов Деминга, описанных в его книге Выход из кризиса (Out of Crisis), по-прежнему применимы и, вероятно, останутся актуальными в будущем. Например, он говорил о «встраивании» качества и уменьшении зависимости от проверок.
Дэн Эшби (Dan Ashby) в своем посте о четырех абсолютах качества Кросби показывает, что эти абсолюты, с поправкой на контекст, все еще можно применять к программному обеспечению.
Несколько лет назад, когда я готовилась к беседе о процессах качества, Изабель Эванз (Isabel Evans) показала мне статью Дэвида Гарвина (David A. Garvin), которая снова заставила меня задуматься, что же в действительности представляет собой качество. Ниже я приведу несколько мыслей оттуда, но лучше прочитайте ее целиком. А в этой статье автор дополнительно раскрывает значение восьми параметров качества.
Люди обычно говорят о качестве, как об одной общей категории. Большая часть того, что мы можем измерить, касается выполнения процессов — я называю это «качество процесса». В свою очередь, «качество продукта» связано с конечным продуктом и опытом наших клиентов.
Подходы к качеству
Качество продукта можно рассматривать с разных сторон. Точка зрения клиента — лишь одна из них. Она показывает, насколько продукт пригоден к использованию или удовлетворяет потребностям, которые у разных клиентов могут отличаться. Мы также должны учитывать мнение других ключевых лиц, заинтересованных в качестве продукта.
Дэвид Гарвин говорит о пяти подходах к качеству. Ниже вы можете увидеть их в форме диаграммы.
Все мы смотрим на качество под разными углами, которые могут меняться в зависимости от обстоятельств. Я начну с внутреннего круга, как с самого простого, и буду постепенно двигаться наружу.
Ориентация на производство
Рассматривая цикл разработки как производственный процесс, мы должны сосредоточиться на методах, которые используем, и соблюдении требований. Наивысший уровень качества в данном случае достигается путем выполнения спецификаций, а основное внимание уделяется предотвращению неполадок и переделок. Вот почему многие разработчики тратят время на выстраивание правильного производственного процесса и оценку его качества, а также проводят тестирование, направленное на эти цели.
Однако нужно понимать, что разработка ПО отличается от производства одного и того же продукта раз за разом. Мы постоянно развиваем то, что у нас есть, меняем и адаптируем.
Вот несколько мероприятий, которые позволяют поддерживать качество разработки (производства): разработка через тестирование (TDD), написание кода с учетом удобства отладки, рецензирование кода, непрерывная интеграция, исследовательское тестирование и даже обеспечение соответствия критериям готовности. Мы оцениваем качество процесса и отвечаем на вопрос: «Правильно ли он организован?».
Ориентация на продукт
Гарвин определяет этот подход как обеспечение качества отдельных компонентов, составляющих целое. Из лучших ингредиентов получается лучший продукт.
При таком подходе производство компонентов стоит недешево, поэтому товары, сделанные из них, тоже имеют более высокую цену. Повышение качества продукта, который является качественным по умолчанию, подразумевает улучшение производительности и дополнительные возможности — что также увеличивает стоимость.
Обсуждая этот вопрос, мы с Полом Симаном (Paul Seaman) придумали интересную метафору: обычный повар не обязательно приготовит из хороших ингредиентов вкусное блюдо, но умелый шеф даже из обычных продуктов может сделать нечто волшебное. Мы должны понимать, из чего состоит наш продукт и как эти части соединяются друг с другом.
Вот несколько мероприятий, которые помогают поддерживать качество продукта: разработка на основе приемочных испытаний (ATDD) или разработка на основе поведения (BDD), а также тестирование параметров качества, таких как безопасность, производительность и эксплуатационная надежность. В этом случае мы отвечаем на вопрос: «Работает ли продукт так, как должен (или как нам хотелось)?».
Ориентация на потребителя
Взгляд на качество с точки зрения пользователя — один из самых часто используемых, но при этом очень субъективных и индивидуальных критериев.
Он подразумевает, что потребители имеют достаточно информации для оценки качества продукта. А если это не так, они могут ориентироваться на некие признаки, чтобы произвести такую оценку. Возьмем, например, чашку кофе. Я предпочитаю простой черный кофе из зерен средней обжарки, а моя сестра всегда заказывает капучино. Что это значит для вас? Кто ваш потребитель? Кто сможет оценить качество вашего продукта? Должны ли вы удовлетворить потребности большинства потребителей или ориентироваться на конкретную целевую группу?
Вот процессы, которые, по моему мнению, могут помочь поддерживать потребительское качество: разработка дизайна взаимодействия с клиентом для понимания его потребностей, ATDD, испытания с использованием тест-персон, A/B-тестирование, тестирование доступности и наблюдаемости, проведение аналитики использования продукта. Здесь мы пытаемся ответить на вопрос: «Этого ли хочет потребитель?».
Ценностный подход
Ценность продукта определяется его стоимостью и затратами на производство. Может ли он обеспечить нужную производительность по приемлемой цене? Возьмем все ту же чашку кофе: одни люди хотели бы купить ее за 50 центов, а другие могут заплатить 5 долларов. Разница в цене составляет 1000 %. Неужели бобы, из которых готовится этот кофе, так сильно отличаются друг от друга? А может, дело в обжарке? Или в чем-то другом?
Специалисты по маркетингу часто задаются этими вопросами. Чтобы найти ответы, они исследуют ценовые точки, проводят опросы среди покупателей, анализируют количество продаж и определяют, какую прибыль может принести та или иная специфическая характеристика продукта. Такие исследования позволяют подтвердить предположения и помогают организациям понять, как именно потребители используют их товары и какую ценность в них находят.
Менеджеры по продукту также заинтересованы в поддержании этой ценности. Они должны найти такие ценовые точки, которые помогут сделать предложение привлекательным для клиента и в то же время позволят им получить прибыль, чтобы не выпасть из бизнеса. Вопрос, на который нам нужно ответить, звучит так: «Представляет ли наш продукт достаточную ценность для клиента?».
Абсолютный подход
Я намеренно оставила абсолютное качество напоследок. Гарвин описывает его как «изначальное совершенство», которое способен распознать кто угодно, признак высочайших стандартов и отличных показателей. Оно с трудом поддается количественному определению, но вы узнаете его, когда увидите. Ваши чувства подскажут вам. Возможно, это вкус и аромат того великолепного капучино, который вы заказываете снова и снова.
Когда организация собирает команду специалистов для создания чего-то особенного, выходящего за рамки обыденности, получается продукт абсолютного качества. Это может быть, например, неожиданно прекрасная графика для новой игры. Однажды я работала над системой, которая должна была заменить другую — ту, что больше не поддерживалась. Когда я спросила, нравится ли новая система пользователям, мне ответили: «Да, очень!» — все потому, что она подстраивалась под их рабочие процессы, а не наоборот. Небольшой пример абсолютного качества.
Заключение
Я бы хотела, чтобы сейчас вы еще раз подумали о том, что значит качество лично для вас. Это непростая тема, поэтому ее редко обсуждают. На одном из своих семинаров я попросила участников дать собственное определение качеству конкретного продукта. Задайте этот же вопрос своим специалистам и посмотрите, о чем говорят их ответы — о качестве разработки (процесса) или все же самого продукта.
Мой следующий пост будет посвящен управлению качеством: я расскажу о тех, кто его осуществляет, о проведении измерений и о том, как создать стратегию качества.
Вы также можете прочитать пост о качестве и его стоимости, опубликованный в моем старом блоге в 2010 году. P.S. Я все еще езжу на «Мини Купере» — правда, на новой модели, которая еще шикарнее, чем я описывала в том посте. Если вы это читаете, я надеюсь, вы прочтете и комментарии тоже.
В преддверии старта курса QA Lead приглашаем всех желающих на бесплатный двухдневный интенсив в рамках которого изучим теоретические основы методов тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Изучим Example Mapping как способ протестировать технические требования. А также попрактикуемся в построении Example Mapping.
Качественное тестирование ПО
Привет, хабровчане. Прежде чем уйти на выходные, хотим рассказать о том, что в декабре в OTUS запускается курс «QA Engineer». Курс подойдет для начинающих тестировщиков, которые только начинают свой путь в тестировании или переходят в область тестирования из смежных технических областей. Также предлагаем записаться на бесплатный вебинар, в рамках которого наши эксперты расскажут о карьерных перспективах в сфере тестирования.
А сейчас традиционный перевод полезного материала.
18 характеристик качественного тестирования программного обеспечения
Это история про Алису. Алиса не только умный, скромный и добрый персонаж, но и отличный тестировщик. Последнее описать нелегко. Понять, что такое качественное тестирование можно, увидев его. Вот что увидел я.
★ Алиса действует как социолог
Алиса знает, что тестирование — это социальная наука. Она знает, что качество ПО по своей сути субъективно. Она знает, что качество представляет собой ценность для людей, которые имеют значение (Джеральд Вайнберг). Она понимает, что ошибка угрожает этой ценности и досаждает кому-то. (Джеймс Бах). Она понимает, что ошибка не обязательно находится в ПО, а скорее появляется в результате взаимодействия между человеком и программой (Джем Канер). Следовательно, она признает, что уровень качества нельзя измерить, а можно только оценить. Таким образом, она действует как социолог, который ищет значимые проблемы для разных людей, потому что знает, что люди воспринимают качество одного и того же ПО по-разному.
★ Алиса действует как психолог
Алиса знает, что наши ошибки в мышлении могут превратиться в программные ошибки, если мы не осознаем свои когнитивные предубеждения (Эндрю Браун). Поэтому она ищет ошибки в сознании людей. Таким образом, она действует как психолог, который копается в сознании людей, чтобы проанализировать особенности мышления. Она знает, что большая часть их знаний о ПО (включая мнения, предположения, ожидания, желания, догадки, чувства, опыт) находится в их головах.
★ Алиса действует как контролёр
Алиса знает, что автоматическая повторяющаяся проверка важна, потому что понимает, что не следует доверять ПО. Она не доверяет ПО, потому что оно постоянно меняет свое «мнение». Само ПО и область его применения (бизнес, технологии) постоянно и стремительно развиваются. Поэтому она автоматизирует процесс проверки, с целью сделать его более быстрым и точным. Она знает, что процесс автоматизации требует постоянной поддержки. Поэтому она относится к автоматизации как к калорийному сладкому десерту — в небольшом количестве вкусно и хорошо, но если его переесть, будет плохо. Итак, она автоматизирует важные проверки, которые многократно раскрывают полезную информацию о ПО. Таким образом, она действует как контролер, который следит за соотношением выгод и затрат автотестов, чтобы не утонуть в усилиях по их обслуживанию.
★ Алиса действует как лидер
Алиса знает, что тестирование ПО — это не механический однообразный процесс, а творческая, многомерная и ориентированная на человека деятельность. Она считает, что в центре процесса тестирования находятся не машины, а люди-тестировщики и их навыки. Она умеет программировать, но не хочет искусственно повышать свою важность, изобретая для нее новые названия (например, SDET, Automation Tester). Она знает, что слова “тестировщик” достаточно. Она понимает, что на самом деле ей платят за тестирование, а не за код.
Она использует разные инструменты с целью ускорить, расширить, усилить и упростить тестирование (Майкл Болтон). Она не рассматривает инструменты как нечто, что устраняет необходимость в человеческом мышлении при тестировании. Она знает, что глупо обвинять гравитацию в падении вниз. Поэтому она не винит инструменты, если тест не удался. Она знает, что только плохие тестировщики винят инструменты в случае неудачи. Таким образом, она действует как лидер , который считает себя ответственным за свои действия и результаты тестирования.
★ Алиса действует как хамелеон
Алиса знает, что тестирование зависит от контекста (Канер, Бах, Петтихорд, Марик). Она знает, что не существует “лучших практик” в тестировании, только хорошие практики для конкретного случая. Она знает, что ценность любой практики зависит от ее контекста (проекта, продукта, людей, окружающей среды и т.д.) Она знает, что не станет тестировать автопилот авиалайнера так же, как веб-сайт (Иэн МакКоватт). Конечно, иногда, вместо того, чтобы научиться пользоваться долотом, она использует молоток, который уже держит в руках (Мэтт Паркер). Но, оглядываясь назад, она осознает это. Она овладевает многими приемами и методами тестирования в различных формах (памятные карты, контрольные списки и т.д.) для разработки, выполнения, приоритезации и анализа тестов в различных контекстах. Она знает, что тестирование — это не талант, а набор навыков, которым можно научиться. Она также связывает тестирование с другими дисциплинами — например, физикой, математикой, историей, философией, общественными науками. Это позволяет ей расширить свой набор навыков — решение проблем, моделирование, разговорная речь, критическое мышление и прочее. Таким образом, она действует как хамелеон, способный быстро адаптироваться к новой или незнакомой среде
★ Алиса действует как критик
Алиса знает, что набор моделей (например, моделей риска, моделей требований, диаграмм архитектуры), которые она использует при тестировании, — это всего лишь набор идей о ПО. Она знает, что эти модели — не ПО; это скорее абстрактные представления ПО. Она использует эти модели, чтобы с помощью несложных понятий разобраться с определенными аспектами сложного ПО. Также эти модели нужны, чтобы формировать предположения, принимать решения и сообщать о своих выводах. Она осознает тот факт, что эти модели являются упрощением ПО, и понимает, что простота не предшествует сложности, а следует за ней (Алан Перлис).
Итак, она размышляет над своими догадками, решениями и выводами, рассматривая альтернативные модели. Она знает, что эти модели могут являться ошибочными представлениями ПО, основанными на ее ошибочной ментальной модели ПО. Таким образом, она ведет себя как собственный лучший критик, который ставит под сомнение свои собственные модели при тестировании, чтобы не быть одураченной ими.
★ Алиса действует как астроном
Алиса знает, что тестирование ПО — это больше, чем просто проверка его спецификации. Она не просто сравнивает реальное ПО с его спецификацией, но также сравнивает идею ПО с реальным ПО и с его спецификацией. Алиса знает, что цель любой программы — решить чью-то проблему. Таким образом, она также оценивает цель ПО, поскольку знает, что проверка цели ПО является одной из целей тестирования. Она понимает, что соответствие спецификации практически не имеет значения, если программа решает неправильную проблему. Таким образом, она действует как астроном, который не только использует микроскоп для оценки ПО с точки зрения всех деталей (техническая сторона), но также использует телескоп, чтобы оценить ценность ПО с глобальной (концептуальной) точки зрения.
★ Алиса действует как историк
Алиса знает, что тот, кто не может извлечь уроки из истории, обречен повторить ее (Джордж Сантаяна). Таким образом, она размышляет о своих ошибках, выявляет закономерности неудач и извлекает из них ценные уроки. Она не отрицает своих ошибок и не скрывает их. Она документирует эти ошибки и рассказывает о них другим (например, тестировщикам, разработчикам), проводя регулярные ретроспективные сессии (например, ежемесячно). Поступая так, она учится на своих ошибках и позволяет другим извлечь пользу из усвоенных ею уроков. Прежде чем приступить к новым задачам (проект, релиз, спринт) она размышляет над ошибками, чтобы не повторить их. Она знает, что профилактика лучше лечения. Таким образом, она действует как историк, который формирует культуру обучения, анализируя свои прошлые процессы, чтобы постоянно улучшать настоящие и будущие процессы.
★ Алиса действует как наставник
Алиса знает, что качественное тестирование никогда не проводится одним человеком изолированно, а требует коллективных умственных способностей группы людей. Она знает, что представление о том, что у одного человека есть ответы на все вопросы, глубоко ошибочно. Она понимает, что знания могут быть разными. Поэтому она ищет источники потенциальной поддержки через различные совместные действия (например, парное тестирование, тестирование толпы). Таким образом, она действует как гид или наставник, который активно вовлекает, направляет и консультирует других людей (например, владельцев продуктов, разработчиков) в тестировании, стимулируя их постоянно критически относиться к программному обеспечению, которое они представляют, проектируют и создают.
★ Алиса действует как реалист
Алиса знает, что для тестирования всегда необходимо гораздо больше времени по сравнению с тем, сколько времени на него отводится. (Джем Канер). Поэтому она умеет расставлять приоритеты в работе, поскольку понимает, что этот процесс должен быть конечным, несмотря на то, что он никогда не заканчивается по природе своей. (Майкл Хантер). Она осознает, что не может доказать корректную работу программы, а может доказать только, что она функционирует неправильно. Алиса принимает тот факт, что не может ответить на вопрос «Все ли ошибки найдены?». Она понимает, что не может оценить количество отсутствующих ошибок, поскольку знает, что тестирование может доказать только наличие ошибок, но не их отсутствие (Эдсгер Вайбе Дейкстра). Таким образом, Алиса действует как реалист, который знает, что тестирование ПО невыполнимо до конца, потому что проблема поиска всех ошибок в ПО неразрешима.
★ Алиса действует как исследователь
Алиса знает, что тестирование — это про обучение. Когда у нее заканчиваются идеи для тестирования, она не исключает того, что, вероятно, недостаточно узнала о ПО. Она продолжает исследовать и экспериментировать, чтобы подтвердить эту догадку, и никогда не перестает изучать ПО и его область применения (бизнес, технологии). Алиса знает, что тестирование — это экспериментальная наука. Она считает тестирование скорее адаптивным исследованием, чем фабричным процессом создания, автоматизации и выполнения тест-кейсов. Она знает, что успех ее теста определяется не количеством тест-кейсов, а качеством ее идей. Таким образом, она действует как экспериментатор, который не путает тестирование с тест-кейсами. Алиса рассматривает тесты как эксперименты, чтобы опровергнуть гипотезы, предположения и мнения о ПО.
★ Алиса действует как заинтересованная сторона
Алиса знает, что тестирование означает сравнение невидимого с неопределенным (Джеймс Бах). Она знает, что знания, цели и опыт заинтересованных сторон не идентичны ее. Она знает, что круг заинтересованных сторон огромен, но не устает изучать риски как для внутренних, так и для внешних заинтересованных сторон. Она учитывает, как внутренние заинтересованные стороны (например, владельцы продуктов, разработчики, продавцы, маркетологи) будут оценивать на риски, которые она обнаруживает. Алиса связывает риски с их целями и потребностями. Она также изучает риски с точки зрения внешних заинтересованных сторон (например, клиентов, партнеров).
Чем лучше она начинает разбираться в ПО, тем труднее становится общаться с новичками (например, с конечными пользователями). Следовательно, она старается представить себя на месте конечного пользователя, чтобы не забыть, что значит быть новичком. Так, она немного отходит от роли тестировщика, чтобы принять во внимание точки зрения различных заинтересованных сторон, рассматривая риски с их точек зрения. Алиса поступает так, потому что знает, что эти разные точки зрения помогут ей по-разному оценивать ценность ПО и влияние угрозы на ПО. Таким образом, она думает, как заинтересованная сторона, чтобы расширить свое представление о том, как оценивать риски и определять приоритеты, чтобы получить более широкую картину общего профиля риска
★ Алиса действует как ребенок
Алиса знает, что не может ожидать ответов на вопросы, которые не задавала. Она не боится выглядеть «глупо», задавая простые вопросы. Она понимает, что тесты — это вопросы, которые она задает ПО, чтобы получить о нем полезную информацию (Джем Канер). Прежде чем что-то предположить, она задает вопросы, чтобы не допускать непроверенных убеждений. Она не боится не знать чего-либо. Алиса знает, что любопытство — это топливо для тестирования. Таким образом, она ведет себя как любопытный маленький ребенок, который никогда не перестает спрашивать, потому что знает, что хорошее тестирование требует правильных вопросов.
★ Алиса действует как бухгалтер
Алиса знает, что если у нее нет вопросов о рисках, связанных с ПО, то нет никаких причин для тестирования. Если такие вопросы есть, она задумается: будут ли ответы стоить больше, чем проведение тестов? Таким образом, она действует как бухгалтер, поскольку понимает, что хорошее тестирование подразумевает баланс между необходимостью снизить риски и риском собрать слишком много информации (Джеральд Вайнберг).
★ Алиса действует как скептик
Алиса знает, что ей не следует верить всему, что слышит, и только половине из того, что видит (Эдгар Аллан По). Она знает, что фактов не существует, есть только интерпретации фактов (Фридрих Ницше). Она знает, что уверенность абсурдна. Итак, она критически относится к тому, что ей сказали о ПО. Она скептически относится к тому, что знает о ПО, и знает, что никогда не узнает всего. Она не ограничивается тем, что знает сейчас, но и сосредотачивается на том, чего она пока не знает. Она продолжает думать, несмотря на то, что уже знает что-то.
Следовательно, Алиса считает тестирование мыслительной деятельностью и относится к ней как к таковой. Она знает, что ей нужно изменить свое мышление, чтобы изменить процесс тестирования. Программа — как хитрый обманщик, который все время пытается обмануть ее тем или иным способом; поэтому она остается осторожной, любопытной и критичной, чтобы ее не обманывали снова и снова. Таким образом, она действует как скептик, потому что знает, что хорошее тестирование требует непрерывного критического мышления.
★ Алиса действует как друг
Алиса знает, что основная цель тестирования — информировать других людей (например, владельцев продуктов, разработчиков) о проблемах в ПО. Она знает, рассказывать людям о проблемах — это социально трудная задача из-за естественного желания людей избегать неприятностей (Майкл Болтон). Она понимает, что проблемы кажутся на первый взгляд чем-то исключительно негативным. Она же рассматривает проблему как отклонение от желаемого. Чем больше этот разрыв, тем серьезнее проблема. Чем больше проблема, тем больше она может угрожать ПО.
Она достаточно разумна, чтобы понимать, что разные люди по-разному (иногда иррационально) реагируют на потенциальные угрозы. Есть люди, которые сложно воспринимают критику или не ценят точку зрения других людей. Есть люди, которые считают себя ответственными за свои ошибки, а есть те, кто этого не делает. Она помнит, что все люди разные по своей природе. Таким образом, она изучает личности людей и их взаимоотношения, чтобы научить их осознавать проблемы беспристрастно.
Алиса понимает, что если не донесет до людей факт существования проблем, эти проблемы в конечном итоге дадут о себе знать. Поэтому она сообщает о проблеме без промедления, сдержанно и с сочувствием. Она говорит прямо, но без осуждения. Она рассказывает о негативных вещах в позитивном ключе, потому что видит в проблемах возможность исправиться. Она знает, что не занимается дизайном, программированием и продажами. Но она пытается помочь другим людям понять, какое ПО у них есть на самом деле, чтобы они могли решить, такое ли ПО им нужно (Майкл Болтон).
★ Алиса действует как рассказчик
Алиса описывает статус ПО с точки зрения того, что оно делает, как работает и как может не работать. Также она описывает, что было протестировано, что еще не было проверено и что, вероятно, не будет протестировано из-за ограничений (например, время, ресурсы, бюджет). Она описывает качество тестирования с точки зрения достигнутых успехов и препятствий, которые помешали ей провести тестирование. Таким образом, Алиса ищет проблемы, которые угрожают ценности ПО и самому процессу тестирования. Проблемы процесса тестирования могут помешать ей найти проблемы в самом ПО. Она рассказывает о тестировании, приводя полезную и практическую информацию, вместо того, чтобы бомбардировать заинтересованных лиц тщеславными метриками (например, количеством тестовых случаев). Таким образом, она действует как рассказчик, который понимает, что тестирование должно быть не только проведено, но и описано.
★ Алиса действует как помощник
Алиса знает, что не может гарантировать качество так же, как врач не может гарантировать здоровье (Майкл Болтон). Она понимает, что ее основная цель — собрать информацию, связанную с качеством (например, риски), чтобы позволить другим людям (например, владельцам продуктов, разработчикам) принимать более обоснованные решения (например, решения по доставке, решения по исправлению) на основе информации, которую она предоставляет. В общем, она тестирует, а другие решают. Алиса понимает, что тестирование — это наука, основанная на информации (Кейт Клейн). Таким образом, она считает себя помощником, который не гарантирует качество, а скорее оказывает качественную помощью.
Этот список можно продолжать и продолжать. Он не завершен и вряд ли когда-либо завершится. Этот рассказ стоит на плечах этих гигантов. Они знают путь, идут этим путем и показывают путь превосходного тестирования ПО.