niv тестирование что это
Регрессионное тестирование на Scrum-проектах: руководство по проведению
Согласно отчету The State of Agile Report («О развитии методологии Agile»), 95% опрошенных компаний разрабатывают программное обеспечение по Agile.
Во-первых, гибкая методология позволяет выпускать качественный продукт быстрее конкурентов за счет тестирования в каждом спринте. Во-вторых, с ее помощью можно легко внести изменения в ПО благодаря тесной коммуникации между заказчиком и участниками проекта.
При этом тесты регрессии остаются одними из наиболее частых проверок перед релизом новой функциональности. Как выполнять их эффективно, особенно если время на тестирование ограничено всего одним спринтом, зачастую составляющим 2 недели? Что делать, если нужно внести изменения в функциональность продукта на поздней стадии спринта?
В этой статье мы ответим на эти вопросы, а также расскажем о том, как проводить регрессионное тестирование на Scrum-проектах и уверенно преодолевать возникающие сложности.
Регрессионное тестирование в Scrum-среде
Регрессионные проверки играют одну из ключевых ролей в тестировании полного цикла и помогают добиваться следующих целей:
повышать общее качество и стабильность ПО благодаря снижению вероятности критических ошибок при его использовании и многократному уменьшению числа дефектов к моменту релиза;
ускорять доставку решения на рынок, уменьшая время прогона тестов за счет автоматизации;
сокращать расходы на подготовку продукта к релизу с помощью раннего обнаружения дефектов и применения автоматизации.
На Scrum-проектах регрессионные проверки особенно важны, поскольку помогают командам сконцентрироваться на новой функциональности, обеспечив при этом корректную и непрерывную работу ПО с каждым новым инкрементом продукта.
Таким образом, QA-специалисты могут быть уверены в том, что доработки никак не повлияли на уже существующую функциональность.
Топ-5 распространенных проблем и способы их преоделения
При проведении регрессионного тестирования на Scrum-проектах важно сфокусироваться на двух аспектах.
Первый ― определить функциональность, затронутую изменениями в коде. Если это неочевидно, необходимо проверять всю функциональность и соответственно раньше начинать тестирование в спринте, чтобы уложиться в сроки. Однако если можно безошибочно установить затронутые изменениями модули, работа станет более таргетированной, что сократит время на QA.
Второй ― выбрать проверки, которые можно автоматизировать. Важно помнить, что использовать автоматизацию уместно не во всех случаях. Особенно это касается GUI-проверок, где малейшие правки в дизайне приложения приводит к пересмотру тест-кейса с нуля.
Автоматизированные проверки подойдут для более стабильной функциональности, которая изменяется редко. А при нехватке времени поможет проактивный подход. Например, разработчики, инженеры по автоматизированному и функциональному тестированию работают над новой функциональностью в параллели и покрывают всё автоматизированными тестами в ходе одного спринта.
Но даже при должном понимании влияния изменившихся функций на приложение в целом и объема автоматизации, Scrum-команды могут столкнуться с рядом сложностей. Давайте перечислим их и рассмотрим, как можно решить.
Возрастающий объем регрессии
На крупных проектах с каждым новым спринтом объем регрессионного тестирования может увеличиваться. Чтобы эффективно им управлять, важно пересматривать тест-кейсы и удалять устаревшие. Делать это стоит по возможности и в зависимости от частоты вмешательства в релизы. Кроме того, это первый звонок, что уже можно и нужно внедрять автоматизацию.
Недостаточная коммуникация между участниками проекта
Специалистам по тестированию, бизнес-аналитикам, разработчикам и руководителям проекта стоит непрерывно взаимодействовать друг с другом. Так они смогут лучше понять объем работ и обеспечить эффективность процесса, начиная с подготовки тестовой документации и заканчивая пониманием того, какая функциональность больше не нуждается в регрессионном тестировании.
Поддержка тестовых сценариев
С увеличением числа тест-кейсов, будь то автоматизированные или функциональные, их поддержка усложняется. Чтобы минимизировать их обслуживание, важно больше коммуницировать с бизнес-аналитиками, которые знают взаимосвязи в бизнес-логике продукта и могут выявить несоответствия в тест-кейсах в случае внесения изменений.
Частые доработки функциональности
Смоделируем ситуацию: на проекте возникли непредвиденные и объемные изменения в требованиях к функциональности продукта. Еще и в конце спринта. Что делать? Да, сроки имеют значение, но важно позаботиться о качестве и оценить, сколько времени займет перезапуск тестов с учетом входной информации, чтобы расширить спринт и перенести дату релиза.
Ложноположительные результаты тестов
Причина может заключаться в некорректной разработке автоматизированного тест-кейса. Исключить подобную вероятность поможет валидация инженером по функциональному тестированию, который проходит тест-кейс по шагам и проверяет соответствие ожидаемому результату. Кроме того, в спринтах стоит закладывать время на интуитивное (ad hoc) и исследовательское (exploratory) тестирование, чтобы максимально расширить тестовое покрытие.
Тестируем регрессию на Scrum-проекте: о чем важно помнить
Для эффективного проведения регрессионного тестирования на гибких проектах важно приступать к созданию тестовой документации еще в самом начале разработки и в дальнейшем непрерывно обновлять ее в зависимости от входящих требований.
Что еще нужно учитывать? Предлагаем рассмотреть 5 шагов, от которых напрямую зависит результативность регрессионного тестирования.
1. Подготовить план тестирования
Этот этап включает в себя подбор необходимых тест-кейсов, их дальнейшее улучшение и доработку, оценку времени создания и выполнения регрессионных тестов, валидации дефектов и разработки финального отчета. Важно также определить тест-кейсы, которые в дальнейшем можно будет автоматизировать. Кроме того, на начальном этапе работ при взаимодействии с разработчиками проводится анализ того, какие модули могут быть затронуты изменениями, чтобы уделить этим областям больше внимания при тестировании.
2. Создать доску регрессии
Все задачи, над которыми работают QA-инженеры Scrum-команды, располагаются на доске в порядке сверху вниз по приоритетности в зависимости от возможных рисков, важности для клиента и ряда других факторов. Переставляя элементы на доске, команда всегда будет понимать актуальность задач и сможет планировать свое время так, чтобы укладываться в сроки.
3. Анализировать отчеты о дефектах
Так QA-команда сможет получить подробную информацию о проведении регрессионных тестов: причины их невыполнения, шаги тест-кейса, на которых произошла ошибка, снимки экрана. Все это поможет быстрее выявить проблему и устранить ее.
4. Добавить исследовательское тестирование
С его помощью инженеры по тестированию по-новому взглянут на проект, расширят тестовое покрытие и обнаружат дефекты, которые могли бы оказать сильное влияние на конечного пользователя разрабатываемого продукта.
5. Настроить модель коммуникации на проекте
Например, непрерывное взаимодействие специалистов по тестированию с владельцами продуктов способствует своевременному отслеживанию изменений в требованиях. В то время как коммуникация QA-инженеров с разработчиками ― получению информации о внесенных в ходе итерации изменениях.
Заключение
Регрессионное тестирование позволяет минимизировать риски сбоев в работе программного продукта после внесения изменений.
В ходе регрессионного тестирования на Scrum-проектах команды сталкиваются с рядом сложностей, которые можно решить благодаря:
обеспечению непрерывной коммуникации между участниками проекта;
поддержке документации в актуальном состоянии;
расширению спринта в случае внесения изменений в функциональность перед релизом;
валидации автоматизированных тест-кейсов.
Чтобы эффективно организовать процесс тестирования, важно:
создать план выполнения регрессии;
использовать доску регрессии;
тщательнее работать над ошибками;
не забывать о преимуществах исследовательского тестирования;
обеспечить открытое взаимодействие между участниками проекта на всех уровнях.
Подобный подход поможет гарантировать качество и стабильность ПО, несмотря на непрерывные доработки, и обеспечить слаженную работу Scrum-команд.
Регрессионное Тестирование (Regression Testing)
Ты хочешь понять, что такое регрессионное тестирование, зачем оно нужно, почему про него говорят все тестировщики и при чем здесь автоматизация?
Тогда ты в правильном месте 🙂
В этой статье отвечаю на самые частые вопросы, связанные с этим типом тестирования.
Как обычно, начинаем с определений.
Что такое регрессионное тестирование?
Регрессионное тестирование (regression testing) это проверки ранее протестированной программы, выполняющиеся после изменения кода программы и/или ее окружения для получения уверенности в том, что новая версия программы не содержит дефектов в областях, не подвергавшихся изменениям.
Regression testing — testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. [ISTQB Glossary]
Regression Testing является одним из двух видов тестирования, связанных с изменениями. [ISTQB FL]
Зачем нужно регрессионное тестирование?
Регрессионное тестирование необходимо для получения уверенности, что изменения ПО не коснулись и не сломали другие, не измененные, части ПО.
Здесь возникает вопрос: “Каким образом изменения одной части ПО могут сломать другие?”
Ответ: это загадка природы 🙂
В мире не бывает идеальных вещей и все мы ошибаемся. ПО и программисты — не исключение.
Иногда, непреднамеренно, разработчик делая исправление в коде может повлиять на части приложения, о которых он никогда не слышал и не представлял, что они существуют и связаны каким-то образом.
Особенно часто эта проблема проявляется в проектах с низким уровнем качества кода, плохой архитектурой и большим техническим долгом.
Фредерик Брукс в своей книге «Мифический человеко-месяц» (1975) писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50%) влечёт появление новой». [Куликов С., Базовый курс, 3-е издание]
Можно предположить, что в наше время вероятность появления ошибки — значительно меньше 20-50%, так как программы и среда разработки 1975 года сильно отличаются от современных.
Но, тем не менее, даже сегодня вероятность ошибки точно больше 0%.
Поэтому, регрессионное тестирование является ключевым инструментом обеспечения качества и должно использоваться практически на любом проекте.
Когда проводят регрессионное тестирование?
Регрессионное тестирование проводится после изменения кода программы (добавили / удалили / изменили) или изменения рабочего окружения (обновили версию PHP / Node JS / Java / Ubuntu / Windows / MySQL / MongoDB / переехали на новые сервера и т.п.)
Стоит отметить, что регрессионные тесты не нужно проводить после каждого изменения!
Например, вы изменили дату в футере сайта.
Нужно ли нам проходить 350 тест-кейсов и перепроверять весь сайт? — конечно же нет! Вы потратите свое время зря)
Такие исправления можно протестировать за 10 секунд используя самый простой чек-лист или сделав code review.
Если же такие исправления “ложат” / “ломают” сайт — вам срочно нужно задуматься о профессионализме разработчиков, это не нормально!
Или, другой пример. На одном из полей формы изменяется правило валидации: до этого максимальная длина строки равнялась 20 символам, а теперь нужно сделать 16.
Зачем после такой правки перепроверять весь сайт? (Вы не поверите, но существуют компании и команды, который до сих пор этим занимаются…)
Единственное, что нужно проверить — валидацию конкретно этого поля и, возможно, валидацию такого же поля на других формах (если они вообще существуют)
Если после изменения длины одного поля изменились правила валидации всех полей на сайте — поздравляю, у вас большие проблемы с профессионализмом разработчиков.
Вместо того, чтоб постоянно выполнять бесполезные проверки, лучше нанять более профессионального кодера. Через 2 месяца вы начнете экономить кучу денег.
При принятии решения о необходимости повторного тестирования вспоминаем принципы тестирования и задаем себе вопрос: ЧТО нам нужно проверять после этих изменений?
Какие плюсы регрессионного тестирования?
К плюсам можно отнести:
Выполнение повторного тестирования необходимо для анализа и улучшения качества продукта и рабочих процессов, чем, кстати, и занимаются настоящие QA Engineers.
Какие минусы регрессионного тестирования?
К минусам можно отнести:
Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки 🙂
Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…
Автоматизация и regression testing
Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]
На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.
Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать 🙂
Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)
Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…
Сравнение теоретического “до” и “после”:
Решили ли мы проблемы, описанные выше? — нет.
Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:
Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…
И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)
Парадокс автоматизации? Наверное, можно так сказать 🙂
Пытаясь уменьшить затраты — мы сделали их еще больше!
Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию.
Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:
Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂
говориМ о тестировании
простым языком
Виды тестирования по целям: тестирование, связанное с изменениями
Именно после таких правок продукт необходимо снова протестировать. Давайте посмотрим, как именно это можно сделать.
Разработчики постоянно вносят изменения в код. И порой эти изменения могут не только принести пользу (например, исправить баг), но и добавить еще больше проблем и багов, причем в самых неожиданных на первых взгляд местах. Тоже самое можно сказать в отношении добавления новых фич в уже работающий продукт. Всегда есть вероятность, что новый код повлияет на уже существующий и добавит в нем новые баги.
Как же проверить все эти внесенные изменения? Давайте разбираться.
Существует несколько видов тестирования, связанного с изменениями:
1. Подтверждающее тестирование (Re-testing)
2. Регрессионное тестирование (Regression Testing)
3. Дымовое тестирование (Smoke Testing)
4. Санитарное тестирование (Sanity Testing)
5. Тестирование сборки (Build Verification Test)
Давайте разберем их более подробно.
Подтверждающее тестирование (Re-testing)
Подтверждающее тестирование направлено на проверку исправления бага. Суть его в том, что после исправление дефекта программное обеспечение может быть протестировано с использованием тестовых сценариев, которые завершились с ошибкой из-за найденного дефекта. То есть на новой версии программного обеспечения должны быть повторно выполнены шаги по воспроизведению сбоев, вызванных дефектом.
Целью подтверждающего тестирования является удостоверение в том, что найденный дефект был исправлен.
Предположим, что мы тестируем сайт. Положили товар в корзину, пробуем увеличить его количество, но ничего не выходит. Далее оформляем баг-репорт и отдаем разработчикам. Они его пофиксили и настает время для подтверждающего тестирование. Нам необходимо убедиться, что дефект пофикшен. Значит, как минимум, нам необходимо проверить, что баг не воспроизводится по тем шагам, которые указаны в баг-репорте. То есть продуем снова увеличить количество позиций товара в корзине и смотрим, увеличивается ли оно или снова нет.
Регрессионное тестирование (Regression Testing)
Код связан между собой и одно исправление может повлечь за собой новые проблемы. Если вернутся к примеру с корзиной, то окажется, что количество стало меняться, а вот цвет товара изменить теперь не получается.
Случилось это из-за того, что «цвет» и «количество» обращались к одному участку кода, который и был поправлен.
Получается, что изменение, внесенное в одну часть кода, будь то исправление или что-либо другое, может случайно повлиять на поведение других частей кода. Такие непреднамеренные побочные эффекты называются регрессиями. А, соответственно, регрессионное тестированиенаправлено на обнаружение таких непреднамеренных побочных эффектов.
Давайте представим это визуально.
Есть продукт. Он состоит из множества различных частей.
В одной из частей был баг и разработчик его исправил. То есть были внесены изменения в одну из частей программы (на рисунке выделено зеленым).
Данные изменения могли тем или иным образом отразиться и на работе других частей продукта. На рисунке выделено красным.
Либо может быть ситуация, когда в продукте появляется новый функционал. И его работа может повлиять на старый.
То есть нам нужно проверить работу старого функционала после исправления старого кода и/или написания нового. В этом и заключается регрессионное тестирование.
Получается, что при подтверждающим тестировании мы проверяем сам баг, а при регрессионным тестирование не вызвало ли исправление бага или написание нового кода каких-либо изменений в других местах.
Дымовое тестирование (Smoke Testing)
Дымовое тестирование — тестирование, проводимое на начальном этапе и, в первую очередь, направленное на проверку готовности разработанного продукта к проведению более расширенного тестирования.
Данный вид тестирования определяет общее состояние качества продукта.
Это короткий цикл тестов, подтверждающий (отрицающий) факт того, что приложение стартует и выполняет свои основные функции. Проверки практически всегда одинаковы и редко претерпевают изменениям. Поэтому целесообразно их автоматизировать.
Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстро находимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным, и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным, и приложение уходит на доработку.
Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты.
Санитарное или Санити тестирование (Sanity Testing)
Относится к виду тестирования, которое используется с целью доказательства работоспособности конкретной функции или модуля согласно заявленным техническим требованиям.
Зачастую санитарное тестирование используют для проверки какой либо части программы или приложения в результате внесенных изменений на нее со стороны факторов окружающей среды. Выполнение его обычно происходит в ручном режиме.
Санитарное тестирование ориентировано на глубинное исследование определенной функции, а дымовое — на тестирование большого количества функционала за самые короткие сроки.
Тестирование сборки (Build Verification Test)
Направлено на определение соответствия выпущенной версии критериям качества для начала тестирования. По своим целям является аналогом дымового тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию.
Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Разница
Итак, на сегодняшний момент наши знания о видах тестирования выглядят следующим образом.
Niv тестирование что это
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Оксана Разина
Исследовательское тестирование — термин, применяемый в противопоставление сценарному подходу к тестированию. Думаю, нет нужды говорить, насколько потрясающих результатов можно достичь, совмещая оба этих подхода, но чаще всего у нас просто не хватает времени на развернутый анализ и полноценное проектирование тестов.
Именно поэтому наиболее удачным решением может оказаться выбор исследовательского тестирования в моно-варианте. Поскольку сам термин «исследование» подразумевает индивидуальную заинтересованность и вовлеченность в процесс, мы все сразу же задумываемся о подводных камнях данного подхода.
Конечно, говоря о тестировании, нельзя не упомянуть распространенные ошибки самих тестировщиков. Есть такой психологический момент: если не обозначены рамки, то начинает казаться, что можно делать всё, что угодно. И этот процесс будет называться тестированием. Многие начинающие тестировщики совершенно необоснованно думают, что «исследовательское» тестирование позволяет не соблюдать основные принципы тестирования.
Заказчики и их заблуждения
Исследовательское тестирование не контролируемо и не управляемо
Представим, что задание на тестирование получено. Мы радостно потираем руки в предвкушении интересной динамичной деятельности, и тут приходит менеджер и говорит: «Ребят, да вы что, с меня голову снимут за ваши эксперименты! А как мы отчитаемся по покрытию функционала тестами? А как вы время оцените?». Резонные опасения, не правда ли? Так мы узнаём, что нашему менеджеру не хватает уверенности в том, что мы сможем грамотно выстроить процесс тестирования и представить его результаты в надлежащем виде.
На самом деле это сомнение очень заботит многих людей, которым предстоит принимать важные решения по продукту на основании результатов тестирования. Спешу успокоить — на этот случай есть несколько эффективных алгоритмов:
Исследовательское тестирование — не для новичков
Итак, менеджер доволен, пора задуматься над тем, кто именно будет заниматься тестированием нашего продукта. Конечно, заинтересованные лица будут настаивать на выборе опытных членов команды, которые уже имели дело с подобным продуктом и способны сделать квалифицированные предположения об ошибках. Такая позиция говорит о восприятии исследовательского тестирования как процесса, в котором нет места начинающим специалистам.
В ряде случаев это может быть действительно так. Однако, если участников тестирования больше одного, с таким подходом можно и поспорить. В качестве примера расскажу случай из практики. К нам поступила срочная и неожиданная заявка на тестирование нового проекта — это была CMS (админка) для одного приложения. В качестве ресурсов у нас был один опытный тестировщик и один стажер. Мы решили сделать план админки и детализировать его с учетом предположений опытного тестировщика.
Затем приступили к работе. Опытный тестировщик уже имел представление о том, где могут скрываться неочевидные ошибки. Стажер же занимался изучением функционала с точки зрения обычного неопытного пользователя: его основной задачей было задавать как можно больше вопросов о том, что ему казалось непонятным. После получения ответов на вопросы мы пришли к выводам, что в системе много дефектов, предположить наличие которых опытный тестировщик мог не всегда. Ведь он был уверен, что этот функционал давно отлажен и стабилен.
Таким образом, вовлекая в процесс исследовательского тестирования менее опытных членов команды, мы можем взглянуть на продукт другими глазами: не в разрезе проверяемого функционала, а опираясь на возможности разных членов команды. К тому же сфера тестирования располагает различными подходами к исследовательскому тестированию:
Поэтому прелесть исследовательского тестирования заключается именно в его гибкости и возможности выстроить процесс таким образом, чтобы удовлетворялись нужды как проекта в целом, так и всех его участников.
Исследовательское тестирование не подходит для регрессионных проверок
Теперь подумаем о возможностях применимости исследовательского подхода к различным видам тестирования. Казалось бы, логика подсказывает, что применить исследовательский подход к регрессионному тестированию сложно.
Такое предположение не лишено оснований. Но для небольших проектов с более-менее очевидной функциональностью вполне можно заменить привычный набор тестовых сценариев небольшим чек-листом с основными частями функционала. Как раз в этом случае важна квалификация тестировщиков и их знание проекта.
У себя на проекте мы делаем так: составляем чек-лист и проводим регрессионное тестирование с опорой на него. Каждая строка чек-листа содержит ссылку на задачу по разработке функции в таск-трекере, чтобы можно было уточнить требуемое поведение в случае, если возникло ощущение, что что-то упущено. Это уже не исследовательское тестирование в чистом виде, но принципы подхода сохраняются и дополняются небольшими подсказками, помогающими двигаться в нужном направлении.
Тестировщики и их заблуждения
Исследование продукта с целью дальнейшего написания тестов — это и есть исследовательское тестирование
Многие скажут, что это утверждение верно, и будут по-своему правы, ведь исследование проводится и в том, и в другом случае. Я же думаю, что имеет смысл разделять понятия «тестирование» и «тест-анализ».
По сути, готовясь к написанию тестов, мы действительно проводим исследование: выполняем анализ имеющейся документации, продумываем стратегию, расставляем приоритеты — то есть, определяем, ЧТО и КАК будем тестировать.
Если говорить об исследовательском тестировании, то конечной целью этого процесса является ответ на вопрос: «Насколько наш продукт соответствует этим ожиданиям?» Да, мы тоже проектируем тесты на ходу, но это лишь часть глобального процесса. Разные цели — разный результат, так что не совсем уместно называть исследовательским тестированием только подготовку к написанию тестов.
Исследовательское тестирование базируется на идее беспорядочного выполнения различных действий
Здесь я имею в виду стремление некоторых тестировщиков «сломать» приложение во что бы то ни стало путем прокладывания безумных путей и введения во все доступные поля невалидных данных. В первую очередь, мы всегда должны думать о том, для кого предназначен продукт, какова основная цель той или иной его функциональности. Гибкость подхода предполагает возможность быстро найти критичные дефекты ключевых модулей. На этом и следует сосредоточиться в первую очередь.
Для исследовательского тестирования не нужна предварительная подготовка
Многие думают: Раз уж при выборе данного подхода чаще всего отсутствует документация, то и готовиться к тестированию не надо, требования сформируются сами собой в процессе тестирования. На самом деле, если не продумать базовую схему выполнения проверок и вовремя не выяснить возникающие вопросы, мы рискуем допустить ошибки как в оценке времени на тестирование, так и в понимании конечных целей работы нашего продукта. Я рекомендую потратить час-другой на то, чтобы вникнуть в проект и определиться с первичным набором тестовых данных и с приоритетами проверок.
Необязательно своевременно актуализировать статус проверок
Довольно часто тестировщики предпочитают проставлять отметки о проверенных функциях и указывать на выявленные дефекты не сразу, а в конце дня, воспринимая данный ритуал как отчет о собственной работе, а не о состоянии продукта. В качестве аргумента они приводят тезис о том, что при исследовательском подходе невозможно точно предсказать, насколько протестирована та или иная функция, потому что каждый последующий тест основан на результатах предыдущего.
Однако, очень важно иметь возможность получать актуальную информацию о стадии тестирования и его результатах в режиме реального времени, чтобы учесть возможные проблемы и вовремя скорректировать стратегию тестирования.
А напоследок я скажу…
Несмотря на различные проблемы, с которыми можно столкнуться, выбрав в качестве подхода к тестированию исследовательский метод, мы всегда имеем возможность получить в итоге все необходимые результаты тестирования. Для этого нужно чётко знать цели проекта и иметь поддержку в виде тесного сотрудничества с заинтересованными лицами. Главным же инструментом любого тестировщика является не какая-то конкретная методика, а критическое мышление, умение анализировать и синтезировать данные, применять накопленный опыт и подводить итоги.