Auftragstaktik и тестеры
Инженеры из Codedgers спрашивали меня, каким образом Auftragstaktik может быть практически применен к работе тестера. Я обещал подумать. И подумал. Вот один из вариантов.
В мой комментарий в дискуссии по данному посту.
http://cartmendum.livejournal.com/54913.html
Обсуждается немецкий Auftragstaktik, и мое "декларативное (событийное) планирование".
Комментарий - вот.
> Тестирования, разработка... Какая разница? Auftragstaktik - это подход к решению проблем более высокого уровня абстракции.
> Думаю этот стиль ляжет на тестирование не сложнее, чем на разработку. Нужен только объективный критерий достижения цели, то есть возможность ответить на вопрос "Правда ли, что я протестировал это достаточно хорошо?".
> В качестве критерия завершения тестерской задачи можно выбрать, например, следующий:
> 1. Покрытие кода по уровню (вставить нужное из "Statement Coverage"/"Decision Coverage"/"Modified Condition/Decision Coverage") составляет не менее XX%
> 2. Покрытие требований составляет не менее YY%
> 3. Все аномалии, обнаруженные в ходе теста имеют описание.
Вполне себе вариант. Примерно так я формулировал эту цель пару лет назад.
Тока - теперь я бы плясал от другого. Глядя на данный критерий - возникает вопрос - а то ли это, что мы на самом деле хотим от тестирования? Зачем вообще нужны тестеры? Пользователю есть разница - 100% кода у нас покрыто тестами, или нет? А вдруг - на практике 95% пользователей своими действиями покрывают только 40% кода? А может быть, пользователи страдают больше от неудобства и неинтуитивности гуя, чем от его несоответствия 60% кода, который они не вызывают, вызывают редко, или вполне могут без его функциональности обойтись - нашим внутренним спецификациям?
Так зачем нам все-таки нужны тестеры? Чтобы это понять, давай тестеров уберем. Пользователь станет недоволен, не так-ли? Но скажет ли он при этом что-нибудь про "низкий процент покрытия"? Вряд ли - он будет недоволен потому, "что вашей программой невозможно пользоваться. Вот у вас в фичлисте на сайте написано вот это - а оно либо не работает, либо делается через жопу".
Мы этого не хотим, и поэтому, а не почему-нибудь еще, заводим тестеров. Получаем в результате интересную штуку. Следуя Auftragstaktik, миссия тестеров формулируется иначе.
Тестеры - это такой мегакомпетентные парни и девчонки, которые:
- вместо того, чтобы накрыть программера матюгами, способны внятно и точно описать найденную проблему. С позиции пользователя.
Это означает, что они для выполнения своей миссии должны проверять вовсе не соответствие поведения проги бумажке (пользователя волнует эта внутренняя бумажка? да пофиг ему). Он должен удостовериться в ценности реализованной фичи для пользователя - в том, что реализованная возможность решает ту проблему пользователя, ради которой создана данная фича.
Тестер, который работает по Auftragstaktik - профессионал высокого класса. Он понимает проблемы пользователя, и компетентен в предметной области. Он умеет отличать неинтуитивное поведение от простого и удобного. Он разбирается в вопросах юзабилити.
И он тестирует поведение не на соответствие бумажке, а на соответствие духу, замыслу, проблеме - ради решения которой фича сделана.
Чтобы это сделать - он должен, тестируя фичу, как минимум, быть знакомым с проблемой - так? И было бы в корне неправильно снабжать тестера информацией, которая будет недоступна пользователю. Он должен располагать той же документацией, которая есть у пользователя, чтобы в том числе найти несоответствие документации программе. И чтобы выписывать дефекты на документацию.
В работе тестера можно выделить два последовательных этапа.
1. Тестер полностью протестировал фичу, выдав обратную связь.
2. Тестер подтвердил, что фича готова к выпуску.
Продолжая предлагаемую логику, задание группе тестеров выдается в виде фичлиста. У каждой фичи - три цвета (красный, желтый, зеленый), соответствующее текущему закрытому этапу. Прогресс (и готовность продукта у выпуску) на высоком уровне отслеживается, например, по общему проценту желтости, зелености, или красности фичлиста.
План тестирования можно структурировать и упорядочить, объединяя фичи (и их юзкейсы) в группы (по самым разным признакам - здесь очень много вариантов), и упорядочивая их по времени.
И этот план тестирования может стать основой для плана разработки.
Вот один из вариантов, который на мой взгляд, в полной мере полагается на Auftragstaktik.
В мой комментарий в дискуссии по данному посту.
http://cartmendum.livejournal.com/54913.html
Обсуждается немецкий Auftragstaktik, и мое "декларативное (событийное) планирование".
Комментарий - вот.
> Тестирования, разработка... Какая разница? Auftragstaktik - это подход к решению проблем более высокого уровня абстракции.
> Думаю этот стиль ляжет на тестирование не сложнее, чем на разработку. Нужен только объективный критерий достижения цели, то есть возможность ответить на вопрос "Правда ли, что я протестировал это достаточно хорошо?".
> В качестве критерия завершения тестерской задачи можно выбрать, например, следующий:
> 1. Покрытие кода по уровню (вставить нужное из "Statement Coverage"/"Decision Coverage"/"Modified Condition/Decision Coverage") составляет не менее XX%
> 2. Покрытие требований составляет не менее YY%
> 3. Все аномалии, обнаруженные в ходе теста имеют описание.
Вполне себе вариант. Примерно так я формулировал эту цель пару лет назад.
Тока - теперь я бы плясал от другого. Глядя на данный критерий - возникает вопрос - а то ли это, что мы на самом деле хотим от тестирования? Зачем вообще нужны тестеры? Пользователю есть разница - 100% кода у нас покрыто тестами, или нет? А вдруг - на практике 95% пользователей своими действиями покрывают только 40% кода? А может быть, пользователи страдают больше от неудобства и неинтуитивности гуя, чем от его несоответствия 60% кода, который они не вызывают, вызывают редко, или вполне могут без его функциональности обойтись - нашим внутренним спецификациям?
Так зачем нам все-таки нужны тестеры? Чтобы это понять, давай тестеров уберем. Пользователь станет недоволен, не так-ли? Но скажет ли он при этом что-нибудь про "низкий процент покрытия"? Вряд ли - он будет недоволен потому, "что вашей программой невозможно пользоваться. Вот у вас в фичлисте на сайте написано вот это - а оно либо не работает, либо делается через жопу".
Мы этого не хотим, и поэтому, а не почему-нибудь еще, заводим тестеров. Получаем в результате интересную штуку. Следуя Auftragstaktik, миссия тестеров формулируется иначе.
Тестеры - это такой мегакомпетентные парни и девчонки, которые:
- вместо того, чтобы накрыть программера матюгами, способны внятно и точно описать найденную проблему. С позиции пользователя.
Это означает, что они для выполнения своей миссии должны проверять вовсе не соответствие поведения проги бумажке (пользователя волнует эта внутренняя бумажка? да пофиг ему). Он должен удостовериться в ценности реализованной фичи для пользователя - в том, что реализованная возможность решает ту проблему пользователя, ради которой создана данная фича.
Тестер, который работает по Auftragstaktik - профессионал высокого класса. Он понимает проблемы пользователя, и компетентен в предметной области. Он умеет отличать неинтуитивное поведение от простого и удобного. Он разбирается в вопросах юзабилити.
И он тестирует поведение не на соответствие бумажке, а на соответствие духу, замыслу, проблеме - ради решения которой фича сделана.
Чтобы это сделать - он должен, тестируя фичу, как минимум, быть знакомым с проблемой - так? И было бы в корне неправильно снабжать тестера информацией, которая будет недоступна пользователю. Он должен располагать той же документацией, которая есть у пользователя, чтобы в том числе найти несоответствие документации программе. И чтобы выписывать дефекты на документацию.
В работе тестера можно выделить два последовательных этапа.
1. Тестер полностью протестировал фичу, выдав обратную связь.
2. Тестер подтвердил, что фича готова к выпуску.
Продолжая предлагаемую логику, задание группе тестеров выдается в виде фичлиста. У каждой фичи - три цвета (красный, желтый, зеленый), соответствующее текущему закрытому этапу. Прогресс (и готовность продукта у выпуску) на высоком уровне отслеживается, например, по общему проценту желтости, зелености, или красности фичлиста.
План тестирования можно структурировать и упорядочить, объединяя фичи (и их юзкейсы) в группы (по самым разным признакам - здесь очень много вариантов), и упорядочивая их по времени.
И этот план тестирования может стать основой для плана разработки.
Вот один из вариантов, который на мой взгляд, в полной мере полагается на Auftragstaktik.