2022-08-02 09:45:16
Відповідь на питання від одного зі слухачів DOU QA подкасту.**Дякую! Дуже цікава розмова. Є околопрактичне запитання: у нас на проєкті був інцидент, коли продакт менеджер описав тікет, розробник його зробив, а коли тестування почав перевіряти, виявилося, що всі троє по-своєму читають тікет (в якихось деталях). Як у вас вирішувались такі моменти? Чи були для цього якісь особливості в процесах, на кшталт спеціального мітингу, де всі читають і обговорюють специфікацію та/або тікети, тощо?
Найчастіше баги виникають саме через не правильну інтерпретацію вимог. Саме тому перед тим як робити якусь фічу потрібно спочатку домовитись, щоб всі учасники процесу розуміли фічу та вимоги однаково. Спираючись на свій досвід я зрозумів, що в незрозумілій ситуації краще задати питання і домогтися відповіді аніж робити фічу на свій погляд і потім переробляти. Якщо говорити про процесну частину, то в команді завжди має буди backlog refinement(ака grooming) де вся команда може обговорити задачі та знайти спільне розуміння. На цьому мітингові потрібна присутність всіх учасників, бо дуже часто QA туди не беруть. Якщо у вас такого нема, беріть скрам гайди, несіть в команду показуйте, розказуйте. Якщо воно є, активно беріть участь, бо дуже часто на грумінгу всі кивають головою і розпинається тільки скрам майстер та team lead.
Ще один мітинг на якому ви можете говорити про проблеми - це ретроспектива. Ця зустріч створена для того, щоб ви дали зворотний зв'язок, що працює, що треба покращити.
Насправді в колаборації саме головне це вміння ставити питання, та не боятися цього робити. Правильно і вчасно поставлене питання під задачею збереже вашій команді купу часу та грошей.
Цікаво. А які підходи використовуєте ви? Пишіть в коментарях
4.1K views06:45
