Ответ
Процесс строился на принципах Agile (Scrum) с активным вовлечением QA на ранних этапах.
Ключевые практики:
- Backlog Refinement: Регулярные сессии с Product Owner (PO), разработчиками и QA для детализации user stories в Jira.
- Критерии приемки (Acceptance Criteria): PO формулировал AC, а QA команда дополняла их проверочными сценариями и edge-кейсами.
- BDD-подход для сложных фич: Совместная разработка сценариев на Gherkin перед началом спринта.
Пример BDD-сценария:
Feature: Password Reset
Scenario: Successful password reset via email
Given the user is on the password recovery page
When the user enters a registered email address "user@example.com"
And clicks the "Reset Password" button
Then a confirmation message "Instructions sent to your email" is displayed
And a reset token is generated in the databaseРоль QA в процессе:
- До спринта: Участие в планировании, анализ требований на тестируемость, выявление противоречий и рисков.
- В начале спринта: Создание тест-кейсов в TestRail/Allure на основе согласованных требований.
- По ходу разработки: Уточнение деталей у PO или разработчиков через комментарии в задаче или на daily stand-up.
Инструменты: Jira для задач, Confluence для документации, совместные доски (Miro) для воркшопов.
Ответ 18+ 🔞
Да ты посмотри, какая красота, блядь! Процесс-то у нас был выстроен по всем канонам Agile, а конкретнее — Scrum, ёпта. И самое главное — QAшников не держали в подвале до последнего, а тащили в самое пиздатое начало, на этап обсуждений. Не «вот тебе фича, иди тестируй, что непонятно», а нормально, с человеческим лицом.
Чё мы там делали, блядь:
- Backlog Refinement, или «чё там по задолженностям?»: Регулярно садились с Product Owner'ом, разработчиками и нами, тестировщиками, и начинали ковырять каждую user story в Jira. Пока не становилось понятно, что за хуйню мы вообще должны делать.
- Критерии приемки (Acceptance Criteria): PO, конечно, их накидывал. Но мы, как хитрая жопа, сразу лезли и дополняли: «А вот если пользователь — идиот и введёт сюда ебушки-воробушки? А если интернет отвалится ровно в этот момент?». Чтобы потом не было «ой, а мы не договаривались».
- BDD для особо замудрённых фич: Если задача была сложная, с кучей условий, мы до начала спринта садились и писали сценарии на этом самом Gherkin. Чтобы все — и PO, и dev, и QA — одним ебалом дышали и понимали, что должно получиться.
Вот, смотри, пример такого сценария, блядь:
Feature: Password Reset
Scenario: Successful password reset via email
Given the user is on the password recovery page
When the user enters a registered email address "user@example.com"
And clicks the "Reset Password" button
Then a confirmation message "Instructions sent to your email" is displayed
And a reset token is generated in the databaseКрасота же, ёпта? Всё прозрачно, как слёзы ребёнка. Никаких «ну оно как бы должно работать».
А наша, QAшная, роль была какая, блядь?
- До спринта: Мы в планировании участвовали, требования щупали на предмет тестируемости, искали противоречия. Чтоб потом не вылезло: «ой, а это технически невозможно проверить, простите».
- В начале спринта: Как только задачи понятны — сразу в TestRail или Allure пишем тест-кейсы. Не в последний день, блядь, а сразу.
- По ходу разработки: Если что-то в процессе стало неясно — не молчали, как партизаны. Уточняли у PO или разработчиков прямо в комментах к задаче или на ежедневном стендапе. «Вася, а вот этот момент, он как должен отрабатывать? А то у меня подозрение ебать чувствую».
Инструменты? Да обычные, блядь: Jira для задач, Confluence для всяких документов, а для мозговых штурмов — совместные доски в Miro. Всё честно, без подвохов. Главное — вовремя включить мозг и не бояться задавать вопросы, даже если они кажутся тупыми. Потому что лучше выглядеть идиотом пять минут, чем потом месяц расхлёбывать последствия.