Предугадывание ошибки тестирование - Исправление ошибок и поиск оптимальных решений проблем

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

Суть техники в том, что чтобы найти все способы, которые могут сломать тестируемый продукт.

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

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

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

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

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

Давайте посмотрим на конкретных примерах, как можно использовать этот метод.

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

Можно попробовать поставить его на другой объект

^{Ставим на другой объект}

2. Или за границу доступного поля

^{Ставим за границу доступного поля}

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

^{Ставим на воду}

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

^{Размещаем корову в курятник}

5. Или попробовать кур поместить на территорию вне курятника

^{Размещаем кур вне курятника}

6. Или попробовать зайти в магазин, пока покупаем кур

^{Заходим в магазин во время покупки кур}

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

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

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

^{Форма регистрации на сайте}

Мне на ум приходят вот какие варианты:

Указать e-mail c несуществующим доменом на конце.
Указать e-mail без знака «@».
Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
Снять галочку «Я принимаю условия Пользовательского соглашения».
Ввести неверные символы с картинки.
Оставить одно поле незаполненным.

________________________________

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

________________________________

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

Источник

Суть методики
Особенности
Что требуется, чтобы эффективно (пред)угадывать ошибки
Примеры
Преимущества и недостатки методики

Что это

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

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

Особенности

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

Методика направлена на поиск багов, не поддающихся другим методикам черного ящика. Поэтому стандартно выполняется уже после них.

Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:

Ввод некорректных (невалидных) параметров и символов
Например, ввод пробела в “цифровые” поля, где это недопустимо
Ошибка-исключение null pointer exception
Деление на ноль
Превышение максимального количества передаваемых файлов
И подобные «типичные пользовательские» ошибки

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

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

Что нужно, чтобы хорошо угадывать ошибки

Интуиция тестировщика
И его знание продукта
Опыт прошлых проектов
Чек-лист
Риск-репорты
Знание типичных проблем с интерфейсом
Идеальное знание общих принципов тестирования
Результаты предыдущих тестов
Характерные ошибки, случавшиеся ранее

Примеры предугадывания ошибок

Пример 1

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

Что случится, если ввести не цифру, а букву или пробел
Если ввести только 8 цифр
Если оставить поле пустым
Если ввести не 10, а 12 цифр

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

Пример 2

Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:

Значение	Результат
6000	ОК
5500	ОК
4000	Ошибка
7200	Ошибка
7400	Ошибка
8000	Ошибка
Пустое	Ошибка
100$	Ошибка
…	…
… и так далее

Преимущества и недостатки методики

Преимущества

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

Недостатки

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

***

Источник

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

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

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

Типы тестирования

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

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:

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

Этапы тестирования

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.

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

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

3. Анализ результатов и составление отчетов.

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

Техники тест-дизайна на примерах

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

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.

Таблица принятия решений

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

Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.

Пример таблицы принятия решений

Попарное тестирование

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

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.

Pairwise testing: пример

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:

№	Браузер	Операционная система	Язык
1	Opera	Windows	RU
2	Google Chrome	Linux	RU
3	Opera	Linux	EN
4	Google Chrome	Windows	EN

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

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

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

Примерный алгоритм использования техники:

1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.

Эта техника помогает:

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

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:

Что произойдет, если не ввести код?
Что произойдет, если не ввести спецсимволы?
Что произойдет, если ввести не цифры, а другие символы?
Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.

Итоги

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

Понравилась статья?

Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.

Источник

Software application is a part of our daily life. May be in laptop or may be in our mobile phone, or it may be any digital device/interface our day starts with the use of various software applications and also ends with the use of various software applications. That’s why software companies are also trying their best to develop good quality error free software applications to the users.

So when a company develops any software application software testing plays a major role in that. Testers not only test the product with a set of specified test cases they also test the software by coming out of the testing documents. There the term error guessing comes which is not specified in any testing instruction manual still it is performed. So in this article we will discuss about that error then error guessing, where and how it is performed. The benefits that we get by performing it. So let’s start the topic.

Actually an error appears when there is any logical mistake in code by developer. And It’s very hard for a developer to find an error in large system. To solve this problem Error guessing technique is used. Error guessing technique is a software technique where test engineer guesses and try to break the software code. Error Guessing technique is also applied to all of the other testing techniques to produce more effective and workable tests.

What is the use of Error Guessing ?

In software testing error guessing is a method in which experience and skill plays an important role. As here possible bugs and defects are guessed in the areas where formal testing would not work. That’s why it is also called as experience based testing which has no specific method of testing. This is not a formal way of performing testing still it has importance as it sometimes solves many unresolved issues also.

Where or how to use it ?

Error guessing in software testing approach which is a sort of black box testing technique and also error guessing is best used as a part of the conditions where other black box testing techniques are performed, for instance, boundary value analysis and equivalence split are not prepared to cover all of the condition which are slanted to error in the application.

Advantages and Disadvantages of Error Guessing Technique :

Advantages :

It is effective when used with other testing approaches.
It is helpful to solve some complex and problematic areas of application.
It figures out errors which may not be identified through other formal testing techniques.
It helps in reducing testing times.

Disadvantages :

Only capable and skilled tests can perform.
Dependent on testers experience and skills.
Fails in providing guarantee the quality standard of the application.
Not an efficient way of error detection as compared to effort.
Drawbacks of Error Guessing technique:
Not sure that the software has reached the expected quality.
Never provide full coverage of an application.

Factors used in error guessing :

Lessons learned from past releases.
Experience of testers.
Historical learning.
Test execution report.
Earlier defects.
Production tickets.
Normal testing rules.
Application UI.
Previous test results.

Error Guessing is one of the popular techniques of testing, even if it is not an accurate approach of performing testing still it makes the testing work simple and saves a lots of time. But when it is combined with other testing techniques we get better results. In this testing, it is essential to have skilled and experienced testers.

Источник

What is the use of Error Guessing ?

Where or how to use it ?

Advantages and Disadvantages of Error Guessing Technique :

Advantages :

It is effective when used with other testing approaches.
It is helpful to solve some complex and problematic areas of application.
It figures out errors which may not be identified through other formal testing techniques.
It helps in reducing testing times.

Disadvantages :

Only capable and skilled tests can perform.
Dependent on testers experience and skills.
Fails in providing guarantee the quality standard of the application.
Not an efficient way of error detection as compared to effort.
Drawbacks of Error Guessing technique:
Not sure that the software has reached the expected quality.
Never provide full coverage of an application.

Factors used in error guessing :

Lessons learned from past releases.
Experience of testers.
Historical learning.
Test execution report.
Earlier defects.
Production tickets.
Normal testing rules.
Application UI.
Previous test results.

Источник

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

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

Автоматизация
Отказ от формализации

И мы рассмотрим тему отказа от формализации, или, в данном случае, подход Experience-Based Testing.

Изначально, понятие тестирования, основанного на опыте не было, первоначально существовало только Исследовательское тестирование (Exploratory testing), о котором впервые упоминает Сэм Канер еще в далеком 1987 году в книге “Testing computer software”. Но постепенно, со временем появляются другие подходы к тестированию, основанные на опыте тестировщиков, которые в 2004 году международная организация IEEE в документе “IEEE: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society” объединяет в общий подход Experience-Based Testing.

Что же в себя включает Experience-Based Testing?

Стандартно (в том числе и в ISTQB), это 3 техники тестирования:

Error Guessing (предугадывание ошибок)
Checklist-based testing (тестирование на основе чек-листов)
Exploratory testing (тестирование методом свободного поиска или исследовательское тестирование)

Немного расскажу о них.

Предугадывание ошибок.

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

Немного отступлюсь…

Года 4 назад у меня был такой знакомый, который тестировал систему 5 лет. Так вот на вопрос, почему он все еще сидит и тестирует ее, он отвечал, что ему нравится работать там, где он все знает. Но его тест-кейсы были просто черт голову сломит “великолепными”. Каждый его тест состоял всегда из 3 шагов:

Что то открыть
Что то сделать
Что то проверить

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

Но это лирика, вернемся к теме…

Тестирование на основе чек-листов.

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

Визуально чек-лист выглядит вот так:

Ну и последнее и самое интересное – это исследовательское тестирование.

Есть брать определение из ISTQB, то исследовательское тестирование характеризуется тем, что тестировщик одновременно изучает продукт и его дефекты, планирует работы по тестированию, проектирует и выполняет тесты и отчитывается о результатах. Тестировщик постоянно корректирует цели во время выполнения тестирования и готовит только высокоуровневую документацию. Именно такое определение дал Джеймс Уиттакер в книге “Exploratory Software Testing”.

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

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

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

Поэтому, исследовательское тестирование:

Подчеркивает персональную свободу и ответственность тестировщика
Показывает индивидуальность тестировщика
Позволяет постоянно проектировать новые тест-кейсы по результатам работы

Очень подробно систематический подход к исследовательскому тестированию описывает Уиттакер, используя для этого подход с турами по различным объектам, таким, как “Тур по плохому району”, “Музейный тур” и т.д.

Звучит смешно. Но это действительно так!

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

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

Очень подробно система туров Уиттакера рассматривается в этой статье Система туров исследовательского тестирования.

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

Но возникает вопрос. А действительно ли достаточно обладать большим опытом, чтобы проводить исследовательское тестирование?

Возьмем опытного тестировщика, который уже большое количество времени проводит тестирование различных систем. Чем руководствуется в таком случае тестировщик? Опытом, интуицией или техниками тест-дизайна? Очень часто я сталкивался с тестировщиками, которые очень хорошо знали систему. Они понимали, где и как может возникнуть проблема, дефект, что нужно тестировать, а на что можно просто не обращать внимания, потому что “там никогда не возникает проблем”. Да, это опыт, это умение сократить тестирование за счет того, что тестировщик понимает, к чему может привести то или иное изменение кода, но тогда мы говорим уже не об исследовательском тестирования, а о Risk-Based Testing!

Что такое исследование?

Исследование – это систематическое расследование с целью установления фактов, т.е. это процесс изучения чего-либо.

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

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

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

– Раз так написали в ТЗ, значит так должно быть.

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

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

Спасибо за внимание! Надеюсь было интересно!

Источник

Кожна людина по-своєму унікальна: різний характер, поведінка і, звичайно ж, спосіб мислення. Тому, в силу цього чинника, в процесі розробки ПЗ неминуче будуть виникати різного роду дефекти і недоробки.

По суті, передбачення помилки в широкому сенсі – це все, що робить тестувальник при складанні тестових сценаріїв. Це словосполучення можна використовувати для опису всіх технік тест-дизайну. Адже основна мета цього процесу і полягає в тому, щоб визначити, в якому місці і за яких обставин з найбільшою ймовірністю може виникнути помилка, а також перевірити це в процесі тестування. Для тестувальника цей навик може стати відмінною підмогою в роботі. Щоб використовувати передбачення помилки в тестуванні, зовсім необов’язково мати досвід розробки ПЗ. Важливо розуміти базову логіку написання коду і розбиратися у вимогах, які будуть пред’являтися до кінцевого продукту. Далеко не зайвим буде і досвід в тестуванні схожих проєктів. Якщо ж немає такого досвіду — як варіант, можна скористатися допомогою колег, які успішно застосовують цю техніку у повсякденній роботі. Але найкраще, в такому випадку, сконцентруватися на інших, більш відчутних техніках складання тест-кейсів, які дозволять отримати надійніший результат.

Передбачення помилок як техніка тест-дизайну

Як правило, в процесі створення тест-кейсів застосовується далеко не одна техніка тест-дизайну. Це пов’язано з тим, що у кожної з них свої способи знаходження дефектів. Різні методи призначені для певного ряду завдань і дозволяють «виловити» нові баги.

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

Таке тестування є найбільш корисним в умовах відсутності або недостатньої кількості специфікацій і суворих дедлайнів. Але, як і інші техніки тест-дизайну, передбачення помилки має свої позитивні і негативні сторони.

До переваг цього методу можна віднести:

можливість використання на різних етапах розробки;
відсутність необхідності в формалізації, тобто зовсім необов’язково оформляти тест-кейси – досить просто виконувати потрібні перевірки, маючи лише доступ до готового продукту;
можливість застосування при нестачі часу.

Основний же недолік техніки передбачення помилки – покриття тестами. Якщо в ході застосування цього методу буде знайдено певну кількість помилок – неможливо гарантувати те, що весь функціонал був протестований. Наприклад, якщо був знайдений дефект верстки при зменшенні розміру вікна браузера – це не означає, що всі можливі баги верстки були виявлені. Тому, саме через відсутність повного охоплення об’єкту тестами, передбачення помилки зазвичай застосовується в поєднанні з іншими техніками тест-дизайну.

Застосування методу на реальних проєктах

Залежно від характеру і специфіки продукту, передбачення помилки може виглядати по-різному. Найпростіший приклад при тестуванні будь-якого веб-сайту: якщо вимкнути виконання Javascript у браузері, то напевно що-небудь зламається. Нижче буде наведена лише незначна частина поширених помилок розробників, які можна виявити в процесі тестування.

Сортування. Тестуючи цією функцією, необхідно враховувати поширену помилку серед розробників, коли числа «10», «11», «12» і так далі до числа «19» виявляються між числами «1» і «2». Таким чином, масив виводиться в такому вигляді:
1
10
11
12
…
19
2
20
Тому при тестуванні подібних масивів не варто обмежувати діапазон даних, що вводяться одним десятком.

Продовжуючи тему масивів, можна згадати про сортування розмірів при тестуванні інтернет-магазинів. Тут досить часто зустрічається помилка, при якій сортування універсальних розмірів відбувається за алфавітом:

L, M, S, XL, …
Тоді як правильно вибудувати в порядку збільшення розміру:
XXS, XS, S, M, L, XL, …

«У мене в браузері все працює». Як правило, в зв’язку з нестачею часу, розробники використовують для тестування своїх продуктів тільки один браузер. Далеко не завжди його версія збігається з тією, яка є пріоритетною на проєкті. Також розробка часто відбувається на MacOS, де стандартом вважається браузер Safari, а поновлення Chrome виходять з невеликим запізненням. Через це також можуть виникати помилки, так як різні браузери можуть інакше обробляти один і той же код. Рішення просте — уточнити пріоритетність кожного браузера і виконати тест-кейси для кожного з них. Корисно тестувати сайт на декількох браузерах одночасно — так буде простіше помітити відмінності в поведінці.

Ігнорування обробки некоректних вхідних даних. Нерідкі випадки, коли розробники навмисно не витрачають час на продумування і впровадження станів, які, на їхню думку, неможливі. Але потрібно враховувати, що продуктом будуть користуватися люди з самим різним мисленням, і вони можуть вводити в систему найрізноманітніші дані, які будуть некоректно оброблятися. У цьому випадку завдання тестувальника – передбачити всі можливі варіанти поведінки користувача і перевірити їх.
Наприклад: в Україні номера телефонів мобільних операторів складаються з 12 символів, тому розробник обмежує довжину поля для введення телефону до 12. Але якщо поле не містить попередньої розмітки (рисок і дужок), то користувач може вводити номер телефону самими різними способами:

380yyxxxxxxx: цей варіант буде прийнятий системою, так як був передбачений розробником;
+380yyxxxxxxx: через символ «+» номер не пройде валідацію, так як довжина поля перевищує очікувану;
380 yy xxxxxxx: якщо поле вважає прогалини як окремі символи – тут вже 14 символів, а не 12;
380-yy-xxxxxxx/380(99)xxxxxxx: ситуація аналогічна до описаної вище.

У зв’язку з величезним вибором продуктів і підходів до розробки ПЗ, помилки можуть бути різними. Їх всі необхідно знайти і усунути. Головною перевагою техніки передбачення помилки слід зазначити відсутність необхідності складання тестових сценаріїв. Саме тому застосовувати цей метод можна вже на самих ранніх етапах розробки, або коли час строго обмежений, і навіть коли немає специфікації. Але успішність застосування цієї техніки безпосередньо залежить від рівня професійної підготовки тестувальника на різних проєктах.

Источник