Александра Ерёмина @ereminaproqa
QA Lead, автор и преподаватель курсов, ментор
Информация
- В рейтинге
- Не участвует
- Откуда
- Гродно, Гродненская обл., Беларусь
- Зарегистрирована
- Активность
Специализация
Quality Assurance Engineer, Quality Assurance Manager
Lead
Кстати, да 👍 Хотя вряд ли такой подход применим вот прямо для всех тест-кейсов. В моей практике такое практиковалось для прохождения разработчиками смоука по фиче и для перепроверки ими своего кода на ошибки в случае фич со сложной логикой.
Не пользуйтесь этой статьей при подготовке к собесу.
Начиная с первых же вопросов, ответы - или неверные, или настолько неточные, что на собесе вам их не засчитают.
Например.
Не написано, что при тестировании происходит сверка с требованиями.
Контроль качества вдруг стал "тщательным тестированием на наличие дефектов". К слову, про QA тоже неверно написано. И про верификацию/валидацию, и про смоук/санити и т.д.
Тест-кейс оказывается содержит фактический результат. Сначала подумала, что перепутано с баг-репортом. Но нет: определение повторяется и в п.8, и в п.29.
К слову, определения ошибки, дефекта, сбоя и бага тоже неверные.
Модульное/интеграционное/системное,приемочное тестирование - в разных вопросах то уровни, то виды. И в принципе тут все классификации перепутаны (кроме п.21). См., например, п.27: с каких пор тестирование производительности, безопасности, удобства использования, регрессионное и т.д. стали уровнями и объединились в одну классификацию?
...
Можно еще много чего выписывать, но тут, скорее, вопрос к автору: как можно писать статью в помощь для прохождения собесов, элементарно не перепроверив информацию на достоверность? Даже если вы джун, но ведь это основа работы тестировщика - ВСЁ перепроверять и уметь работать с документацией.
Если вы реально хотите повториить базовую теорию и/или подготовиться к собесу без чтения стандартов/ISTQB, то почитайте книгу Святослава Куликова - https://svyatoslav.biz/software_testing_book/.
За последние несколько лет появилась масса учебников, библий, тьюториалов и т.д. (в которых, как и в статье, тоже хватает ошибок), но по уровню качества и правильности изложения информации к Куликову пока так никто и не приблизился.
Пожалуйста )
Согласна, за тренажёр - 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) как и что улучшить в процессах, чтобы похожего рода проблемы впредь обнаруживались до релиза.