#testing #interview
Ben Fellows поділився цікавим підходом для оцінки рівня тест інженерів на співбесіді. Зазвичай, Ben шукає кандидатів рівня 3 або 4.
Питання:
"Потрібно випустити важливий реліз, але час на тестування обмежений. Як Ви будете пріоритезувати тестові активності, в залежності від ризиків та впливу на користувача та бізнес?"
1️⃣Рівень 1 - Реактивний та сфокусований на задачі.
Я почну з тестування логіну та покупки, тому що вони найголовніші.
2️⃣Рівень 2 - Баланс між технічними та бізнес потребами, але без структурованого підходу.
Я сфокусуюсь на модулях, що були змінені нещодавно та головних фічах, типу покупок (враховуючи їх залежності)
3️⃣Рівень 3 - Використання структурованих фреймворків, пріоритезація ризиків, вибір тестових активностей в залежності від бізнес задач.
Я приоретизую тестування за допомогою матриці ризиків, щоб зрозуміти ймовірність виникнення ризику та його можливий вплив. Найбільш ризиковий функціонал, як-от покупки, буде протестований найпершим. Я також застосую дослідницьке тестування для виявлення інших ризиків та скооперуюся з продуктовою командою щоб визначити найбільш важливі фічі для бізнесу.
4️⃣Рівень 4 - Застосування системного мислення, прогнозне моделювання та безперервне покращення
Я зроблю карту системних залежностей, приоритезую найкритичніші фічі для бізнесу (такі як безпека та оплата), автоматизую регресійні тести для відомих ризиків. Мануальне тестування буде фокусуватись на дослідницьких сценаріях. Після релізу, я буду збирати фідбек для покращення наявних стратегій та підходів.
❓А ви як думаєте? Яка відповідь найкраща?
