Комментарии 6
Спасибо большое, повторение мать учения! Был приятно прочесть простыми словами то, что когда-то учил и не понимал.
Спасибо. Интересно, хоть я и не тестировщик.
Несколько комментариев по поводу написанного.
1. Анализ граничных значений.
Что такое граничные значения? Это минимальные или максимальные значения из упорядоченного класса эквивалентности.
Вот смотрите, вы разбили возраст на классы эквивалентности: до 17 включительно, 18-60, 61 и более.
Где в вашем примере эти минимумы и максимумы? Это 17, 18, 60 и 61. И всё.
Ни 19, ни 59 к границам не относятся.
Вот подумайте сами: 18 и 19 лежат в одном классе эквивалентности. Если 18 обрабатывается корректно, то смысл проверять еще и 19? А если 18 обрабатывается неверно, то вот он и есть баг. Поэтому и нет смысла закладывать в тесты проверку ни 19, ни 20, ни 21 и т.д.
2. Попарное тестирование.
К сожалению, применено неправильно. В итоговых комбинациях должны перебираться ВСЕ уникальные пары. В вашем примере не хватает еще двух: белый фон + большой текст и черный фон + маленький текст.
И да: в этом примере вообще нет смысла использовать pairwise, поскольку правильное применение этой техники дает те же самые 6 комбинаций, что и были изначально.
Вообще pairwise testing обычно не делают вручную. Как правило, его применяют при большем числе переменных (условий) и значений, чтобы как раз-таки и был эффект от его использования. Речь не про 4-6 комбинаций, а про десятки, сотни и тысячи.
На всякий случай, вот хороший инструмент: https://pairwise.yuuniworks.com/
3. Таблицы принятия решений (ТПР).
Построенная таблица напоминает ТПР весьма отдаленно.
Попробуйте приведенную таблицу переложить (и при этом не запутаться), например, на требования к банковскому, страховому или медицинскому ПО, где условий и значений куда больше, а каждому правилу соответствует не одно действие, а их комбинация. А ведь формат ТПР и алгоритм ее построения как раз и “заточены” под то, чтобы легко обрабатывать такие кейсы.
Также в таблице, составленной для авторизации, в последней строке нет смысла перебирать варианты “Да или нет”, т.к. если пользователь не авторизован, то у него вообще нет доступа ни к корзине, ни к способу оплаты. Поэтому в этих ячейках будет просто прочерк. Видимо, аналогично будет и для строки, где нет товаров в корзине.
Анализ граничных значений.
А как же проверить -1 или число большее int. Ну и null тоже же надо вкорячить и проверить :)
Попарное тестирование.
Согласен. UI такой ui
Таблицы принятия решений (ТПР).
Никогда почти не делал их за 15 лет работы
По опыту скажу, все проекты разные и единого подхода не будет. Я уже смирился с тем, что пирамида тестирования тоже не всегда применима и верна. Но это все от проекта к проекту
Про числа 19 и 59 вопрос спорный, ибо это есть границы допустимых значений ?
Первые шаги в тест-дизайне: Разбираемся в базовых техниках QA