А почему эти навыки понадобятся только через 5 лет? Откуда такая информация? Откуда такие данные? Так нейронка так написала просто? Если так,то стоит сказать об этом. Если вы специалист в этой области, то напишите о своей экспертности и сделайте прогноз как тот, кто разбирается в этой теме. А так это похоже на предсказание Нейронострадамуса.
Эльвира, спасибо за статью! Вы подняли очень важные и актуальные проблемы, с которыми сталкиваются многие команды, работающие с автотестами. Действительно, отношение к тестовому коду как к чему-то второстепенному — это распространённая ошибка, которая приводит к серьёзным последствиям. Ваши примеры антипаттернов очень наглядны и, к сожалению, знакомы многим из нас.
Хочу добавить несколько мыслей:
Комментарии в тестах: Вы правы, что комментарии часто маскируют проблемы, вместо того чтобы их решать. Однако, если комментарии используются для объяснения сложной бизнес-логики или неочевидных решений, они могут быть полезны. Главное — не злоупотреблять ими и не заменять ими качественный код.
Самодокументируемый код: Это идеал, к которому стоит стремиться. Если тестовый код написан чисто и понятно, он не только упрощает поддержку, но и становится частью документации. Это особенно важно для новых членов команды.
Page Object и DRY: Полностью согласен, что пренебрежение этими принципами приводит к хрупким и трудно поддерживаемым тестам. Page Object — это must-have для UI-тестов, а DRY — это основа любого качественного кода, будь то продукт или тесты.
Ревью тестов: Очень важный момент. Ревью тестов должно быть таким же тщательным, как и ревью продуктового кода. Покрытие, логика, корректность проверок — всё это должно проверяться. Иначе тесты теряют свою ценность.
Последствия пренебрежения: Вы абсолютно правы, что проблемы с тестами накапливаются, как снежный ком. В итоге это приводит к тому, что тесты перестают быть инструментом, а становятся обузой. И тогда команда возвращается к ручному тестированию, что сводит на нет все преимущества автоматизации.
Спасибо за ваш опыт и примеры! Думаю, многим командам будет полезно задуматься над тем, как они пишут и поддерживают свои тесты.
А, что вы думаете по поводу внедрения code style и линтеров для тестового кода? Это могло бы помочь избежать некоторых проблем, которые вы описали.
С одной стороны, вы совершенно правы: «плохая архитектура» действительно часто выливается в избыточную сложность, и это напрямую влияет на вероятность появления дефектов. Если архитектура изначально продумана, модули чётко разделены, а код легко расширять и поддерживать, то и вероятность «кучкования» багов снижается.
Что до «частоты изменений», тут тоже соглашусь. Сама по себе она не означает, что будет больше проблем. Всё зависит от опытности команды, общего процесса разработки (code review, тестирование, документация) и понимания контекста. Если всё это налажено, то и при частых релизах продукт может становиться только лучше. Но если процессов нет или они работают плохо, то каждое изменение — потенциальный риск внести новую ошибку.
В итоге и «плохая архитектура», и «высокая частота изменений» можно рассматривать как факторы, которые могут усиливать дефектное «скопление». Но всё это, конечно, сильно зависит от конкретных условий в проекте и того, как организована работа команды. Ещё раз спасибо, что обратили внимание на эти нюансы!
Благодарю за комментарий! Благодаря ему я внес уточнение в статью. Вы абсолютно правы в том, что недостаточное тестирование — это не первопричина скопления дефектов, а скорее фактор, усугубляющий ситуацию. Скопление дефектов происходит из-за inherent complexity (врожденной сложности) определенных модулей — из-за их сложной логики, частых изменений, большого количества зависимостей. Баги чаще появляются в сложных частях кода. Если мы плохо тестируем эти части, то просто не находим их там, где они уже есть. И понятно, что проблема не в том, что из-за плохого тестирования баги появляются чаще, а в том, что мы их не видим, а они накапливаются.
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например, int), так и некорректными (например, не int), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.
Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.
В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например, int), так и некорректными (например, не int), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.
Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.
В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Добрый день, Антон! Благодарю за интересный комментарий.
Ваш вопрос поднимает интересную точку зрения о терминах "негативное" и "позитивное" тестирование. Давайте разберем эти концепции и постараемся внести ясность в то, почему тестирование с использованием некорректных данных называется "негативным", несмотря на предсказуемость результата.
Позитивное и негативное тестирование: разница в подходах
Позитивное тестирование направлено на проверку того, что система работает правильно при вводе корректных данных и в нормальных условиях.
Цель позитивного тестирования — убедиться, что система выполняет свои функции так, как ожидается. Например, если пользователь вводит правильные учетные данные, система должна успешно аутентифицировать пользователя и предоставить доступ.
Негативное тестирование, с другой стороны, направлено на проверку того, как система обрабатывает некорректные, неожиданные или невалидные данные.
Цель негативного тестирования — убедиться, что система правильно реагирует на ошибки, невалидные данные или некорректные действия. Например, если пользователь вводит неправильные учетные данные, система должна предотвратить вход и выдать соответствующее сообщение об ошибке.
Почему тесты на некорректные данные считаются негативными?
Когда мы говорим о "негативном тестировании", термин "негативный" не обязательно означает, что результат теста непредсказуем или нежелателен. Скорее, это относится к самой природе входных данных или действий, которые считаются некорректными или выходящими за рамки нормального использования системы. В этом контексте:
Позитивное тестирование проверяет, что система работает правильно, когда все данные и действия корректны.
Негативное тестирование проверяет, что система правильно обрабатывает ошибки и отклонения, когда данные или действия некорректны.
Примеры для лучшего понимания
Позитивный тест: Пользователь вводит правильный логин и пароль. Мы ожидаем, что система предоставит доступ. Это позитивный тест, так как данные корректны, и мы проверяем, что система выполняет свою основную функцию.
Негативный тест: Пользователь вводит неправильный пароль. Мы ожидаем, что система откажет в доступе и выведет сообщение об ошибке. Это негативный тест, так как мы проверяем поведение системы при некорректных данных.
Почему тесты на предсказуемое поведение системы при некорректных данных все равно негативные?
Даже если мы точно знаем, что система должна вернуть определенный код ошибки (например, 404 или 400), когда ей передаются невалидные данные, такой тест все равно считается негативным. Это связано с тем, что основной акцент в этом тесте делается на том, как система справляется с ненормальными, некорректными или ошибочными вводами, а не с тем, выполняет ли она свои функции при корректных условиях.
Шикарная статья. Спасибо автору. Возник вопрос выложенный код сервиса load-testing-hub нужно ложить на свой сервер для работы с ним или как он работает?
Благодарю за вопрос и дополнения. Все по делу. Здорово! (п7 исправил. Там действительно был 8 внутри 7-го, поэтому теперь их стало 17 и твой п 10 стал 11.).
Отвечая на Ваш вопрос по п.6 хочу уточнить и дополнить некоторые моменты:
В поле "Pre-conditions" (Предварительные условия) тест-кейса можно и нужно прописывать требование авторизации/аутентификации, но с нюансами:
Прежде всего важно отметить ,что уровни авторизации можно разделить на 2 уровня (первичной и вторичной авторизации) и также не забыть сказать о динамической природе авторизации (как раз тот момент на который Вы обратили внимание). За что вам отдельное спасибо! Итак начнем по порядку.
1) Уровень авторизации: а) первичная авторизация: если для доступа к приложению или тестовой сборке требуется авторизация, это обязательно следует указать в "Pre-conditions". Это первичный уровень, без которого тест не может быть запущен.
б) вторичная авторизация: если авторизация требуется для определенных функций внутри уже доступного приложения, то ее не обязательно прописывать в "Pre-conditions".
2) Динамическая природа авторизации:
Сброс авторизации: Вы правы, что авторизация не может длиться вечно. Если она сбрасывается за время выполнения теста, то ее необходимо повторить в шагах тест-кейса.
Сохранение авторизации: Если авторизация сохраняется на протяжении всего теста, то ее достаточно указать в "Pre-conditions".
Приведу 2 примера :
Пример 1:
Pre-conditions:Пользователь авторизован в системе под учетной записью "tester".
Шаги:
Открыть раздел "Корзина".
Добавить товар в корзину.
Оформить заказ.
Комментарий. В данном случае:
Первичная авторизация необходима для доступа к приложению.
Вторичная авторизация не требуется, т.к. она уже выполнена в "Pre-conditions".
Пример 2:
Pre-conditions: Пользователь находится на странице "Личный кабинет".
Шаги:
Перейти в раздел "Настройки безопасности".
Изменить пароль.
Комментарий. В данном случае:
Первичная авторизация не упоминается, т.к. она подразумевается.
Вторичная авторизация не требуется, т.к. пользователь уже находится в "Личном кабинете".
3) Важные рекомендации к авторизации:
Четко формулируйте требования к авторизации.
Указывайте уровень авторизации: первичная или вторичная.
Учитывайте динамическую природу авторизации: сброс или сохранение.
Используйте здравый смысл: если авторизация очевидна, не дублируйте
Надеюсь я ответил на этот вопрос.
Что касается п.10 (теперь п.11) "Предыдущие действия", то здесь Вы абсолютно правы он имеет свои ограничения:
1. Динамические действия:
Действия, которые не сохраняют свое состояние (например, нажатие кнопки), нельзя прописать в "Pre-conditions".
Спасибо за вопрос. Это пилотная статья и проба пера. Хочу в следующей статье более глубже рассмотреть поднятую тему. Приведенные примеры в таком объеме вы вряд ли найдете в книгах о тестировании. Скорее всего - понадобятся и журналы. Цель статьи не только донести информацию, напомнить на важность использования предусловий, но и призвать участников сообщества к диалогу, полемике по данной теме.
Хотелось бы от всей души поблагодарить автора за прекрасную статью и затраченные на нее силы. Весьма полезная и толковая статья, которая обязательно найдет отклик в умах своих читателей.
Ну а теперь перехожу непосредственно к своему развернутому комментарию.
Сильные стороны:
Практическая направленность: Автор статьи делится своим опытом применения техник тест-дизайна в реальном проекте, что делает материал более интересным и ценным для читателей, особенно для тех, кто только начинает свой путь в тестировании. Также стоит отметить, что автор уделяет внимание не только техникам тестирования, но и важности декомпозиции системы перед началом тестирования. Он подробно описывает, как он разбивает систему оплаты на отдельные компоненты и как это помогает ему более эффективно проводить тестирование.
Четкость и структурированность: Статья хорошо структурирована, содержит понятные определения и примеры, что облегчает восприятие информации.
Комплексный подход: Автор статьи не ограничивается описанием одной техники тест-дизайна, а рассматривает их комбинацию, что позволяет провести более полное тестирование системы.
Наглядность: Иллюстрации и схемы, используемые в статье, помогают лучше понять описываемые концепции.
Актуальность: Тема статьи актуальна для QA-специалистов, занимающихся тестированием систем оплаты.
Точки роста:
Недостаточно подробное описание некоторых техник: Автор статьи мог бы более подробно описать некоторые техники тест-дизайна, например, прогнозирование ошибок.
Не уделено достаточное внимания различным типам ошибок, которые могут возникнуть при тестировании систем оплаты. Он упоминает о "потере свойства оплаты", но не рассматривает другие возможные ошибки, такие как неправильное округление сумм, проблемы с обработкой возвратов и т.д.
Не упоминается о важности тестирования безопасности системы оплаты. В современном мире это является одним из ключевых аспектов тестирования, так как системы оплаты часто становятся целью для хакерских атак.
Отсутствие примеров тестовых сценариев: Примеры тестовых сценариев, основанных на описанных техниках, могли бы сделать статью еще более практичной.
Недостаточная фокусировка на нюансах: Автор статьи мог бы более подробно остановиться на нюансах тестирования систем оплаты, связанных с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Рекомендации:
Добавить больше примеров тестовых сценариев.
Более подробно описать прогнозирование ошибок.
Рассмотреть нюансы тестирования систем оплаты, связанные с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Общее впечатление:
Статья "Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты" является ценным ресурсом для QA-специалистов, занимающихся тестированием систем оплаты. Автор статьи делится своим опытом применения техник тест-дизайна, что делает материал интересным и практичным.
Моя оценка: 4,5 из 5.
Дополнительные комментарии:
Автор статьи мог бы добавить раздел "Заключение", в котором он бы подвел итоги и дал рекомендации по применению описанных техник тест-дизайна.
В статье можно было бы использовать больше ссылок на дополнительные ресурсы по теме тестирования систем оплаты.
В целом, статья представляет собой полезный обзор техник тестирования систем оплаты и может быть интересна как начинающим, так и опытным тестировщикам. Она подчеркивает важность комбинирования различных техник и подхода к тестированию с разных сторон.
Статья из рода фантастики на IT тематику. Абсолютно отсутствует научный подход к методологии исследования. Его просто нет. Автор приводит данные, которые не обоснованы и не подкреплены никакой доказательной базой. Кроме того, данный материал можно уже смело использовать в суде как факт клеветы на IT-курсы, т.к. они не давали согласия на опубликование информации о своих выпускниках и результатах работы. Пишу не как защитник IT-курсов, а как IT-специалист с большим багажом научного опыта в прошлом. А модераторы Habr могут также "отхватить" за подобные публикации. Как минимум кто-то может в ближайшей перспективе сходить в суд вместе с автором статьи. Это реалии сегодняшнего времени.
Статью однозначно нужно переименовывать. Принципами тут и не пахнет, да и целью также. Цель всегда одна, ну 2 - это максимум, а остальное это решаемые задачи на пути её достижения. Правильно уже ни один раз сказано о разнице между целями и принципами, однако никто не сказал, что это статья даже не о новой цели , а обыкновенной задаче. Предложение в цели тестирования нужно добавить еще один пункт - «Работать над улучшением продукта» на мой взгляд не является актуальным и с методологической точки зрения ошибочным, так как цель как я сказал одна, а задач много. Статья получилась очень сырая. Автору желаю успехов в написании новых, более грамотных и полезных статей.
А почему эти навыки понадобятся только через 5 лет? Откуда такая информация? Откуда такие данные? Так нейронка так написала просто? Если так,то стоит сказать об этом. Если вы специалист в этой области, то напишите о своей экспертности и сделайте прогноз как тот, кто разбирается в этой теме. А так это похоже на предсказание Нейронострадамуса.
Эльвира, спасибо за статью! Вы подняли очень важные и актуальные проблемы, с которыми сталкиваются многие команды, работающие с автотестами. Действительно, отношение к тестовому коду как к чему-то второстепенному — это распространённая ошибка, которая приводит к серьёзным последствиям. Ваши примеры антипаттернов очень наглядны и, к сожалению, знакомы многим из нас.
Хочу добавить несколько мыслей:
Комментарии в тестах: Вы правы, что комментарии часто маскируют проблемы, вместо того чтобы их решать. Однако, если комментарии используются для объяснения сложной бизнес-логики или неочевидных решений, они могут быть полезны. Главное — не злоупотреблять ими и не заменять ими качественный код.
Самодокументируемый код: Это идеал, к которому стоит стремиться. Если тестовый код написан чисто и понятно, он не только упрощает поддержку, но и становится частью документации. Это особенно важно для новых членов команды.
Page Object и DRY: Полностью согласен, что пренебрежение этими принципами приводит к хрупким и трудно поддерживаемым тестам. Page Object — это must-have для UI-тестов, а DRY — это основа любого качественного кода, будь то продукт или тесты.
Ревью тестов: Очень важный момент. Ревью тестов должно быть таким же тщательным, как и ревью продуктового кода. Покрытие, логика, корректность проверок — всё это должно проверяться. Иначе тесты теряют свою ценность.
Последствия пренебрежения: Вы абсолютно правы, что проблемы с тестами накапливаются, как снежный ком. В итоге это приводит к тому, что тесты перестают быть инструментом, а становятся обузой. И тогда команда возвращается к ручному тестированию, что сводит на нет все преимущества автоматизации.
Спасибо за ваш опыт и примеры! Думаю, многим командам будет полезно задуматься над тем, как они пишут и поддерживают свои тесты.
А, что вы думаете по поводу внедрения code style и линтеров для тестового кода? Это могло бы помочь избежать некоторых проблем, которые вы описали.
Спасибо за развёрнутый комментарий!
С одной стороны, вы совершенно правы: «плохая архитектура» действительно часто выливается в избыточную сложность, и это напрямую влияет на вероятность появления дефектов. Если архитектура изначально продумана, модули чётко разделены, а код легко расширять и поддерживать, то и вероятность «кучкования» багов снижается.
Что до «частоты изменений», тут тоже соглашусь. Сама по себе она не означает, что будет больше проблем. Всё зависит от опытности команды, общего процесса разработки (code review, тестирование, документация) и понимания контекста. Если всё это налажено, то и при частых релизах продукт может становиться только лучше. Но если процессов нет или они работают плохо, то каждое изменение — потенциальный риск внести новую ошибку.
В итоге и «плохая архитектура», и «высокая частота изменений» можно рассматривать как факторы, которые могут усиливать дефектное «скопление». Но всё это, конечно, сильно зависит от конкретных условий в проекте и того, как организована работа команды. Ещё раз спасибо, что обратили внимание на эти нюансы!
Благодарю за комментарий! Благодаря ему я внес уточнение в статью. Вы абсолютно правы в том, что недостаточное тестирование — это не первопричина скопления дефектов, а скорее фактор, усугубляющий ситуацию. Скопление дефектов происходит из-за inherent complexity (врожденной сложности) определенных модулей — из-за их сложной логики, частых изменений, большого количества зависимостей. Баги чаще появляются в сложных частях кода. Если мы плохо тестируем эти части, то просто не находим их там, где они уже есть. И понятно, что проблема не в том, что из-за плохого тестирования баги появляются чаще, а в том, что мы их не видим, а они накапливаются.
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например,
int), так и некорректными (например, неint), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные
int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Антон, спасибо за дополнение — это действительно интересное мнение!
Вы правы в том, что граница между валидными и невалидными данными часто зависит от контекста и того, как именно система обрабатывает входные данные. Если мы заранее ожидаем, что данные могут быть как корректными (например,
int), так и некорректными (например, неint), и у нас есть соответствующая логика обработки, то можно сказать, что с точки зрения системы такие данные ожидаемы и могут считаться "валидными" в широком смысле.Тем не менее, концепция негативного тестирования основывается не столько на том, что данные предсказуемы или ожидаемы, сколько на том, что они выходят за пределы нормального сценария использования системы. Например, если API ожидает положительные
int, но получает отрицательные значения, и если это не предусмотрено в коде (нет проверки или обработки), это действительно может считаться негативным кейсом.В итоге, негативные кейсы — это те, которые проверяют систему на устойчивость к непредусмотренным или некорректным вводам, даже если они потенциально "валидны" с точки зрения типа данных. Если система сталкивается с такими данными и не обрабатывает их должным образом, то это сигнал о возможной уязвимости или недоработке.
Ваш подход, где негативные кейсы — это все, что не предусмотрено в коде, тоже имеет право на жизнь, так как он фокусируется на обнаружении проблемных мест, которые могут быть упущены при разработке. И это как раз то, что делает негативное тестирование столь важным в общем процессе обеспечения качества ПО.
Добрый день, Антон! Благодарю за интересный комментарий.
Ваш вопрос поднимает интересную точку зрения о терминах "негативное" и "позитивное" тестирование. Давайте разберем эти концепции и постараемся внести ясность в то, почему тестирование с использованием некорректных данных называется "негативным", несмотря на предсказуемость результата.
Позитивное и негативное тестирование: разница в подходах
Позитивное тестирование направлено на проверку того, что система работает правильно при вводе корректных данных и в нормальных условиях.
Цель позитивного тестирования — убедиться, что система выполняет свои функции так, как ожидается. Например, если пользователь вводит правильные учетные данные, система должна успешно аутентифицировать пользователя и предоставить доступ.
Негативное тестирование, с другой стороны, направлено на проверку того, как система обрабатывает некорректные, неожиданные или невалидные данные.
Цель негативного тестирования — убедиться, что система правильно реагирует на ошибки, невалидные данные или некорректные действия. Например, если пользователь вводит неправильные учетные данные, система должна предотвратить вход и выдать соответствующее сообщение об ошибке.
Почему тесты на некорректные данные считаются негативными?
Когда мы говорим о "негативном тестировании", термин "негативный" не обязательно означает, что результат теста непредсказуем или нежелателен. Скорее, это относится к самой природе входных данных или действий, которые считаются некорректными или выходящими за рамки нормального использования системы. В этом контексте:
Позитивное тестирование проверяет, что система работает правильно, когда все данные и действия корректны.
Негативное тестирование проверяет, что система правильно обрабатывает ошибки и отклонения, когда данные или действия некорректны.
Примеры для лучшего понимания
Позитивный тест: Пользователь вводит правильный логин и пароль. Мы ожидаем, что система предоставит доступ. Это позитивный тест, так как данные корректны, и мы проверяем, что система выполняет свою основную функцию.
Негативный тест: Пользователь вводит неправильный пароль. Мы ожидаем, что система откажет в доступе и выведет сообщение об ошибке. Это негативный тест, так как мы проверяем поведение системы при некорректных данных.
Почему тесты на предсказуемое поведение системы при некорректных данных все равно негативные?
Даже если мы точно знаем, что система должна вернуть определенный код ошибки (например, 404 или 400), когда ей передаются невалидные данные, такой тест все равно считается негативным. Это связано с тем, что основной акцент в этом тесте делается на том, как система справляется с ненормальными, некорректными или ошибочными вводами, а не с тем, выполняет ли она свои функции при корректных условиях.
Пожалуйста. Очень рад , что статья вам понравилась.
Шикарная статья. Спасибо автору. Возник вопрос выложенный код сервиса load-testing-hub нужно ложить на свой сервер для работы с ним или как он работает?
Благодарю за вопрос и дополнения. Все по делу. Здорово! (п7 исправил. Там действительно был 8 внутри 7-го, поэтому теперь их стало 17 и твой п 10 стал 11.).
Отвечая на Ваш вопрос по п.6 хочу уточнить и дополнить некоторые моменты:
В поле "Pre-conditions" (Предварительные условия) тест-кейса можно и нужно прописывать требование авторизации/аутентификации, но с нюансами:
Прежде всего важно отметить ,что уровни авторизации можно разделить на 2 уровня (первичной и вторичной авторизации) и также не забыть сказать о динамической природе авторизации (как раз тот момент на который Вы обратили внимание). За что вам отдельное спасибо! Итак начнем по порядку.
1) Уровень авторизации: а) первичная авторизация: если для доступа к приложению или тестовой сборке требуется авторизация, это обязательно следует указать в "Pre-conditions". Это первичный уровень, без которого тест не может быть запущен.
б) вторичная авторизация: если авторизация требуется для определенных функций внутри уже доступного приложения, то ее не обязательно прописывать в "Pre-conditions".
2) Динамическая природа авторизации:
Сброс авторизации: Вы правы, что авторизация не может длиться вечно. Если она сбрасывается за время выполнения теста, то ее необходимо повторить в шагах тест-кейса.
Сохранение авторизации: Если авторизация сохраняется на протяжении всего теста, то ее достаточно указать в "Pre-conditions".
Приведу 2 примера :
Пример 1:
Pre-conditions:Пользователь авторизован в системе под учетной записью "tester".
Шаги:
Открыть раздел "Корзина".
Добавить товар в корзину.
Оформить заказ.
Комментарий. В данном случае:
Первичная авторизация необходима для доступа к приложению.
Вторичная авторизация не требуется, т.к. она уже выполнена в "Pre-conditions".
Пример 2:
Pre-conditions: Пользователь находится на странице "Личный кабинет".
Шаги:
Перейти в раздел "Настройки безопасности".
Изменить пароль.
Комментарий. В данном случае:
Первичная авторизация не упоминается, т.к. она подразумевается.
Вторичная авторизация не требуется, т.к. пользователь уже находится в "Личном кабинете".
3) Важные рекомендации к авторизации:
Четко формулируйте требования к авторизации.
Указывайте уровень авторизации: первичная или вторичная.
Учитывайте динамическую природу авторизации: сброс или сохранение.
Используйте здравый смысл: если авторизация очевидна, не дублируйте
Надеюсь я ответил на этот вопрос.
Что касается п.10 (теперь п.11) "Предыдущие действия", то здесь Вы абсолютно правы он имеет свои ограничения:
1. Динамические действия:
Действия, которые не сохраняют свое состояние (например, нажатие кнопки), нельзя прописать в "Pre-conditions".
Пример 1:
Pre-conditions: Пользователь нажал кнопку "Забыли пароль?".
Это некорректно, т.к. после нажатия кнопка меняет свое состояние, и тест не сработает.
2. Последовательные действия:
Вместо "Предыдущие действия" для таких случаев используйте последовательные тест-кейсы.
Пример 2:
Тест-кейс 1: Нажать кнопку "Забыли пароль?".
Тест-кейс 2: Проверить возможность восстановления пароля.
Рекомендации:
Используйте "Pre-conditions" для статичных условий.
Для динамических действий используйте последовательные тест-кейсы или другие решения.
Четко формулируйте все условия и действия.
Спасибо за вопрос. Это пилотная статья и проба пера. Хочу в следующей статье более глубже рассмотреть поднятую тему. Приведенные примеры в таком объеме вы вряд ли найдете в книгах о тестировании. Скорее всего - понадобятся и журналы. Цель статьи не только донести информацию, напомнить на важность использования предусловий, но и призвать участников сообщества к диалогу, полемике по данной теме.
Хотелось бы от всей души поблагодарить автора за прекрасную статью и затраченные на нее силы. Весьма полезная и толковая статья, которая обязательно найдет отклик в умах своих читателей.
Ну а теперь перехожу непосредственно к своему развернутому комментарию.
Сильные стороны:
Практическая направленность: Автор статьи делится своим опытом применения техник тест-дизайна в реальном проекте, что делает материал более интересным и ценным для читателей, особенно для тех, кто только начинает свой путь в тестировании. Также стоит отметить, что автор уделяет внимание не только техникам тестирования, но и важности декомпозиции системы перед началом тестирования. Он подробно описывает, как он разбивает систему оплаты на отдельные компоненты и как это помогает ему более эффективно проводить тестирование.
Четкость и структурированность: Статья хорошо структурирована, содержит понятные определения и примеры, что облегчает восприятие информации.
Комплексный подход: Автор статьи не ограничивается описанием одной техники тест-дизайна, а рассматривает их комбинацию, что позволяет провести более полное тестирование системы.
Наглядность: Иллюстрации и схемы, используемые в статье, помогают лучше понять описываемые концепции.
Актуальность: Тема статьи актуальна для QA-специалистов, занимающихся тестированием систем оплаты.
Точки роста:
Недостаточно подробное описание некоторых техник: Автор статьи мог бы более подробно описать некоторые техники тест-дизайна, например, прогнозирование ошибок.
Не уделено достаточное внимания различным типам ошибок, которые могут возникнуть при тестировании систем оплаты. Он упоминает о "потере свойства оплаты", но не рассматривает другие возможные ошибки, такие как неправильное округление сумм, проблемы с обработкой возвратов и т.д.
Не упоминается о важности тестирования безопасности системы оплаты. В современном мире это является одним из ключевых аспектов тестирования, так как системы оплаты часто становятся целью для хакерских атак.
Отсутствие примеров тестовых сценариев: Примеры тестовых сценариев, основанных на описанных техниках, могли бы сделать статью еще более практичной.
Недостаточная фокусировка на нюансах: Автор статьи мог бы более подробно остановиться на нюансах тестирования систем оплаты, связанных с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Рекомендации:
Добавить больше примеров тестовых сценариев.
Более подробно описать прогнозирование ошибок.
Рассмотреть нюансы тестирования систем оплаты, связанные с налогами, чеками, возвратными чеками, регионами, экономическими зонами.
Общее впечатление:
Статья "Тест-дизайн на практике: комбинируем разные техники тестирования, на примере проверки систем оплаты" является ценным ресурсом для QA-специалистов, занимающихся тестированием систем оплаты. Автор статьи делится своим опытом применения техник тест-дизайна, что делает материал интересным и практичным.
Моя оценка: 4,5 из 5.
Дополнительные комментарии:
Автор статьи мог бы добавить раздел "Заключение", в котором он бы подвел итоги и дал рекомендации по применению описанных техник тест-дизайна.
В статье можно было бы использовать больше ссылок на дополнительные ресурсы по теме тестирования систем оплаты.
В целом, статья представляет собой полезный обзор техник тестирования систем оплаты и может быть интересна как начинающим, так и опытным тестировщикам. Она подчеркивает важность комбинирования различных техник и подхода к тестированию с разных сторон.
Отличная статья! Читал на одном дыхании. Огромное спасибо за рекомендации и личный опыт! Это очень важно!
Статья из рода фантастики на IT тематику. Абсолютно отсутствует научный подход к методологии исследования. Его просто нет. Автор приводит данные, которые не обоснованы и не подкреплены никакой доказательной базой. Кроме того, данный материал можно уже смело использовать в суде как факт клеветы на IT-курсы, т.к. они не давали согласия на опубликование информации о своих выпускниках и результатах работы. Пишу не как защитник IT-курсов, а как IT-специалист с большим багажом научного опыта в прошлом. А модераторы Habr могут также "отхватить" за подобные публикации. Как минимум кто-то может в ближайшей перспективе сходить в суд вместе с автором статьи. Это реалии сегодняшнего времени.
Статью однозначно нужно переименовывать. Принципами тут и не пахнет, да и целью также. Цель всегда одна, ну 2 - это максимум, а остальное это решаемые задачи на пути её достижения. Правильно уже ни один раз сказано о разнице между целями и принципами, однако никто не сказал, что это статья даже не о новой цели , а обыкновенной задаче. Предложение в цели тестирования нужно добавить еще один пункт - «Работать над улучшением продукта» на мой взгляд не является актуальным и с методологической точки зрения ошибочным, так как цель как я сказал одна, а задач много. Статья получилась очень сырая. Автору желаю успехов в написании новых, более грамотных и полезных статей.