- Суть методики
- Особенности
- Что требуется, чтобы эффективно (пред)угадывать ошибки
- Примеры
- Преимущества и недостатки методики
Что это
Техники тест-дизайна — это то, чем должен хорошо владеть каждый тестировщик, даже стажер. Наиболее часто применяемые техники: эквивалентные классы, анализ граничных значений, и предугадывание ошибок.
В данной методике (типологически относится к тестированию черного ящика) нет какого-то специфического метода идентификации ошибок. Тестировщик действует, исходя из своего опыта и интуиции, пытаясь предугадать проблемные места в приложении. Поэтому успешность этой методики сильно зависит от опыта и скиллов, и глубины понимания тестируемого продукта.
Особенности
Как уже сказано, эффективность зависит от опыта, особенно с похожими приложениями ранее. Поэтому лучше и быстрее с такой задачей справляются QA-инженеры с опытом 1 год и более.
Методика направлена на поиск багов, не поддающихся другим методикам черного ящика. Поэтому стандартно выполняется уже после них.
Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:
- Ввод некорректных (невалидных) параметров и символов
- Например, ввод пробела в “цифровые” поля, где это недопустимо
- Ошибка-исключение null pointer exception
- Деление на ноль
- Превышение максимального количества передаваемых файлов
- И подобные «типичные пользовательские» ошибки
Итак, цель предугадывания — найти ошибки, которые трудно “выловить” другими методиками черного ящика. Готовятся тест-кейсы, направленные на области наиболее вероятных ошибок; по возможности покрываются все проблемные места; но без избыточности.
Методика, разумеется, не является идеальной, способной обеспечить высокое качество — ведь она основана на интуиции, поэтому ограничена по умолчанию, зависит от умений и, главное, опытности QA-инженера. Она вовсе не гарантирует высокого покрытия, и должна сочетаться с другими методиками, дополнять их.
Что нужно, чтобы хорошо угадывать ошибки
- Интуиция тестировщика
- И его знание продукта
- Опыт прошлых проектов
- Чек-лист
- Риск-репорты
- Знание типичных проблем с интерфейсом
- Идеальное знание общих принципов тестирования
- Результаты предыдущих тестов
- Характерные ошибки, случавшиеся ранее
Примеры предугадывания ошибок
Пример 1
В приложении есть функция ввода номера телефона клиента, и он должен быть стандартной длины, то есть 10 цифр. Методика предугадывания ошибок в данном случае может проверить, например:
- Что случится, если ввести не цифру, а букву или пробел
- Если ввести только 8 цифр
- Если оставить поле пустым
- Если ввести не 10, а 12 цифр
Если такие невалидные значения введены, и функция ведёт себя как ожидается — то есть показывает ошибку, она расценивается как не имеющая багов; в противном случае заводится баг, и функция передается разработчикам, чтобы те устранили баг.
Пример 2
Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:
Значение | Результат |
6000 | ОК |
5500 | ОК |
4000 | Ошибка |
7200 | Ошибка |
7400 | Ошибка |
8000 | Ошибка |
Пустое | Ошибка |
100$ | Ошибка |
… | … |
… и так далее |
Преимущества и недостатки методики
Преимущества
- Неплохой контроль возможных проблемных мест в проекте (они обычно стандартные)
- Отлично работает в сочетании с другими техниками тест-дизайна и дополняет их
- Позволяет довольно просто находить баги, которые доступны только при исчерпывающем тестировании (всех комбинаций ввода, что невозможно из-за недостатка времени)
Недостатки
- Является как бы ориентированной на личность тестировщика методикой, а не на процессы, что более правильно; то есть не является универсальной, а сильно зависит от скиллов тестировщика
- Не обеспечивает хорошее покрытие сама по себе
- Не очень подходит новичкам, неопытным, плохо знакомым с продуктом или областью его применения
***