про тестування та QA

За останні вихідні натрапив на дві публікації, так чи інакше пов’язані із автоматизацією тестування.

Перша (Sapient Processes, написана Джеймсом Бахом (James Bach)), зачіпає тему автоматизації загалом - що треба, що можна, а чого взагалі не варто автоматизовувати.

Друга стаття (Four implementation styles for workflow tests, від Браяна Маріка (Brian Marick)) на вужчу тематику - на тему створення т.з. workflow tests, які показують, як саме користувач виконав те чи інше завдання.

Обидві статті варті того, щоб ознайомитися із їхнім змістом.

У статті Бах (James Bach) розповідає про один зі способів виходу з ситуації, коли замовники визначають, про які баги звітувати, а які залишити в спокої (“Не тестуйте інсталятор. Цим ми займаємося самі”). Часто після закінчення проекту ці замовники нарікають на те, що відділ тестування пропустив серйозні помилки саме в тих модулях, які просили не тестувати.

Тому автор рекомендує звітувати про всі знайдені баги. Якщо ж баг стосується забороненої області, або є невизначеним, його позначають як “mipping” (Mention In Passing - “Згадка по Ходу”). Саме в цьому статусі про такі баги відділ тестування звітує в статус-репортах та мейлах. Таким чином, тестувальники, з одного боку, не витрачають марно свій час на ті проблеми, якими їм сказали не займатися, з другого боку маючи документальне підтвердження того, що проблема була знайдена.