ТОП-6 книг книг для тестировщика

Что изменилось

Перемены в продуктовых командах шли по-разному и затронули разные стороны процесса. В одной из команд тестирование сначала стало узким местом: оно требовало времени, и не все понимали, что же происходит на этом этапе. В виде эксперимента мы подключили разработчиков к запуску тестов, в результате чего они смогли прочувствовать работу тестировщиков и даже увидеть продукт в целом – не отдельную функцию построения отчета, например, а весь путь от авторизации пользователя в продукте и проведения бизнес-операций до итога – выгрузки отчета.

В другом продукте с нашей помощью изменился релизный цикл. Изначально было устроено так, что результаты спринта уходили в тестирование в пятницу после обеда, а в понедельник продукт уже попадал к заказчику. На тестирование и исправление критических ошибок оставался самый конец пятницы и лишь начало понедельника, и в итоге новая версия нередко выходила «сырой» или же разработчикам приходилось срочно фиксить баги в выходные.

Окончательное решение, меняться или нет, остается за командой: именно она отвечает за продукт и его выход, поэтому она и выбирает наиболее удобный для себя вариант. Цель нашей работы – не в том, чтобы навязать программистам свои подходы, а в том, чтобы дать максимум информации о возможных рисках и предложить подходящие продукту улучшения и действия.

Что удалось сделать нашему отделу тестирования за прошедший год:

Изменения всегда сложны, но они необходимы, если мы болеем за наши продукты. И именно тестировщики могут внести значительный вклад в обеспечение качества продуктов.

В следующих материалах я с коллегами расскажу, как мы тестируем конкретные продукты, о выборе стратегии тестирования, об инструментах (например, Allure Enterprise edition – удобное средство для управления тестированием, формирования отчетности и даже управления автотестами), о том, как внедряем автоматические тесты в пайплайн и какие варианты развития видим (Test Driven Development, если вы подумали о нем, это только один из возможных вариантов ).

«перевернутое» мышление и бремя доказывания

Мой первый руководитель сказал мне как-то: «когда тестируешь приложение, просто предположи, что баги есть. Если ты изначально отнесешься к приложению так, что оно работает правильно и без ошибок и попытаешься найти их, то много ошибок не найдешь. Ты будешь видеть то, что ожидаешь увидеть. И наоборот, если ты будешь предполагать, что баги есть, то внезапно заметишь их повсюду».

Этот небольшой совет идеально передает идею «перекладывания бремени доказывания». Начинать тестирование следует с предположения, что приложение не работает. Фактически, оно вероятно и не может работать. Даже помыслить нельзя, что оно работает.

Удерживая это в памяти, заставьте приложение доказать, что вы ошибаетесь. Заставьте его выполнять все действия и демонстрировать нужное поведение, пока ему не удастся убедить вас в обратном, что это никакая не подстава. Чудо из чудес, но это действительно работающий софт.

Сформулируем по-другому: приложение должно считаться виновным, пока не доказано обратного.

Хорошие тестировщики относятся к приложению «перевернутым» образом мышления — они изначально исходят из точки наихудших предположений. Можно назвать это здоровым скептицизмом, конструктивным пессимизмом, или иным термином, но суть в том, что изначально мы исходим из предположения, что приложение не работает.

Когда мы стартуем из этой точки и фокусируемся на том, что приложение должно доказать нам обратное, это помогает преодолеть естественную предвзятость подтверждения и помогает хорошим тестировщикам обнаружить баги, которые могли остаться незамеченными для других.

Нельзя сказать, что инверсионное мышление является специфическим для тестирования, у него есть свои сторонники во всем, от математики до инвестирования. Этому может научиться каждый (даже самые оптимистичные разработчики!)

Презентуем наши улучшения руководителям команд и заинтересованным лицам, делая акцент на том, какие проблемы решат эти улучшения

Процесс пойдёт проще, если заручиться поддержкой команды. Важно «продать» свою идею, показать, какой профит принесут предложенные вами изменения. Например, критерии приемки, которые мы упоминали выше, могут выглядеть как дополнительная работа для аналитика, но когда команда понимает, какую экономию времени она получит – а это от часов до дней, которые могут уходить на уточнение задачи, – то принимает улучшение намного легче.

В некоторых случаях можно действовать через владельца продукта. Например, продукту не хватает мониторинга (допустим, технического, с логами и красивыми графиками) и на настройку нет времени, ведь это не продуктовая задача. В таком случае можно обратиться к продакту и пояснить, какие именно выгоды он получит от мониторинга (стабильнее сразу не станет, но вырастет скорость локализации проблем), и попросить его выделить на это ресурсы.

Параллельно со стандартизацией работы в продуктовых командах идёт проработка подходов к тестированию, которые обеспечивают качество продуктов, например, оценка и подготовка необходимых объемов тестовых данных, проработка тестовой модели, формирование точек будущей автоматизации и т.д.

Всегда есть вероятность, что команда не примет предлагаемые изменения, какими бы разумными они вам ни казались. В каждом отдельном случае необходимо формировать свои подходы и искать индивидуальный способ убеждения. Продукты очень разные, и подходы, работающие в одном продукте, совсем не работают в другом.

Многие команды уверены, что способны сами организовать свою работу, и иногда это действительно так. Были случаи, когда наше участие сводилось к рекомендации основных точек проверки, и дальше команда прекрасно все реализовывала на уровне кода, а мы просто оставались рядом, всегда готовые помочь.

Гибкое тестирование. практическое руководство для тестировщиков по и гибких команд

Интуитивное мышление и исследовательское поведение

Если тестирование можно было бы свести к простому списку действий, тестировщики были бы не нужны. И даже если бы оно могло быть сокращено до предсказуемого, предопределенного набора шагов, основанного на ограниченном наборе входных параметров (критерии приемки и SUT, например), необходимости в тестировщиках все равно не было бы.

Тестирование — это нелинейная, непредсказуемая деятельность. Она требует развитого критического и креативного мышления и предполагает участие интуиции и чутья в той же мере, как и выполнение действий по алгоритму. Природа тестирования зачастую исследовательская — на старте вы не знаете точно, куда придете. Хорошие тестировщики принимают интуитивную и исследовательскую природу тестирования.

Чтобы лучше понять, что мы имеем в виду, приведем противоположное мнение, которое, к сожалению, до сих пор еще встречается в некоторых кругах: «Тестирование — это проверка приведенного списка приемочных критериев с помощью составления тест-кейсов с использованием техник граничного анализа, классов эквивалентности, комбинаторных техник и других формальных стратегий по созданию тест-кейсов. Как только готов полный список тест-кейсов, тестер прогоняет их и записывает, какие прошли, а какие нет.»

Для тех, кто придерживается подобного мнения, тестирование представляется простым и предсказуемым набором действий. Написание тест-кейсов еще требует каких-то навыков, но тестировать по этим пошаговым инструкциям сможет каждый. Однажды продумав тест-кейсы, вы точно знаете, что будете тестировать, еще до начала.

Как я сказал ранее, этого мнения до сих пор придерживаются некоторые представители индустрии. И я точно не знаю, почему, ведь большинство людей с реальным опытом тестирования совсем не поддерживают эту точку зрения. У меня есть догадка, что некоторым менеджерам это может нравиться потому, что так тестирование можно свести к деятельности, которую легко сделать общедоступной — что можно разделить на части и распределить между наименее «дорогими» участниками проекта.

Я мог бы еще страниц двадцать писать об исследовательской и интуитивной природе тестирования, но многие опытные тестировщики уже сделали это. Я горячо рекомендую «Исследуй это!» авторства Элизабет Хендриксон и «Исследовательское тестирование программного обеспечения» Джеймса А. Уиттакера.

Лайза Кристин и Джанет Грегори тоже затрагивают эту тему в книгах «Гибкое тестирование» и «Еще более гибкое тестирование», но в рамках более широкого обсуждения роли тестировщика в Agile-командах. И, наконец, Майкл Болтон и Джеймс Бах часто пишут на эту тему с большим неравнодушием. В особенности рекомендую к прочтению вот эту статью.

Неважно, назовем мы это глубоким тестированием или структурированным исследовательским тестированием или любой другой фразой. Что действительно важно, так это то, что для тестирования требуется мышление в реальном времени, а направление и активности тестирования должны постоянно пересматриваться по мере поступления новой информации. Это не алгоритмическое экстраполирование критериев приемки и не может быть рассчитано заранее.

Как тестировщику, вам должно быть комфортно начинать свое путешествие без полной карты того, куда вы идете. Этот аспект непредсказуемости и неопределенности некоторых беспокоит, но я также обнаружил, что хорошие тестировщики, наоборот, добиваются результатов благодаря ему.

Нужна ли гибким командам стратегия тестирования?

Давайте сначала посмотрим на основную работу по обеспечению качества в гибких проектах, как показано на рисунке ниже.

Тогда вы можете спросить: «Привет, почему нет контента, связанного со стратегией тестирования?» Фактически весь процесс разработки и тестирования отражает содержание стратегии тестирования. Итеративный процесс разработки, показанный на рисунке выше, включает в себя действия по тестированию «Автоматизированные приемочные тесты», «Тестирование истории» и «Системное тестирование», так зачем проектам эти действия по тестированию?

В рамках модели гибкой разработки итеративная разработка имеет характеристики короткого цикла и высокого давления доставки.Так как быстро реагировать на новые требования, обеспечивать качество новых требований и регрессионное тестирование реализованных требований, все это будет испытательным испытанием.

Если не существует соответствующего контекста проекта и разумной стратегии планирования планирования действий по тестированию, эти проблемы будут продолжать преследовать команду, поэтому, конечно, необходим ответ на заголовок. В рамках гибкой модели разработки стратегия тестирования может более разумно использовать ресурсы тестирования и унифицировать восприятие проекта тестированием, детально определив тестовые действия проекта.

Кроме того, стратегия тестирования также является важной частью гибкой системы обеспечения качества проектов.

Определение стратегии тестирования

Давайте посмотрим на Википедию оtest strategyОпределение

A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used and occasionally, conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.

Резюмируя вышеприведенные определения, мы можем сделать вывод, что конечная цель стратегии тестирования состоит в том, чтобы максимально раскрыть и устранить дефекты продукта и снизить риски, связанные с продуктом, путем определения действий по тестированию, которые будет использовать проект.

Кроме того, поскольку разработка программного обеспечения часто сопровождается давлением доставки, время и ресурсы тестирования не могут быть гарантированы и даже могут быть сжаты, поэтому стратегия тестирования будет начинаться с наименьших затрат и подвергать риску качества продукта и выбирать наиболее приемлемый метод тестирования. И процесс тестирования.

Определите цели качества

Прежде чем думать о том, «как измерить», нам нужно определить качественные цели проекта. Эта цель в области качества позволит согласовать понимание и ожидания всего соответствующего персонала проекта с точки зрения качества проекта и прояснить, что область качества – это область действия стратегии тестирования.

В то же время, цель качества также должна быть согласована с целью продукта, потому что конечная цель качества – обеспечить успех продукта. В зависимости от того, имеет ли продукт разные цели на разных этапах, цели качества будут меняться соответственно.

Как установить целевой показатель качества? В основном обращайтесь к списку характеристик качества программного обеспечения и модели качества программного обеспечения, чтобы установить модель качества продукта в соответствии с контекстом проекта, определив тем самым цель качества проекта.

Чтобы установить модель качества продукта проекта, сначала необходимо узнать, каковы качественные атрибуты или характеристики программного продукта и какова соответствующая модель качества. К счастью, уже есть много моделей, на которые можно ссылаться

Модель качества ISO / IEC_25010 выглядит примерно следующим образом:

Из приведенного выше списка или модели характеристик качества видно, что качество программного продукта состоит из множества характеристик или стандартов качества, и каждая функция качества может быть дополнительно разложена на подфункции. Эти существующие модели качества используются для определения того, какие характеристики качества важны для продуктов проекта и какие стандарты качества применимы к продуктам проекта, и, наконец, получается модель качества продукта, которая соответствует контексту проекта.

Например, модель качества продукта, которую мы создаем, может содержать следующие грубые особенности:

1. Функциональность
   • Степень завершенности
   • точность
   • Interoperability
   • эффективность
   • совпадение
2. Производительность
   • Использование ресурсов
   • пропускная способность
   • выносливость
3. Безопасность
   • сертификация
   • авторизация
   • Конфиденциальность
4. Совместимость
   • Приложение совместимо
   • Совместимость с ОС
   • Аппаратная совместимость
   • Обратная совместимость
5. Доступность
   • Легко обучаема
   • Простота эксплуатации
   • доступность
6. Надежность
   • стабильность
   • прочность
   • восстанавливаемость
   • Обработка ошибок
   • Целостность данных
7. Ремонтопригодность
   • Масштабируемость
   • ремонт
   • Construct
8. Переносимость
9. Возможность установки
   • конфигурация
   • Обновление удалить

Приведенная выше модель качества определяет характеристики и стандарты качества продукции, и именно эти характеристики и стандарты являются тем, чего мы должны достичь! В дополнение к модели качества, упомянутой выше, некоторые конкретные метрики также могут быть введены, чтобы гарантировать качество проекта и стать частью целей качества проекта. например

Упомянутые выше стандарты могут быть достигнуты с помощью качественных инструментов или сред тестирования, интегрированных в конвейер непрерывной интеграции.

Кроме того, некоторые команды будут также использовать формулировку цели стратегии тестирования для формирования командной культуры.

“To Constantly Deliver Working Software that Meets Customer’s Requirements”
by means of
“Providing Fast Feedback”
and
“Defect Prevention, rather than Defect Detection”

Определить тип теста

Теперь, когда у нас есть цель в области качества, мы должны подумать, как ее достичь! Другими словами, какие типы тестов мы должны выполнить для достижения каждой цели в области качества?

Существует много типов тестов в соответствии с различными размерами, например

1. На основании того, следует ли учитывать внутреннюю структуру и реализацию программного обеспечения
   • Тестирование белого ящика
   • Тестирование черного ящика
   • Тестирование серой коробки
2. В зависимости от того, выполнять ли программу
   • Статический тест
   • тест на динамику
3. На основе процесса тестирования

• модульный тест
• Интеграционное тестирование
• Тест дыма
• Функциональный тест (системный тест)
  • Разведочные испытания
  • Тест сцены
  • Тест потока
  • Тест домена
• Тест на совместимость
• Регрессионное тестирование
• Вступительный тест
• Тест производительности
  • испытание под давлением
  • Нагрузочный тест
• Тест безопасности

Конечно, вышесказанное является лишь частью списка.

Кроме того, HTSMTest TechniquesДевять универсальных методов тестирования предназначены для того, чтобы вдохновить вас на размышления о применимых типах тестов. Четыре квадранта гибкого тестирования также предоставляют типы тестов, на которые могут ссылаться гибкие проекты.

Возьмем в качестве цели качество, которое мы предполагали выше, давайте посмотрим, какие виды тестирования могут быть применены

Стоит отметить, что не каждый проект должен охватывать типы тестов, перечисленные выше. Мы должны выбрать соответствующий тип покрытия теста в соответствии с целями и характеристиками продукта и другими фактическими условиями, то есть широта тестирования для разных проектов различается в зависимости от типа теста.

Определить фазу теста

По этой ссылке нам нужно определить, какой тип тестирования проводить на каждом этапе жизненного цикла разработки проекта, чтобы тип тестирования полностью интегрировался в процесс разработки проекта, чтобы мы могли максимизировать влияние всех действий по тестированию для достижения наших целей в области качества.

На данный момент, на два вопроса «что тестировать» и «как тестировать» можно примерно ответить.

Отдельная стратегия для автоматического тестирования

Пирамида автоматического тестирования используется для руководства стратегией автоматического тестирования в гибких проектах.

Согласно теории пирамид, проект должен приложить больше усилий к базовому модульному тестированию и интеграционному тестированию (тестирование API).

Автоматизированные тестовые проекты будут интегрированы в конвейер непрерывной интеграции и автоматически запускаются вышестоящими проектами. Чтобы сократить время обратной связи при непрерывной интеграции, обычной практикой является размещение огромного набора автоматизированных наборов тестов в различных конвейерах в зависимости от важности и приоритета, которые могут запускаться вышестоящими проектами или через регулярные интервалы. :

1. Создайте конвейер развертывания, тесты, которые нужно выполнить для каждой сборки, и триггеры вышестоящего проекта -> модульное тестирование, тестирование интерфейса, тестирование дыма.
2. Отдельные тестовые задания, тесты, которые будут выполняться в последней стабильной версии каждый день, триггеры синхронизации -> Частичные функциональные регрессионные тесты, тесты производительности
3. Выпуск кандидата конвейер, каждый выпуск кандидата строит тесты, которые будут выполняться, запускаются с регулярными интервалами -> все функциональные регрессионные тесты, тесты производительности

Постоянное улучшение и анализ рисков

Как правило, после определения стратегии тестирования она не будет часто меняться, поскольку стратегия тестирования устанавливает некоторые стандарты тестирования. Если стандарты испытаний часто меняются, это затруднит реализацию конкретных планов и в то же время приведет к большему расходу ресурсов и в конечном итоге повлияет на качество проекта.

Мы часто сталкиваемся с «изменениями» в проектах: например,

• Изменения в объеме функций
• Изменения в деталях конкретной функции
• Изменения в фокусе теста
• Изменения, основанные на оценке риска

Влияние этих изменений на тестирование – это объем тестируемых объектов и развертывание ресурсов проекта. Это мало влияет на цели качества, типы тестов и этапы тестирования проекта. Поэтому, как только будет сформулирована стратегия тестирования, особых изменений не будет.

Однако это не означает, что стратегия тестирования является неизменной и не нуждается в улучшении. QA необходимо наблюдать за эффектом реализации стратегии тестирования на каждой итерации, чтобы определить, соответствуют ли текущие типы тестов и методы реализации требованиям проекта.

Например, когда интеграционное тестирование проекта (тестирование API-интерфейса) часто дает сбой, а координация отнимает много времени и является трудоемкой, QA может рассмотреть возможность использования контрактного тестирования вместо существующего интеграционного тестирования для повышения производительности и качества всей проектной команды, например, внезапного увеличения числа пользователей Internet Edge.

Также возникла производственная ошибка в Internet Edge: QA необходимо добавить Internet Edge в тест на совместимость и настроить соответствующую среду тестирования, например, процесс тестирования отстает, а давление доставки увеличивается. QA необходимо своевременно отрегулировать объем теста и фокус тестирования. Провести анализ рисков.

В реальных проектах часто возникают проблемы, препятствующие беспроблемной посадке и выполнению тестовых стратегий. Некоторые из этих проблем являются проблемами самой стратегии тестирования, но есть и проблемы, вызванные проектом. В настоящее время анализ рисков чрезвычайно важен.

Для анализа рисков стратегии тестирования это должно проходить через весь цикл формулирования стратегии тестирования. Нам нужно идентифицировать риски, которые могут блокировать тестирование в проекте, через список рисков проекта и передать приоритет риска (вероятность подверженности риску * потеря подверженности риску) )

Предварительный сбор информации о проекте

Как упомянуто выше, QA может собирать различную информацию из разных ролей.Кроме того, использование контекстной модели планирования эвристического тестирования и модели контекста планирования эвристического тестирования и модели стратегии эвристического тестирования также является эффективным каналом.

после анализаhtsmИспользуя ключевые слова и эвристику в «среде проекта» и «элементах продукта», QA может изучать все виды информации о продуктах и ​​проектах, чтобы помочь сформулировать стратегии тестирования.htcpmТакже предоставляется большое количество ключевых слов, чтобы вдохновить QA анализировать и понимать требования к продукту, среду проекта, команду тестирования и ресурсы для тестирования.

Информация, которую можно собрать, можно условно классифицировать следующим образом.

1. Информация о продукте
   • Бизнес цели
   • Видение продукта
   • Заинтересованные стороны
2. Деловая информация
   • Бизнес-процесс
   • Сфера деятельности
   • Бизнес-данные
3. Техническая информация
   • Технология Архитектура
   • Технологический стек
4. Информация о доставке
   • План доставки
   • Процесс развития
   • Архитектура развертывания
   • Непрерывная доставка
   • Онлайн мониторинг
5. Информация о команде
   • Организационная структура
   • Тестовые ресурсы

Только собрав достаточное количество информации о проекте из разных измерений и хорошее понимание влияния этой информации на качество проекта и деятельность по тестированию, мы можем избежать обходных путей и разработать стратегию тестирования, подходящую для проекта и команды.

Признание человеческой природы

Как тестировщик, вы занимаетесь тестированием программного обеспечения, но не забывайте о том, что программное обеспечение — это конечный продукт длительного процесса. Это результат совместной работы группы людей с целью создания чего-то большего и сложного, чем любой из них смог бы сделать в одиночку.

Дефекты в ПО не появляются сами по себе, из вакуума, они являются симптомами проблем в процессе. Поэтому вам, как тестировщику, следует обращать внимание на процесс разработки ПО и поведение пользователей столько же, как и на конечный продукт.

Если изучать человеческую природу, то вскоре можно понять, что люди далеки от запрограммированных роботов с идеальной памятью, неизменной мотивацией и всегда высоким уровнем внимания. На самом деле, всё совсем наоборот.

Люди иногда отвлекаются, что-то забывают, начинают скучать. Люди также расстраиваются, раздражаются и устают. А еще иногда завидуют успехам других. У каждого свои планы и жизненные цели, из которых разработка этого конкретного модуля приложения для этой конкретной компании, возможно даже не входит в топ-10.

Для кого-то мотивация лежит в области финансов, кто-то ориентируется на работу с крутыми технологиями, кого-то интересует определенная сфера, кто-то мотивируется признанием и социальным статусом, а ещё, по словам одного вымышленного персонажа, «Некоторые люди просто хотят наблюдать, как мир горит».

Кроме того, человеческое мышление является эвристическим и любит использовать короткие пути, а также имеет склонность придерживаться шаблонов, которые были полезны для выживания млекопитающих в Серенгети, но в меньшей степени для создания ПО. Бихевиористы называют это «когнитивными искажениями».

Например, люди склонны видеть и принимать доказательства, которые согласуются с существующими убеждениями (предвзятость подтверждения, confirmation bias); если мы уже вложили свое время и другие ресурсы во что-то, нам трудно изменить направление или отказаться от этого (ошибка невозвратных затрат, sunk cost fallacy); мы переоцениваем факты, которые приходят в нашу голову просто (ошибка доступности, availability bias); и мы фокусируемся на первом доказательстве (эффект привязки, anchoring bias). И это далеко не все примеры когнитивных искажений, их гораздо больше.

Все эти несовершенства человеческого поведения дают о себе знать в процессе разработки программного обеспечения точно так же, как и в остальном жизненном опыте. Они присутствуют, когда разработчики разрабатывают, бизнес-аналитики анализируют, топ-менеджеры реализовывают корпоративную стратегию, и когда менеджеры среднего звена… ну, менеджерят.

Когда начинаете тестировать продукт, помните о том, что вы сейчас смотрите на конечный продукт человеческой деятельности, страдающей от этих когнитивных искажений и других несовершенств. Ошибки, поиском которых вы занимаетесь, чаще будут их симптомами, нежели чем того, что разработчик просто неправильно реализовал алгоритм или требование. Знание и понимание человеческой машины, создавшей это ПО, поможет вам их обнаружить.

Подходите к тестированию с такой мысленной установкой, что разработка ПО по сути своей является беспорядочным сотрудничеством разных людей и страдает от всех обычных ошибок.

Разница между стратегией тестирования и планом тестирования

Чтобы сказать разницу, сначала посмотрите на разницу в определении.

Из вышесказанного видно, что содержание стратегии тестирования фактически включено в план тестирования. Стратегия тестирования определяет, какой тип тестирования должен быть выполнен, и план тестирования содержит всю информацию о том, как должна выполняться стратегия тестирования.Эта информация хорошо организована в плане тестирования.

Формула может дополнительно проиллюстрировать их отношенияtest plan = test strategy test logistics, Таким образом, стратегию тестирования можно рассматривать как часть плана тестирования.Test logisticsОтносится к настройкам тестовой среды, человеческим ресурсам и т. Д.

В блоге Джеймса БахаA Question About Test StrategyВ он описал три следующим образом

Test Plan: the set of ideas that guide a test project

Test Strategy: the set of ideas that guide test design

Test Logistics: the set of ideas that guide the application of resources to fulfill a test strategy

I find these ideas to be a useful jumping off point. Here are some implications:

The test plan is the sum of test strategy and test logistics.

The test plan document does not necessarily contain a test plan. This is because many test plan documents are created by people who are following templates without understanding them, or writing things to please their bosses, without knowing how to fulfill their promises, or simply because it once was a genuine test plan but now is obsolete.

Conversely, a genuine test plan is not necessarily documented. This is because new ideas may occur to you each day that change how you test. In my career, I have mostly operated without written test plans.

Сложные допущения

Эта фраза настолько часто используется, чтобы описать склад ума тестировщика, что уже стала клише и потеряла часть смысла. Сложные допущения — это не только про то, чтобы задаваться вопросом «Почему?» на все подряд, словно нетерпеливый пятилетний ребенок. Это предполагает нечто большее, и, как и всё остальное, это требует практики.

«Сложные допущения» не означает «оспаривай каждое допущение». Это также не значит «выброси все из окна и начни с нуля». Нам, тестировщикам, нет нужды быть Бертраном Расселом и расписывать на 360 страниц доказательство того, что 1 1 = 2.

На самом деле, для эффективного тестировщика критично важен навык определять и использовать допущения. Когда вы начинаете тестировать новую фичу непростого приложения, существует почти неограниченное количество возможных действий и путей тестирования, которые предположительно могут привести к обнаружению ошибки.

Допущения — это инструмент для сокращения проверок, допущения — полезны.

Важным навыком является способность точно оценить допущения, чтобы определить, корректно ли они влияют на ваше поведение, или они сбивают вас с пути. Являются ли они вредными или полезными; не позволяют ли они вам забывать про низкорисковые области в пользу более выгодного тестирования, или они прячут обоснованные опасения за мыслями вроде «нам не надо это тестировать» и «этого не могло произойти»?

Клише «сложные допущения» чрезмерно упрощает это — вы не оспариваете слепо допущения, вы используете все инструменты, которые есть в вашем распоряжении, чтобы лучше понять, какие допущения нужно оспорить, когда и как.

Например: «Наше приложение использует эту открытую библиотеку… Я не буду предполагать, что оно работает, я протестирую это тоже!» Скорее всего, это менее ценное допущение, которое можно оспорить, что будет тратой времени. Однако, немного поработать над этим вопросом будет вполне разумно (У нее уже миллионы пользователей или ее недавно создал какой-то студент?

Ум тестировщика находится в процессе постоянного распознавания и оценки допущений, с целью определить, являются ли они ценными, или вводят в заблуждение.

Тем не менее, не будьте уверенны, что вы все выяснили. 

Тест метрики

Как измерить эффективность стратегии тестирования? Метрики качества могут показать нам качество продукта и удовлетворенность пользователей и, таким образом, отразить, является ли стратегия тестирования эффективной и действенной.

Не существует лучших методов измерения качества программного обеспечения, ни наиболее точных и научных измерений. Некоторые из них являются просто успешным опытом, накопленным в проектах, но этот успешный опыт стал плохо пригодным для повторного использования из-за больших различий в проектах.

• Статистическое измерение дефекта
  • Скорость разрешения
  • Время разрешения
  • распределенный
  • Причина триггера
  • серьезность
  • приоритет
  • Тенденция изменения количества
• Уровень покрытия
  • Покрытие спроса
  • Карта покрытия AC Story
  • Покрытие кода
    • Функция покрытия
    • Количество используемых функций покрытия
    • Условия покрытия
    • Количество путей покрытия
  • Автоматизированное тестовое покрытие
    • Прошёл тестирование
      • Функциональная стабильность
    • Соотношение разных этапов развития
• Выполнение теста
  • Скорость выполнения теста
  • Скорость прохождения теста
• Количество и доля переделок истории карты
• Количество протестированных системных браузеров
• Обратная связь о принятии заказа

В то же время конкретная цель качества также является хорошим инструментом для качества проекта. Что касается модели качества, мы можем увидеть, достигли ли мы каждого элемента качества, а для конкретных показателей нам необходимо отслеживать обратную связь в любое время.

Тренинги по тестированию, сообщество тестировщиков

Все члены нашей команды могут тестировать тщательно, при условии, что они знают, как сделать это правильно (каждый может тестировать соответствующим образом, а не упрощенно, как это бывает). Наша обязанность состоит в том, чтобы обучить их конкретной деятельности по тестированию, освоить QA мышление, а также расширить их знания о продукции, чтобы сделать их лучшими тестировщиками.

Цель отдела тестирования — сделать это обучение возможным. Обсуждение и обмен опытом необходимы, например, путем создания сообщества тестировщиков. Это могут быть люди, заинтересованные в тестировании, а не только те, у кого тестирование является их основной специализацией. Люди этого сообщества могут встретиться, а затем поучиться друг у друга или пообщаться в чате или в wiki.

Рассмотрим сообщество тестировщиков. Вы можете создать обучающуюся организацию, которая поможет вашим тестировщикам обмениваться идеями и помогать друг другу. Предположим, что QA менеджер (“менеджер-учитель”) станет лидером практики в организации. В этом случае этот человек будет обучать навыкам, которые необходимы тестировщикам для того, чтобы стать сильнее и лучше справляться с постоянно меняющейся обстановкой.

“Менеджеры как учителя принципов бережливого мышления, проводящие время, обучая и тренируя других”.