Yet another QA
tg6.5 тыс. подписчиков
Открыть пост ↗
Про приоритеты
Октябрь выдался непростым - и мыслей про приоритеты и качество накопилось много, но пока хочется поговорить о них на учебных примерах.
«Связано с деньгами» — а что чиним первым?
Недавно на практикуме по дефектам я дала студентам по четыре учебных бага на группу. Нужно было описать каждый, решить, в каком порядке их чинить, а потом отдать свои отчёты соседней группе на ревью. После ревью можно было поменять порядок и объяснить почему.
В одном задании было два бага про цену. В одном кейсе неправильно посчиталась скидка, в другом не сходился итог в корзине. И вот тут классический аргумент «это связано с деньгами, значит критикал» подходит к обоим. А что тогда ставим первым? Какую сумму человек увидит перед оплатой? Какую с него реально спишут? А что, если у нас черный ящик?
Мне интересно, что студент будет делать после «я нашёл баг». Какие данные ещё соберёт? Что напишет в отчёте, чтобы другая команда могла разобраться без обсуждения с автором? И поменяет ли своё решение, если на ревью всплывёт что-то новое?
С API та же история. Отправили запрос на создание заказа, получили 201, в ответе есть ID. Уже можно сходить за заказом по этому ID и проверить, какую сумму сохранили. А потом попробовать открыть его от имени другого пользователя. Из одного запроса уже выросло несколько вполне разных проверок
И немного полезного по теме
• 20 проверок API: В блоге Нетологии на Хабре берут один сценарий с заказом и разбирают на нём ответ, права и то, что сохранилось после запроса. Можно взять первые несколько проверок и повторить в Postman. [Статья на Хабре]
• Про чужие заказы и не только: у OWASP есть короткий разбор того, как пользователь может получить доступ к чужим данным, просто поменяв ID в запросе. [Разбор OWASP]
• Где попробовать на живом примере: Restful Booker - учебное API для бронирований, в котором специально оставили баги. Можно создать бронь, поменять даты и проверить, что сохранилось. [Restful Booker]
• Как съесть пончик и не оставить дырок в платежах: доклад Екатерины Голдиновой из «Островка!» на SQA Days. Хорошее продолжение вопроса «а сколько с человека реально списали?». Екатерина рассказывает, что проверять на стыке с платёжной системой, где может подвести тестовый стенд и с каких проверок начать. [Открытая запись доклада]
• Вышло обновление моей любимой подборки каналов про тестирование - мы с участниками проголосовали за самые крутые, живые и полезные каналы и очень довольны результатом [подписаться]
Октябрь выдался непростым - и мыслей про приоритеты и качество накопилось много, но пока хочется поговорить о них на учебных примерах.
«Связано с деньгами» — а что чиним первым?
Недавно на практикуме по дефектам я дала студентам по четыре учебных бага на группу. Нужно было описать каждый, решить, в каком порядке их чинить, а потом отдать свои отчёты соседней группе на ревью. После ревью можно было поменять порядок и объяснить почему.
В одном задании было два бага про цену. В одном кейсе неправильно посчиталась скидка, в другом не сходился итог в корзине. И вот тут классический аргумент «это связано с деньгами, значит критикал» подходит к обоим. А что тогда ставим первым? Какую сумму человек увидит перед оплатой? Какую с него реально спишут? А что, если у нас черный ящик?
Мне интересно, что студент будет делать после «я нашёл баг». Какие данные ещё соберёт? Что напишет в отчёте, чтобы другая команда могла разобраться без обсуждения с автором? И поменяет ли своё решение, если на ревью всплывёт что-то новое?
С API та же история. Отправили запрос на создание заказа, получили 201, в ответе есть ID. Уже можно сходить за заказом по этому ID и проверить, какую сумму сохранили. А потом попробовать открыть его от имени другого пользователя. Из одного запроса уже выросло несколько вполне разных проверок
И немного полезного по теме
• 20 проверок API: В блоге Нетологии на Хабре берут один сценарий с заказом и разбирают на нём ответ, права и то, что сохранилось после запроса. Можно взять первые несколько проверок и повторить в Postman. [Статья на Хабре]
• Про чужие заказы и не только: у OWASP есть короткий разбор того, как пользователь может получить доступ к чужим данным, просто поменяв ID в запросе. [Разбор OWASP]
• Где попробовать на живом примере: Restful Booker - учебное API для бронирований, в котором специально оставили баги. Можно создать бронь, поменять даты и проверить, что сохранилось. [Restful Booker]
• Как съесть пончик и не оставить дырок в платежах: доклад Екатерины Голдиновой из «Островка!» на SQA Days. Хорошее продолжение вопроса «а сколько с человека реально списали?». Екатерина рассказывает, что проверять на стыке с платёжной системой, где может подвести тестовый стенд и с каких проверок начать. [Открытая запись доклада]
• Вышло обновление моей любимой подборки каналов про тестирование - мы с участниками проголосовали за самые крутые, живые и полезные каналы и очень довольны результатом [подписаться]
Новый список