Кстати, да 👍 Хотя вряд ли такой подход применим вот прямо для всех тест-кейсов. В моей практике такое практиковалось для прохождения разработчиками смоука по фиче и для перепроверки ими своего кода на ошибки в случае фич со сложной логикой.
Если разработчик решит перейти в проджект менеджмент, разве это будет означать, что он "вырос", стал самостоятельнее и компетентнее в разработке? Так и у всех остальных: если тестировщик захочет перейти в ВА, автоматизацию, разработку, девопс ... - это не рост, а просто смена профессии.
А сарказм ваш зря. Это полезно - знать и понимать терминологию своей профессиональной области. Обычно от практики она как раз-таки и отличается там, где её или не знают, или неправильно понимают/применяют.
Подскажите, за что похвалить :) Вы перешли в автоматизацию и теперь умеете дебажить код в девтулз. Разве это не обычный базовый навык автоматизатора и разработчика?
Вы хотели поделиться своими новыми знаниями и помочь коллегам? Может, тогда стоило подсветить ценность этой информации не через призму, что якобы мануальный тестировщик, не занимающийся дебаггингом в Devtools и поиском в ошибок в чужом коде, - это пока еще несамостоятельный и с закрытыми глазами тыкающий исследовательское тестирование. А ну и еще он так и останется, по вашему мнению, на уровне принеси-подай.
Хотя, как вам верно подсветили, компетентность мануальных тестировщиков определяется не по умению работать с кодом или дебажить его за разработчиками.
Ну а терминологию тестирования - да, знать полезно.
То, что лучший тестировщик - это тот, кто баг не только нашел, но еще и пофиксил, - это уже бородатый анекдот. Но то, чтобы тестировщики за разработчиков еще и отладку кода делали - это что-то новое. ?
Мануальный тестировщик (в отличие от автоматизатора) не занимает отладкой кода. Это всё-таки обязанность разработчика, как и написание юнит-тестов, и баг-фиксинг, и желательно смоук-тестинг разработанной им же фичи.
Тут хочу пару слов добавить о всё-таки правильном употреблении терминов.
Метод черного ящика - это когда тестировщик делает тестовое покрытие на основе требований и их приемочных критериев. То есть тестировщик читает приемочные критерии и придумывает тесты, которые будут проверять эти приемочные критерии. При этом он может иметь доступ к коду и даже прекрасно в нем разбираться. Но в данном методе эти знания тестировщик не использует, т.к. цель - проверить запланированное ВА/РО поведение фичи/системы без привязки к тому, как именно разработчик его реализовывал.
Метод белого ящика - это когда тестировщик делает тестовое покрытие на основе кода/архитектуры приложения. То есть условно, когда фича сделана, тестировщик открывает код и придумывает тесты, которые будут проверять именно этот код. И для этого существуют специальные техники тест-дизайна, отличающиеся от тех, что применяются в методе черного ящика.
Так что методы тестирования - это о подходе к тест-дизайну, а не о том, знает или не знает тестировщик код. Поэтому на самом деле нет в тестировании метода "серого" ящика. Как нет ни красного, ни желтого, ни т.п. "цветных" методов (хотя и такие в статьях встречаются). Если что - это можно перепроверить по ISTQB Glossary или Syllabus (раздел 4).
По условию задачи из статьи: "18 и 60: Это минимальное и максимальное допустимые значения". Т.е. это и есть границы позитивного класса эквивалентности.
Так что 19 и 59 - это обычные значения внутри этого класса. Такие же, как 20 и 58, 21 и 57 и т.д. :)
Что такое граничные значения? Это минимальные или максимальные значения из упорядоченного класса эквивалентности.
Вот смотрите, вы разбили возраст на классы эквивалентности: до 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 комбинаций, а про десятки, сотни и тысячи.
Построенная таблица напоминает ТПР весьма отдаленно.
Попробуйте приведенную таблицу переложить (и при этом не запутаться), например, на требования к банковскому, страховому или медицинскому ПО, где условий и значений куда больше, а каждому правилу соответствует не одно действие, а их комбинация. А ведь формат ТПР и алгоритм ее построения как раз и “заточены” под то, чтобы легко обрабатывать такие кейсы.
Также в таблице, составленной для авторизации, в последней строке нет смысла перебирать варианты “Да или нет”, т.к. если пользователь не авторизован, то у него вообще нет доступа ни к корзине, ни к способу оплаты. Поэтому в этих ячейках будет просто прочерк. Видимо, аналогично будет и для строки, где нет товаров в корзине.
У нас была отдаленно похожая история. Правда про предложения по улучшению.
Один из популярных пользователей системы озвучил у себя в блоге, что, мол, ему не хватает такой-то фичи. И там же пошёл целый шквал комментов от подписчиков, что им тоже хотелось бы такое улучшение и почему, мол, компания не может до сих пор это сделать. Хотя до этого вообще никто на эту тему никаких ни фидбэков, ни жалоб не писал.
Ну а фичу добавили в бэклог и спустя какое-то время зарелизили )
Тестирование же включает в себя разные активности на протяжении всего SDLC.
Например, еще в процессе анализа требований мы выявили, что приемочные критерии стори не позволяют полноценно достичь того велью, которое в стори описано. А это уже потенциально в будущем проваленная валидация, а то и UAT.
Или еще на этой же стадии (да и даже на стадии тестирования фичи) мы можем вносить предложения по улучшению.
Это ведь все не баги, но тем не менее на качество влияет.
Да и в целом тестирование - это не только поиск багов. В первую очередь - это подтверждение того, что приложение/фича работает по требованиям и позволяет достигать поставленной цели. И такое подтверждение - это уже отметка об определённом уровне качества.
Пункты #2 и #3 в принципе могут как НЕ зависеть от тестировщиков, так и быть упущением со стороны QA-команды. Надо смотреть по ситуации, конечно.
Пункт #2. Если работают несколько команд, то как минимум QA Team Lead должен отслеживать и уточнять скоупы и их возможные пересечения. И соответственно планировать тестирование.
Пункт #3. Это тоже может отловить команда тестирования в будущих релизах: как на стадии тестирования новых требований, так и при тестировании новых фич/регрессии.
Но это, конечно, при правильном раскладе, прозрачных процессах, открытой коммуникации, ...
ИМХО. Основной смысл тестирования - повысить качество продукта /снизить риск выпуска некачественного ПО или фичи. Поиск багов это всего лишь один из способов, как этого добиться.
Да, нас, тестировщиков, как правило, не будят посреди ночи, когда обнаружен баг на проде.
Но именно тестировщики - это фактически те, кто последними проверяют фичу перед передачей в прод. И именно мы отвечаем за резолюцию по качеству фичи/продукта и их готовности к релизу.
Поэтому, когда тестировщик узнает о баге на проде (пусть и утром), то чаще всего первая мысль, которая его посещает, - "Это я пропустил(а) баг". И это в любом случае не самые приятные эмоции, а для начинающих - так и вообще стресс.
Но это я про ответственных тестировщиков, конечно :)
Кстати, да 👍 Хотя вряд ли такой подход применим вот прямо для всех тест-кейсов. В моей практике такое практиковалось для прохождения разработчиками смоука по фиче и для перепроверки ими своего кода на ошибки в случае фич со сложной логикой.
Пожалуйста )
Согласна, за тренажёр - kudos!
Если разработчик решит перейти в проджект менеджмент, разве это будет означать, что он "вырос", стал самостоятельнее и компетентнее в разработке? Так и у всех остальных: если тестировщик захочет перейти в ВА, автоматизацию, разработку, девопс ... - это не рост, а просто смена профессии.
А сарказм ваш зря. Это полезно - знать и понимать терминологию своей профессиональной области. Обычно от практики она как раз-таки и отличается там, где её или не знают, или неправильно понимают/применяют.
P.S. Новому учусь, учиться люблю. :)
Подскажите, за что похвалить :) Вы перешли в автоматизацию и теперь умеете дебажить код в девтулз. Разве это не обычный базовый навык автоматизатора и разработчика?
Вы хотели поделиться своими новыми знаниями и помочь коллегам? Может, тогда стоило подсветить ценность этой информации не через призму, что якобы мануальный тестировщик, не занимающийся дебаггингом в Devtools и поиском в ошибок в чужом коде, - это пока еще несамостоятельный и с закрытыми глазами тыкающий исследовательское тестирование. А ну и еще он так и останется, по вашему мнению, на уровне принеси-подай.
Хотя, как вам верно подсветили, компетентность мануальных тестировщиков определяется не по умению работать с кодом или дебажить его за разработчиками.
Ну а терминологию тестирования - да, знать полезно.
То, что лучший тестировщик - это тот, кто баг не только нашел, но еще и пофиксил, - это уже бородатый анекдот. Но то, чтобы тестировщики за разработчиков еще и отладку кода делали - это что-то новое. ?
Мануальный тестировщик (в отличие от автоматизатора) не занимает отладкой кода. Это всё-таки обязанность разработчика, как и написание юнит-тестов, и баг-фиксинг, и желательно смоук-тестинг разработанной им же фичи.
Тут хочу пару слов добавить о всё-таки правильном употреблении терминов.
Метод черного ящика - это когда тестировщик делает тестовое покрытие на основе требований и их приемочных критериев. То есть тестировщик читает приемочные критерии и придумывает тесты, которые будут проверять эти приемочные критерии. При этом он может иметь доступ к коду и даже прекрасно в нем разбираться. Но в данном методе эти знания тестировщик не использует, т.к. цель - проверить запланированное ВА/РО поведение фичи/системы без привязки к тому, как именно разработчик его реализовывал.
Метод белого ящика - это когда тестировщик делает тестовое покрытие на основе кода/архитектуры приложения. То есть условно, когда фича сделана, тестировщик открывает код и придумывает тесты, которые будут проверять именно этот код. И для этого существуют специальные техники тест-дизайна, отличающиеся от тех, что применяются в методе черного ящика.
Так что методы тестирования - это о подходе к тест-дизайну, а не о том, знает или не знает тестировщик код. Поэтому на самом деле нет в тестировании метода "серого" ящика. Как нет ни красного, ни желтого, ни т.п. "цветных" методов (хотя и такие в статьях встречаются). Если что - это можно перепроверить по ISTQB Glossary или Syllabus (раздел 4).
По условию задачи из статьи: "18 и 60: Это минимальное и максимальное допустимые значения". Т.е. это и есть границы позитивного класса эквивалентности.
Так что 19 и 59 - это обычные значения внутри этого класса. Такие же, как 20 и 58, 21 и 57 и т.д. :)
Несколько комментариев по поводу написанного.
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. Таблицы принятия решений (ТПР).
Построенная таблица напоминает ТПР весьма отдаленно.
Попробуйте приведенную таблицу переложить (и при этом не запутаться), например, на требования к банковскому, страховому или медицинскому ПО, где условий и значений куда больше, а каждому правилу соответствует не одно действие, а их комбинация. А ведь формат ТПР и алгоритм ее построения как раз и “заточены” под то, чтобы легко обрабатывать такие кейсы.
Также в таблице, составленной для авторизации, в последней строке нет смысла перебирать варианты “Да или нет”, т.к. если пользователь не авторизован, то у него вообще нет доступа ни к корзине, ни к способу оплаты. Поэтому в этих ячейках будет просто прочерк. Видимо, аналогично будет и для строки, где нет товаров в корзине.
Забавно )
У нас была отдаленно похожая история. Правда про предложения по улучшению.
Один из популярных пользователей системы озвучил у себя в блоге, что, мол, ему не хватает такой-то фичи. И там же пошёл целый шквал комментов от подписчиков, что им тоже хотелось бы такое улучшение и почему, мол, компания не может до сих пор это сделать. Хотя до этого вообще никто на эту тему никаких ни фидбэков, ни жалоб не писал.
Ну а фичу добавили в бэклог и спустя какое-то время зарелизили )
Тестирование же включает в себя разные активности на протяжении всего SDLC.
Например, еще в процессе анализа требований мы выявили, что приемочные критерии стори не позволяют полноценно достичь того велью, которое в стори описано. А это уже потенциально в будущем проваленная валидация, а то и UAT.
Или еще на этой же стадии (да и даже на стадии тестирования фичи) мы можем вносить предложения по улучшению.
Это ведь все не баги, но тем не менее на качество влияет.
Да и в целом тестирование - это не только поиск багов. В первую очередь - это подтверждение того, что приложение/фича работает по требованиям и позволяет достигать поставленной цели. И такое подтверждение - это уже отметка об определённом уровне качества.
?
Пункты #2 и #3 в принципе могут как НЕ зависеть от тестировщиков, так и быть упущением со стороны QA-команды. Надо смотреть по ситуации, конечно.
Пункт #2. Если работают несколько команд, то как минимум QA Team Lead должен отслеживать и уточнять скоупы и их возможные пересечения. И соответственно планировать тестирование.
Пункт #3. Это тоже может отловить команда тестирования в будущих релизах: как на стадии тестирования новых требований, так и при тестировании новых фич/регрессии.
Но это, конечно, при правильном раскладе, прозрачных процессах, открытой коммуникации, ...
ИМХО. Основной смысл тестирования - повысить качество продукта /снизить риск выпуска некачественного ПО или фичи. Поиск багов это всего лишь один из способов, как этого добиться.
Классная история! Прямо как стандартное "Никто ж так делать не будет!" + еще как минимум 10 причин ⬇️
И вот как-то даже не поспоришь :)
Да, нас, тестировщиков, как правило, не будят посреди ночи, когда обнаружен баг на проде.
Но именно тестировщики - это фактически те, кто последними проверяют фичу перед передачей в прод. И именно мы отвечаем за резолюцию по качеству фичи/продукта и их готовности к релизу.
Поэтому, когда тестировщик узнает о баге на проде (пусть и утром), то чаще всего первая мысль, которая его посещает, - "Это я пропустил(а) баг". И это в любом случае не самые приятные эмоции, а для начинающих - так и вообще стресс.
Но это я про ответственных тестировщиков, конечно :)
Гадать можно долго :) В моей практике чаще причину находят разработчики. Задача же команды в целом (и QA-специалистов в частности) - это понять:
1) как можно было обнаружить эту проблему до релиза;
2) почему ее не обнаружили до релиза;
3) как и что улучшить в процессах, чтобы похожего рода проблемы впредь обнаруживались до релиза.