Комментарии 22
Я думаю составление тест кейсов это не совсем обязанность QA, их время дорого и они должны заниматься тестированием, а не менеджментом. Во многих компаниях тест кейсы пишут заказчики или менеджеры проекта, которые отвечают за функциональность.
У нас постановщики задач пишут тест кейсы ещё до начала программирования. Прямо в экселе где первый столбец - название теста, второй-четвёртый служебная информация, в пятом описание что нужно сделать, в шестом правильный результат и так далее. Если надо тест может состоять из шагов которые суть отдельные строчки.
После сохранения в CSV и подготовки тесты импортируются в джиру в виде тикетов. Шаги это подзадачи. Тестировщик набирает себе сотню тестов на спринт. В начале тестирования переводит тест в состояние "В прогрессе" и повторяет шаги в сабтасках, выставляя состояние "пройден" или "не пройден". Дальше в зависимости от проекта либо автоматически создаётся баг в проекте программистов, либо генерируется отчёт с ссылками на упавшие тесты.
Программисту очень легко пофиксить - в тесте ссылки на документацию, да и само описание теста не оставляет сомнений.
Импорт производится для каждого релиза, то есть начальник говорит надо протестировать билд такой-то. Девопс импортирует тесты и процесс повторяется.
Спасибо за комментарий!
Правильно ли я понимаю, что негативные сценарии тоже составляют постановщики задач?
В компаниях, где я работал, тестировщики составляли самостоятельно тест-кейсы для тестируемой ими функциональности.
А что вы понимаете под негативными сценариями?
Понимаю проверку реакции системы или приложения на некорректные или неожиданные входные данные.
В таком случае такие проверки никто кроме qa сделать не сможет, может фаззинг, но кто им пользуется:)))
В постановках на доработку, в частности в моей практике,
в рамках Use Case указываются негативные сценарии, но они больше для вывода ошибок бизнес логики, фиксации/логирования и отображения реакции системы на 1хх, 2хх, 3хх, 4хх, 5хх
То что вы пишите, мне кажется очень сложно спрогнозировать, за то и любим мы хороших и отличных qa, вы это чувствуйте.
Простите. А точно время тестировщика, которые по готовым тесткейсам идут должно быть дорогое? И где "менеджмент" в написании тесткейсов?
Извините, но не смог удержаться:
В прошлом году наша команда искала и нанимала QA‑инженеров с различным опытом, в том числе совсем начинающих.
Сколько в этом году джедаев QA выгнали (перед этим снабдив их знаниями о крайне нужной вне Сбера СУБД Pangolin)?
Давайте проверим корректность обработки минимального и максимального числа с 8 цифрами:
Сценарий 2: Строка 11111111 → ответ 200
00000000?
Нули, конечно, обсуждаются ниже по тексту. Но тогда постановка задачи некорректная.
Давайте проверим корректность обработки минимального и максимального числа с 8 цифрами:
Сценарий 2: Строка 11111111 → ответ 200
минимальное число с 8 цифрами 10000000
Сценарий 7: Строка 12 356 789 → ответ 503
Отправлено 8 цифр, должен был вернуться 200.
Возьмёте меня к себе работать? :)
Скажите, а статья подобного разбора тест-кейсов для Api будет?
Это хорошая статья. Для новичков это действительно очень полезно, так как в основном расскажут как это должно быть, но не приведут понятных примеров. Воды полно, практических примеров мало.
Честно скажу я бы до многого в статье просто бы не допер, ибо не знал основы... Но я бы обязательно проверил бы что-то типа
1234,5678
1234.5678
1234,567
1234.567
12345678,0
12345678.0
1E8
1234567*9
123456*9
NULL
NaN
NONE
2^22
В этой статье я покажу
Показательненько...
мы не проверили один из важных сценариев — обработку чисел с нулями
по логике ваших позитивных сценариев 00000000 система должна принимать за корректный ввод, что в реальности будет не так и что вы не стали проверять. а как система будет себя вести с классом значений 00000001-09999999, если она не обрезает нули? То что вы должны были сказать: набор ваших сценариев не может быть исчерпывающим, он определяется знанием о системе, техническими возможностями по выполнению и здравым смыслом и может быть дополнен.
Как составить тест-кейсы на собеседовании? Разбираем задачу с техсобеса для начинающих QA