суббота, 20 июля 2013 г.

Мысли об основах тест дизайна

< Предыдущее сообщение по теме обучения: Мысли об основах тестирования
> Следующее сообщение по теме обучения: Техники анализа классов эквивалентности и граничных значений

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




Определение тест дизайна

Итак, что такое тест дизайн?
Тут все кажется просто – это разработка или придумывание тестов.

Тест можно определить как эксперимент, направленный на проверку какого-то предположения или гипотезы.

Давайте приведем пример: что такое гипотеза, что такое тест, проверяющий гипотезу, что такое разработка тестов.

Предположим, мы видим черный ящик и не знаем, что внутри:

Мы можем выдвинуть несколько гипотез или предположений о том, что находится внутри ящика:
  • В ящике пусто
  • В ящике лежит мяч
  • В ящике лежит кот
Чтобы проверить каждое предположение, мы можем провести несколько экспериментов (тестов):
  • Поднять и взвесить
  • Послушать
  • Потрясти
  • Открыть
Каждый тест либо подтверждает, либо опровергает наше предположение.

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

Можно провести аналогию с тестированием программного продукта. Гипотезы, которые мы можем проверять в этом случае:
  • Программа работает неправильно
  • Программа работает правильно
  • Программа удобна
  • Программа работает быстро

И возможные тесты по проверке будут такими:
  • Проверить работу одной функции
  • Проверить работу другой функции программы
  • Проверить работу интерфейса
  • Измерить время отклика программы на действия пользователей

Цели тест дизайна

Можно выделить главные цели тест дизайна: 
  1. Придумать тесты, которые обнаружат наиболее серьезные ошибки продукта. Да, мы можем придумывать тесты, которые находят несерьезные ошибки, но тогда тестирование будет неэффективным. 
  2. Минимизировать количество тестов, необходимых для нахождения большинства серьезных ошибок. Мы может придумать столько тестов, сколько не в состоянии будем выполнить. Поэтому перед разработчиками тестов всегда стоит задача – сохранить эффективность тестов (то есть их способность обнаруживать серьезные ошибки) без увеличения их числа.
Задачи тест дизайна

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


Например, в эту категорию входит:
  • Написание тест кейсов
  • Оценка и анализ рисков (то есть проблем, которые могут быть при использовании продукта)
  • Создание списка приемочных проверок для нового функционала
  • Анализ требований

Навыки тест дизайнера 

Разработка тестов – это непростое и длительное занятие, которое требует серьезного погружения.

Если говорить о навыках, необходимых тест дизайнеру, можно выделить:

  • Умение разделять систему на составляющие (делать декомпозицию). То есть, нужно уметь видеть систему как целое, но и уметь раскладывать ее на составные части. Это очень полезный навык для проведения функционального тестирования, где проверяется каждая фича продукта.
  • Умение собирать и анализировать требования к продукту. Если нет формально описанных требований – нужно уметь их собирать у разработчиков, у аналитиков, у пользователей.
  • Умение расставлять приоритеты. Тест дизайнер должен уметь отличать более важное от менее важного, и расставлять приоритеты тестирования.
  • Умение формулировать свои мысли (письменно и устно). Это умение важно для тестировщика в принципе. Тест дизайнеру оно здорово поможет при создании тест кейсов.
  • Знание техник тест дизайна. Основные техники мы коротко обсудим в этом сообщении.
  • Умение применять их на практике.

Важный вопрос, который мог у вас возникнуть: необходимо ли тестеру знать, что такое тест дизайн, и уметь разрабатывать тесты?

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

Техники тест дизайна 

Давайте подробнее рассмотрим техники тест дизайна.

Что это такое? Это способ создания тестов.

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

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

Давайте перечислим несколько основных техник тест дизайна:
  • Разбиение на классы эквивалентности (это метод сокращения числа тестов путем выбора одного теста из эквивалентного набора)
  • Анализ граничных значений (это метод проверки переменных программы на их границах)
  • Функциональное тестирование (это проверка всех функций продукта, одна за одной)
  • Тестирование на основе сценариев использования (это проверка продукта по наиболее частым и важным сценариям использования – use cases)
  • Тестирование на основе рисков (это проверка важных проблем, которые могут возникнуть)
  • Unit-тестирование
  • Регрессионное тестирование
  • Тестирование безопасности
Техник разработки тестов очень много, и каждый тестировщик может придумать свою технику.

Например, есть довольно забавные техники:
  • Партизанское тестирование – попытка найти ошибки в некоторой области программы, причем тесты выполняются быстрые и вредоносные.
  • Есть еду своей собаки – когда продукт используется внутри самой компании, в повседневной работе.
  • Тестирование глупой обезьяны – беспорядочное автоматическое тестирование, когда с клавиатуры вводятся случайные числа и мышь кликает по случайным местам экрана.
  • Тестирование мыльной оперы – (http://www.logigear.com/logi_media_dir/Documents/Soap_Opera_Testing.pdf) – когда проверяются слегка усложненные и расширенные сценарии реального использования. Главное в одном сценарии проверить как можно больше всего, как в мыльной опере, в которой в одной серии может произойти столько событий, сколько умещается во всей жизни.

Классификация техник

А как можно классифицировать техники?

Считается, что каждая техника может заключать в себе рекомендации по семи вопросам: 
1.       Что тестируется?
2.       Насколько тщательно?
3.       Кем тестируется?
4.       Какие проблемы ищутся?
5.       Как тестируется?
6.       Как оценивается результат тестов?
7.       Есть ли определенная цель тестирования?

Но каждая техника обычно дает ответы не на все вопросы, а на 2-3. Остальные нюансы оставляет на наше усмотрение, то есть на усмотрение тех, кто будет ее использовать.

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

Давайте для примера рассмотрим несколько техник, которые дают нам ответы на некоторые вопросы, но оставляют нам свободу выбора по остальным.

  • Функциональное тестирование. Техника говорит нам, что нужно тестировать функции (фичи) продукта, одну за одной, по очереди. Причем она рекомендует тестировать все функции. Насчет остального (кто выполняет тестирование, какие проблемы ищутся, как мы тестируем, как определяем результат тестов) – мы решаем сами. 
  • Бета тестирование. Техника говорит нам, что тестирование лучше проводить в выделенной группе пользователей. Остальные вопросы – на наше усмотрение. 
  • Unit-тестирование. Техника говорит нам, что тестируется каждая функция кода, тестирование обычно проводится программистом, тесты выполняются автоматически. Остальное (какие проблемы ищут unit-тесты, насколько они покрывают код) – мы вольны решать сами.

Техники черного и белого ящика

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

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

Однозначно сказать, какие техники (белого или черного ящика) лучше – нельзя. ИМХО, самый хороший вариант – комбинировать эти техники, от этого тестирование может стать намного эффективнее.

Исследовательское тестирование

Мне бы также хотелось рассказать вам о двух подходах к тестированию:

  • Исследовательском (эксплоративном) тестировании
  • Тестировании по тест кейсам

Их очень часто противопоставляют друг другу в литературе по тестированию.

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

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

Обычно тестировщик, занимающийся ET (exploratory testing, исследовательское тестирование), не имеет четкого сценария тестирования. У него есть цель, но все, что нужно для достижения этой цели – он определяет сам. Такое тестирование обычно слабо структурировано, предоставляет тестеру много свободы. Оно не очень удобно для оценки тестового покрытия, то есть определения того, что мы уже протестировали.

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

Тестирование по тест кейсам

Теперь давайте рассмотрим второй подход, который очень популярен во всем мире – тестирование по тест кейсам (Scripted testing):

Это подход к тестированию, который предполагает формальное описание тестов в форме чеклистов или тест кейсов.

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

Что такое тест кейс?

Раз уж мы заговорили о тест кейсах, давайте обсудим, что это такое.

Типичный тест кейс состоит из следующих частей: 
  • Цель. То есть, смысл тест кейса, что мы в нем проверяем.
  • Предварительные шаги (опционально). Содержит список шагов, которые нужно выполнить до начала теста.
  • Шаги. Это описанный по шагам алгоритм выполнения теста. 
  • Ожидаемый результат (или результаты). Раздел, который содержит описание поведения продукта, которое мы должны наблюдать после выполнение шагов теста. По ожидаемому результату мы обычно определяем, прошел продукт тест или не прошел.


Также мы упомянули чеклисты. Что это?

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

Плюсы и минусы эксплоративного тестирования и тестирования по сценариям

Давайте рассмотрим плюсы и минусы исследовательского тестирования и тестирования по сценариям.

Исследовательское тестирование: 



  • Хорошо развивает навыки, дает тестеру больше свободы
  • Не требует времени для написания тестовых сценариев, все время уделяется тестированию
  • Поощряет изучение тестером продукта
Но:

  • Неопытным тестерам в первое время бывает трудно из-за того, что они предоставлены сами себе, у них нет хотя бы примеров тестов, которые нужно выполнять
  • Без тест кейсов сложнее оценить тестовое покрытие
  • Изучение продукта отнимает время от непосредственного тестирования

Тестирование по сценариям: 

  • Требует меньше навыков от тестера, который выполняет тесты
  • Дает возможность легче оценить тестовое покрытие
  • Стабильность и неизменяемость тест кейсов дает возможность проследить качество продукта с течением времени
  • Обеспечивает более структурированный подход к тестированию
  • Как правило, выполнение тестов не требует дополнительных исследований и общения с разработчиками, аналитиками, работы со спецификациями, что дает выигрыш по времени
Но:

  • Тестирование по тест кейсам ограничивает свободу тестера
  • Формирует привычки в тестировании, потому что тестер привыкает делать такие проверки, как описаны в тест кейсах 
  • Тест кейсы потихоньку теряют свою эффективность и перестают находить баги
  • Постоянное выполнение одних и тех же тестов со временем утомляет
  • Требует много времени на поддержку тест кейсов: обновление, удаление, исправление
  • Тестер медленно развивает свое знание продукта и его контекста по сравнению с исследовательским тестированием
У обоих подходов есть плюсы и минусы. Отсюда можно сделать вывод:

Лучше всего комбинировать эти два подхода вместе: использовать и исследовательское тестирование, и тестирование по сценариям.

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

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

Но что-то новое в раздел литературы по тест дизайну я бы добавил:

  • Practitioner’s Guide to Software Test Design (Lee Copeland) – очень полезная книга по тест дизайну. Она понятным языком описывает основные техники тест дизайна, собранные из разных источников. Рекомендую, написано интересно! 
  • http://www.testingeducation.org/BBST/testdesign/ - сайт одного из курсов по обучению тестированию. Здесь есть видео, слайды лекций, статьи по тест дизайну. Рекомендую тем, кого не смущает английский язык.

Спасибо за внимание! Надеюсь, было интересно. Буду рад выслушать ваше мнение в комментах.

12 комментариев:

  1. На мой взгляд, автор блога спутал понятие "техника тест-дизайна" и "вид-метод тестирования" (в отношении, например, перечисленных после анализа граничных значений)...Также (насколько поняла из других разных источников - книги, блоги, видео) - описанный тут вид тестирования - скорее Ad hoc (а не исследовательское). Есть исследовательское тестирование с написанием тест-кейсов...

    ОтветитьУдалить
    Ответы
    1. Спасибо, что подняли очень интересный вопрос!

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

      Что касается видов и методов тестирования с одной стороны и техник тест дизайна с другой - мне кажется эти понятия очень похожи и грань между ними найти сложно.

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

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

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

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

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

      Удалить
  2. Исследовательское тестирование определение - 'одновременное выполнение и разработку тестов, а также изучение продукта.' - нигде нету ни про отсутствие тест кейсов ни про отсутствие плана. В исслежовательском тестировании документации иногда должно быть даже больше чем в кейсовом. И тестирование происходит по очень даже чёткому плану. Документация ввиде отчётов, чек-листов и тд может оформляться позже. Всё зависит...

    Исследовательское тестирование отличаетса от кейсового только одним - длиной степа. В кейсовом - изучаешь требования пол дня, потом проводишь тест дизайн день, пишешь кейсы, получаешь функционал, тестишь, анализируешь, всё это занимает 2-3 дня, первый фидбек дня через полтора. В исследовательском - изучаешь 15 минут требования, час намечаешь приблизительный план тестирования и вперёд - степ 5-10 минут - требование, тест, выполнение, анализ. А потом уже после цикла - оформление документации. Первый фидбек - через час-два.

    ОтветитьУдалить
    Ответы
    1. Спасибо, насчёт длины степов согласен с вами - исследовательское тестирование скорее имеет короткие итерации (позволю себе сравнить его с гибкими методами разработки). Тестирование по кейсам больше похоже на водопад, когда итерации создания тестов, их выполнения, анализа результатов обычно более длительные.

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

      Удалить
  3. Так же соглашусь с первым комментарием, что зря Вы замешали в одну кучу техники и виды(типы) тестирования. Вы советуете отличную книгу по тест-дизайну (Practitioner’s Guide to Software Test Design), но не упоминаете оттуда множество разных техник(например pairwise или диаграмма состояний), а вместо этого замешиваете сюда "бета" и другое тестирование. Это хорошо так сбивает с толку.

    Особенно бросаются в глаза некоторые моменты:
    "Функциональное тестирование. Техника говорит нам, что нужно тестировать функции (фичи) продукта, одну за одной, по очереди." - Почему Вы решили что именно по очереди? Как определить очередность?
    "Техника говорит нам, что тестирование лучше проводить в выделенной группе пользователей. Остальные вопросы – на наше усмотрение." - в какой группе каких пользователей? Получается если дать готовый продукт который уже выпустили на рынок, какой-то фокус-группе это будет считаться бета-тестированием? Бета тестирование привязывается к циклу разработки ПО и основывается в первую очередь на версии продукта, а не на группе пользователей.

    Вот посмотрите например перечень техник тест-дизайна от ISTQB:
    http://istqbexamcertification.com/wp-content/uploads/2011/12/testing-techniques1.jpg

    ОтветитьУдалить
    Ответы
    1. Евгений, спасибо за ваш комментарий! Вы дали мне повод еще раз задуматься о техниках и видах тестирования. Признаться, раньше я путался в том, что есть техника и что есть вид тестирования. Сейчас все более менее уложилось у меня в голове, но я понимаю ваше замешательство. Мне тяжело понять, как можно выполнять какой-то вид тестирования без использования соответствующей ему техники по созданию тестов. Был бы признателен, если бы вы поделились своим мнением, в чем отличие техники тест дизайна и вида тестирования.

      В курсе BBST, например, даётся такое определение техники тестирования: это метод разработки, выполнения и интерпретации результатов тестов.

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

      А про pairwise я ещё расскажу :-)

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

      В разговоре про бета тестирование я старался раскрыть мысль о том, что все техники дают нам рекомендации по одному-двум вопросам из списка (что тестируется, как глубоко тестируется, каким способом тестируется, кто проводит тестирование, какие проблемы ищутся, как оценивается результат тестов, какая конкретная цель у тестирования). И я привёл пример техники бета тестирования, которая, как мне кажется, прежде всего отвечает на вопрос "кто проводит тестирования". Кстати, эта классификация техник приведена в книге Lessons learned in software testing, отрывок из неё можно взять здесь - http://www.testingeducation.org/BBST/testdesign/KanerBachPettichord_Lessons_Learned_in_SW_testingCh3-1.pdf (забыл не упомянуть в Литературе).

      Ещё раз спасибо за ваш коммент, без него я бы не знал о слабых местах своего тренинга.



      Удалить
    2. Есть виды тестирования и есть техники.

      1. Виды тестирования это классификация тестов по определенному признаку. Допустим по степени готовности продукта это альфа\бета тестирование. Или по степени понимания системы (черный, белый, серый ящики)

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

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

      В стандарте BS 7925-1 указано что "5.191 test case design technique: A method used to derive or select test cases." т.е. это методика формирования и выбора тест-кейсов.
      В ISTQB используется почти такое же определение: "test design technique: Procedure used to derive and/or select test cases."
      Оттуда же: The purpose of a test design technique is to identify test conditions, test cases, and test data

      У компании Luxoft есть курс, видео которого есть на youtube, по техникам тест дизайна. Можно посмотреть слайды и лучше понять как классифицируются техники: http://www.luxoft-training.ru/upload/iblock/1a2/test_design_techniques_luxoft.pdf это практически тоже самое, что написано в книге Practitioner’s Guide to Software Test Design (Lee Copeland)

      Удалить
  4. Евгений, вот об этом я в самом начале и пыталась сказать)) Что это разные термины - техника и вид. Только я новичок и не смогла привести такие доводы 0:-) Заинтересовалась последней ссылкой - скачала для ознакомления (хотя переводы основных техник из этой книги уже изучала из одного из блогов, но там были не все)

    ОтветитьУдалить
  5. Да, действительно, у Люксофта классификация похожа на Коупленда :-)

    Мне кажется, мы с вами просто должны найти пересечения моих источников с вашими. Техники тест дизайна, похоже, означают у вас и у меня примерно одно и то же. Но вот по видам тестирования - у меня остаются непонятки.

    Давайте попробуем на примерах разобраться.

    Евгений, я правильно вас понимаю, что бета тестирование - это вид тестирования, который предполагает проведение тестирования на определённой стадии? То есть это не техника тест дизайна?

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

    ОтветитьУдалить
    Ответы
    1. Да, все верно, бета тестирование это проведение тестирования(разного рода, от функционального до нагрузочного) когда продукт на стадии беты.
      Все что нам дает понятие "бета тестирование" это стадия на которой мы тестируем продукт. Техника же должна отвечать на три вопроса как я писал выше. Вы правильно поняли, что "виды тестирования не дают нам рекомендаций по созданию тестов, поэтому мы не можем их использовать без техник тест дизайна". Они дают рекомендацию по выбору тестов, которые мы пишем с использованием различных техник.
      Я считаю, что основной вопрос на который отвечает вид тестирования это "Что тестировать", т.е. продукт на определенной стадии разработки, код, производительность, какие-то функции, безопасность и т.п.. У техники основной вопрос "Как", как выбрать значения для теста, как уменьшить кол-во тестов и не потерять эффективность и т.п.
      Видов тестирования гораздо больше чем техник, вот тут например перечислены около сотни http://www.softwaretestingsoftware.com/all-types-of-software-testing/

      Удалить
    2. Спасибо большое! Кажется я понял и теперь могу сказать, чему соответствуют наши понятия.

      В источнике (материалы курса BBST Test Design), который я использовал, техникой тестирования называют понятие, которое объединяет в себе:
      - И метод разработки тестов (техника тест дизайна)
      - И метод выполнения тестов
      - И метод анализа результатов

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

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

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

      Удалить
    3. Да, в Вашем случае техника тестирования куда более общее понятие чем техника тест дизайна. Просто в контексте данной заметки используется именно "техника тест дизайна", что и смутило.

      Удалить