Расскажите правильный порядок следующих видов тестирования после раскатки сборки на стенд с новыми фичами и минорными дефектами.

К видам тестирования связанными изменениями относятся:
- Смоук-тестирование
- Регрессионное тестирование
- Ре-тест (повторное или подтверждающее тестирование)
- Санитарное тестирование
- Тестирование новой функциональности
А также тестирование сборки.

Мой ответ таков, а вы если, что дополняйте.
После раскатки нового билда на тестовый стенд мы сначала проводим смоук-тестирование, затем санитарное тестирование (хотя на проектах это тестирование не используется осознанно😁 и в целом можно не проводить или проводится бессознательно), потом проводим тестирование новой функциональности, и все же если в сборке есть дефект высшего приоритета чем приоритет новой фичи, то проводим сперва ретест, а затем тестирование new feature.
Проверили новую функциональность, выполняем повторное тестирование (ретест) минорных дефектов или дефектов приоритета ниже приоритета новой фичи, и уже потом заканчиваем регрессионным тестированием.

Такой мой ответ для собеса.
А какой ответ будет у вас?

#собеседование

Разбор вопросов и тестовых заданий … to continue…😀

Локализация бага:

Задача на локализацию бага: к примеру пользователь вводит почту, а экран белый? Как быть, твои действия

ИЛИ

При открытии сайта отображен белый экран - ваши действия?

Я напишу свои рассуждения, а вы дополняйте.

Хочу предложить варианты решения на данный вопрос про локализацию бага:
Первым делом!
🐞- очистить кэш и куки
А потом уже другие варианты🐞:
🐞- перейти на страницу chrome://settings/system и выключить аппаратное ускорение.
🐞- установить необходимые сертификаты для работы
🐞- уточнить у разработчиков на изменение хостов или обратиться к разработке на изменение кода или эндпойнтов
🐞- проанализировать логи в console DevTools
🐞- просмотреть сетевые запросы в network Devtools
🐞- проверить интеграцию с БД
🐞- открыть «Просмотр кода страницы» и запустить любой .js файл, и затем обновить тестируемую страницу
🐞- просмотреть логи сервера
🐞- просмотреть логи проекта / пода в консоли опеншифта
🐞- проанализировать логи в кибане, sentry, graylog, grafana, если есть эти инструменты на проекте
🐞- коммуницировать с командой на наличие возможного обновления требований

Не заводите сразу дефект, постарайтесь разобраться, изучить логи, проверить интеграцию с БД или данные в таблицах БД, или интеграцию с другим сервисом, куда может сохраниться адрес электронной почты.

Главное помните, что на собесах ждут ваших рассуждений, а не точного верного ответа.
Главное не молчать, а генерировать идеи!

Разбор вопросов будет продолжаться на @protestinginfo

Такой вопрос я задавала в рефлексии на курсе по тестам, который стартанет в июле.

#собеседование

Всем привет!
Хочу порекомендовать прочитать статью на хабре, которая мне понравилась:

Методы тестирования веб-API, которые должен знать каждый: чек-листы для начинающих

Здесь вы ознакомитесь с:
- Разделением тестирования: фронтенд vs бэкенд;
- Спецификой тестирования API;
- Типами тестирования;
- Позитивными и негативными тестами;
- Тестированием API на производительность;
- Тестированием сценариев.


А также хочу напомнить про свою статью:
💙Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
и посмотреть видео
Стратегия написания тест-кейсов по API

Разбор вопросов из нельзяграма (подписаться на аккаунт Protestinginfo)

Подписчице задали такой вопрос на
Локализацию бага:
⁉️Тестировщик в Postman через post создаёт пользователя (email и пароль), а ему приходит 200 статус код и пустой json.

А точно ли это баг?
Я считаю, что это нормальное поведение, если под пустым json понимается, что нет тела ответа от сервера. На скрине отображено нормальное поведение, и все же хотелось бы, чтоб был 201 статус код, например, документация без тела ответа от сервера "Code - 201; Denoscription - User has been registered and expects confirmation by e-mail"

Но если будет действительно пустое тело ответа от сервера как {} или ключи имеют значения null, то по сути это дефект, и здесь нужно провести локализацию бага.
Смотрим документацию и проверяем значения в таблице БД.

Помните ваша задача на собесе рассуждать, задавать вопросы интервьюеру.

Сперва я укажу ответы подписчиков:

▪️- Самый главный ответ, что дефект на бэкенде.
▪️- Обычно при создании пользователя приходит статус код 201.
▪️- Пустой json - это некорректный ответ от сервера.

Я скажу так, что эти ответы не относятся к локализации бага.

Было два ответа, относящиеся к локализации бага, и то, что как по мне понравится услышать интервьюеру.

- проверить данные в базе данных;
- проверить эндпойнт на корректность.

На помощь к ответу пришел Женя (канал Про Мир ИТ) и прочитайте его рассуждения.

У меня возникает два вопроса:
1. Какое апи?
2. Возвращается именно пустой json? Не пустой body, а именно json?

Если именно пустой json то вероятно да дефект.
Если просто пустое бади, то не факт.
Если это банальный REST то там жестких правил нету. Можно сделать POST запрос, где будет 200 статус код и пустое тело в ответе. И ничего криминального в этом не будет.

Я бы в первую очередь обратился к документации. Чтобы понять - а как должно быть? Прелесть апи в том, что по-любому документация есть. Даже если нет её в привычном понимании - есть реализованный код, в котором запрограммировано поведение, там указано и какой код ответа должен возвращаться и что должно возвращаться в теле ответа.

Если следовать мысли бест-практикс реализации restful, то здесь логичней 201 статус код и в теле ответа информация о созданном пользователе.

Статус код 201 в коде прописывается тут локализовать нечего.

Пустой json: идем в БД проверить, что запись создалась корректно. Если БД допускает null значения, то запись могла создаться с пустыми значениями. Если запись есть, но поля пустые - идем в логи и смотрим, что произошло в момент записи в БД.
Если запись корректна - то идём в логи смотреть что произошло когда апи "забирал" данные из БД.

🔷Запомните, что локализация бага - это процесс, направленный на анализ проблемы, которая возникает в приложении, на сервере, при интеграции двух сервисов и т.д..
🔺Наша задача выяснить причину возникновения данной проблемы.

Основные действия по локализации:
🔹- еще раз посмотреть имеющиеся требования на проекте;
🔹- в данном задании используется Postman, тогда просмотреть логи в console Postman;
🔵- проверить интеграцию с БД, просмотреть созданную запись пользователя в БД, и по-моему мнению, что была проблема в БД, вероятно, несоответствие типов данных или размера или длины значений данных;
🔹- присмотреть логи на сервере, или в других имеющихся инструментах по сбору логов на сетевые ошибки, недоступность или некорректная конфигурация систем;
🔹- также не исключаем: уточнить информацию на обновления кода в системе у разработчика / на обновления требований у аналитика - взаимодействовать с командой;
🔹- возможно, что здесь есть интеграция с другим сервисом и посмотреть доступность другого внешнего сервиса.

Работая инженером по тестированию важно научиться предугадывать ошибки, уметь читать и анализировать логи, тем самым навык локализации багов возрастет.

А также этот вопрос на проверку, вероятно, это не дефект, а вы начнете «копать» не в ту сторону 😁.
Добавляйте свои рассуждения.
А разбор вопросов буду продолжать.
@protestinginfo
и жду ваши реакции❤️✍️🔥, реакции еще больше мотивируют делиться с полезной информацией🥰

​​Вопросы, которые любят задавать на собеседовании не только на роль BA/SA, но и на роль QA Engineer.
Сохраняйте полезный пост 😎 и необходимые ссылки.