ISTQB учит плохому?
Новые темы форума тестировщиков
В реальной работе тестировщика, а особенно в современном эджайле, тест-планы и тест-кейсы не требуются наверное в 95% случаев
Но несмотря на это ISTQB и подавляющее большинство книг по тестированию утверждают что начинать тестирование надо начинать именно с написания тест-плана и тест-кейсов, потом конечно идет выполнение этих тест-кейсов. Как будто никакого эджайла и не существует. Теперь ведь вместо тест-планов есть спринт-рефайнмент, вместо тест-кейсов чек-листы и исследовательское тестирование, вместо ручной регрессии автоматизированные тесты. Тест-менеджеров и тех практически не осталось
Может, пора уже принять современные реалии? Прошу помощи в споре с коллегами про принципы разработки автотестов 2019-11-26 17:00 Приветствую коллеги.
Чтобы было максимально понятно, опишу максимально подробно.
Я работаю в небольшой фирме и я единственный человек, который занимается автоматизацией тестирования. Мой стек - это cypress.io + javascript Я знаком с некоторыми принципами автоматизации тестирования и знаю несколько способов управления тестовыми данными
В основном, я использую способы 3 и 4. Потому что я знаю. Что управлять тестовыми данными через UI очень дорого и тесты получаются хрупкими и т.д.
Собственно из-за этого у меня возникает постоянный спор с коллегами, которые с автоматизацией тестирования почти не знакомы. Они утверждают следующее: (Примерно процитирую) Цитата: “Если ты пишешь автотесты, используя такие способы как “3” и “4” . То это не E2E тестирование. Потому что в такое случае приложение не ведет себя как пользователь. И соответственно такой тест, может не найти те баги, которые найдет тест, которые пишется с помощью способа “2”.
Приведу пример пары моих реальных тестов для наглядности. Думаю вы сразу все поймете.
Пример с использованием appStore
На двух видео представлен один и тот же тест
https://ibb.co/hXtgT2J - На этом видео, я через appStore приложения сразу ставлю поле с sql запросом в нужное мне состояние с нужным мне sql_id, тем самым избегая хрупкости селектора и тому подобное.
Но здесь мои коллеги мне говорят (Примерно процитирую): Цитата: При скролировании может быть какая-то ошибка, по этому неправильно сетить данные сразу в appStore, вместо того чтобы делать так, как делает пользователь
https://yapx.ru/u/FzcCI -На этом видео я использую только возможности UI и скролю вниз до тех пор, пока нужный id sql запроса не будет найден в списке. И здесь есть самое слабое место. Очень хрупкий селектор для выбора скрола, потому что наши разработчики уверены в том, что код приложения для тестирования менять неправильно или вроде того. По этому у меня нет id на этом элементе и мне приходится скакать по парентам и чилдренам чтобы добраться до нужного мне селектора. И любое изменение дерева, сразу ломает мне весь тест.
Пример с использованием API
Представьте простой кейс. “Редактирование пользователя” Шаги:
На примере работы моего тестируемого приложения. На скриншоте - https://ibb.co/jfkc6D8показано, что при нажатии на кнопку “Сохранить” на предыдущем шаге, отправляется запрос, который сохраняет пользователя и возвращает user_Id. По этому вместо того, чтобы создавать пользователя в автотесте через UI и затем через UI его редактировать, я сразу отправляю API запрос, в котором, в пререквизитах к автотесту, создается пользователь для редактирования. И Затем уже в UI интерфейсе я его редактирую
Но здесь мои коллеги мне говорят (Примерно процитирую): Цитата: Ты делаешь не как пользователь. Реальный пользователь приложения не может создать пользователя через API. Он создает и редактирует его через UI по этому и ты должен делать также.
Здесь очевидна проблема хрупкости теста, в котором на шаге создания пользователя для его редактирования, тест может отвалиться по любой причине. И до редактирования тест даже не дойдет.
Спасибо что дочитали до конца
Друзья. Подскажите пожалуйста. Как мне переубедить моих коллег. Какие аргументы мне им предъявлять. Чем оперировать? В чем я не прав? © 2010 | Software-Testing.Ru |
| В избранное | ||
