В прошлом году James Whittaker и Alberto Savoia породили интересуню дискуссию на тему смерти тестирования вообще или в конкретных его проявлениях.
Янезнаючтоэтозначит, но оба, кстати, недавно покинули Google.
Еще не успела улечься эта волна дискуссий, как на прошлой неделе свет наш Cem Kaner
заявил, что:
Даже если когда-то и существовала контекстная школа тестирования, то отныне ее нет.
Для того, чтобы разобраться в том, что случилось стоит вспомнить что вообще представляют из себя школы тестирования и какие они бывают.
Школы? Что это?
Эксперты в тестировании ПО очень часто не соглашаются друг с другом, спорят и вообще ведут себя странно в силу ряда причин, которые во многом кроются в сильно разных, зачастую противоречивых теоретических базах, подходах, разном определении одних и тех же терминов и еще сотне-тысяче других причин.
До 2003-го года общение на почве тестирования было затруднено, но ясно солнышко Bret Pettichord (дальше местами будет вольный пересказ его тезисов) сотоварищи постарался и ввел такое понятие как Школы Тестирование ПО. Эти школы это не "Средняя школа №17", а скорее что-то сродни школам мышления, научным школам.
Bred Pettichord это один из основателей контекстной школы, так что это разделение на школы в основном дело рук именно этих граждан.
На данный момент принято считать, что школ пять: Аналитическая, Стандартная, Обеспечения Качества, Контекстная и Школа Гибкого
(Agile) Тестирования.
Школа не определяется какими-то специфичными техниками - все школы в той или иной мере используют все известные техники.
У школы нет своей доктрины.
Как правило школа это набор общих целей, ценностей, терминологии и, возможно, каких-нибудь организационных институтов (ISTQB, например).
Эта классификация имеет ряд приятных эффектов.
Во-первых они сильно облегчает дискуссию, поскольку уже не обязательно проходиться по поверхностным пунктам из-за которых эксперты не соглашаются и переходить сразу к настоящей причине разногласий.
Во-вторых это сильно упрощает обучение, т.к. тестировщик-самоучка начитавшийся всего подряд из разных источников рискует заработать себе в голове много взаимоисключающих устверждений, т.е. фарш.
С другой стороны в случае, если у вас в команде окажутся особо ортодоксальные последователи разных школ, то могут возникнуть серьезные проблемы. Да в общем-то хватит и парочки упертых тестировщиков, тупо заучивших какие-то вещи и не понимающих зачем и почему они нужны. Но это уже очень грустный клинический случай, не будем на нем останавливаться подробно.
Аналитическая Школа
Аналитическая Школа делает упор на спецификации, анализ и все что можно легко померить. Они очень много усилий уделают поиску объективных метрик и способов измерения чего-либо касающегося качества. Процент выполненной работы, степень точности результата, покрытие кода - это практически краеугольные камни Аналитеской школы.
ПО для Аналитической школы это целиком и полностью логический артефакт.
Тестирование - ветка Cumputes Science/Математики (т.е. объективный, понятный, регулируемый процесс)
Любые техники тестирования должны давать один правильный ответ, т.е. принимают четкую логико-математическую форму.
В итоге такое тестирование требует как можно более детальной спецификации, а процесс построен во многом вокруг сверки спецификации и конечного продукта. Эти проблемы практически нерешаемые, да и авторы этой школы сосредоточены больше на других вопросах - вопросе выбора техник обеспечивающих максимальное покрытие.
Pettichord в качестве примера авторов этой школы приводит Бориса Бейзера.
Стандартная Школа
Она же бывшая Заводская. Во многом она калькирует промышленное производство, постулируя что тестирование это повторяемый процесс, являющийся во многом частью конвейера. Во многом из этого вытекает, что представители этой школы стараются найти минимально возможный рабочий ресурс для выполнения той или иной работы.
Матрица покрытия требований хороший пример данной школы. Ее основной принцип - все требования и тесты для них (или наборы тестовых случаев) должны быть перечислены и когда все тесты прошли успешно - продукт можно выпускать. Это очень интересный артефакт, который как правило не работает в полной мере, т.к. требования меняются или могут быть просто неточными, а тесты так же не всегда показывают то, что мы считаем они должны показывать (см.
предвзятость подтверждения). Т.е. в итоге можно получить софт сомнительного качества, но зато все клеточки зелененькие.
Тестирование с Стандартной Школе это фактически измеритель прогресса.
Тестирование в ней должно быть легко управляемым, предсказуемым, повторяемым и легко планируемым. А так же эффективно по цене (дешевая рабочая сила под мудрым управлением).
Весь процесс должен быть хорошо регламенирован, так что основным вопросом является выбор правильных метрик.
Это вносит ряд сложностей, т.к. это практически ничем неприкрытый Тейлоризм, требующий четких границ между тестированием и любой другой активностью, т.е. четких критериев начала/остановки работы.
Так же с такими подходами очень сложно вносить изменения в уже имеющиеся планы.
Зато последователи этой школы очень много сделали на поприще генерации бесчисленных стандартов, "лучших практик" и сертификаций. В частности они породили мой любимый
IEEE Standard Classification for Software Anomalies.
Рекс Блэк отличный представитель данной школы, даже в последнем интервью для uTest сообщивший что основной проблемой тестирования является сложность подбора хороших, годных метрик.
Школа Контроля (Качества)
Школа Контроля Качества больше фокусируется на стандартах и процессах. Согласно их утверждениям тестирование является своего рода хранителем продукта.
Pettichord использует роль хранителя продукта как ключевой пример этой школы. Тест менеджер или QA лид является единственным лицом, которое решает можно релизить продукт или еще рано. Эдаким защитником конечного пользователя от плохого продукта. Это одно из основных отличий от остальных школ, где подобные решения возлагаются на менеджмент или же на всю команду.
Подобный подход требует чтобы помимо ответственности у контролирующего были и возможности остановить выпуск продукта, если он считает, что продукт слишком низкого качества чтобы его выпускать. Я видел случаи, когда компании пытались применять подобные стратегии, но в итоге когда менеджменту действительно хотелось чтобы продукт увидел свет, ответственного QA лида просто отодвигали в сторонку и выпускали продукт несмотря на его качество. Очень неприятные ощущения, надо сказать. Ведь если у вас есть ответственность и обязанность говорить что продукт выпускать нельзя, но нет никакой возможности приостановить выпуск, то, возможно, скоро на вам станут смотреть как на того мальчика, который кричал про волков. Есть и другой вариант - "идеальное качество у того продукта, который так никогда и не был зарелизен".
Такой подход может работать, если соблюден должный баланс ответственности и возможностей, а так же, если у ответственного лица есть возможность непосредственно влиять на процесс (и, желательно, только у него). В ряде случаев такие роли приводят к тому, что ответственное лицо фактически никаким тестированием не занимается.
Контекстная Школа
Контексттная школа это своего рода Agile Manifesto для тестировщиков. Оно базируется на следующих принципах:
- Ценность любой практики зависит от контекста ее применения
- Есть хорошие практики для определенного контекста, но нет лучших практик
- Люди работающие вместе это самая важная часть контекста проекта
- Проекты со временем могут развиваться совершенно непредсказуемымо
- Продукт это решение. Если проблема не решена, то продукт не работает
- Хорошее тестирование ПО это сложный интеллектуальный процесс
- Только через суждения и навыки используемые совместно по всему проекту могут привести к выполнению правильных вещей в правильное время для того чтобы эффективно протестировать ваш продукт
Контекстная школа и по сей день является одним из самых ярых сторонников исследовательского тестирования. В других школах так же применяются подобные практики, но в данном случае Bred ииспользовал этот пример потому, как он отдает все внимание продукту и людям, а не процессу, который, согласно Контекстной Школе, вторичен.
Как и Agile Manifesto пообный подход для многих показался слишком открытым и абстрактным, к тому же он не дает серебряной пули на все случаи жизни, не дает лучших практик, которые всегда спасут. К тому же у ряда кампаний/проектов есть определенные, жесткие жизненные циклы, вокруг которых выстроены избыточные процессы, которым обязательно нужно следовать. В такой среде контекстное тестирование не очень часто приживается.
Школа Гибкого Тестирования
Основные принципы этой школы предельно ясны - она фокусируется вокруг концепции непрерывной поставки. Всегда должен быть рабочий софт, который можно отправлять в мир.
Эта школа концентрируется вокруг массовой автоматизации всего. TDD, unit тесты и так далее. Все это аттрибуты этой школы (нет, другие школы тоже их могут использовать, но гибкого тестирования без этого просто быть не может). Кто-то из тестировщиков может сказать что это все дела разработчиков, но ему стоит задуматься хотя бы над тем, что такие компании как Microsoft или Google отказались от концепции тестировщика, который занимается только тестированием и нанимают SDET - разработчиков, которые занимаются тестированием.
В ряде случаев все ограничивается повальной автоматизацией и приемочными тестами, которые зачастую тоже автоматизируются. Никаких тестировщиков, только серверная стойка. В такой среде практически нет места для других школ, но большая часть команд разработки не настолько agile, чтобы себе это позволить.
Весьма примечательно, что в истоках этой школы стоят очень хорошо подкованные технически представители Контекстной Школы и люди, которые никогда не называли себя тестировщиками и/или QA/QC.
Промежуточное Итого
Bret Pettichord фактически является автором этого разделения, которое основатели Контекстной Школы подхватили и начали использовать как базис для дискуссий. Представители остальных школ со временем тоже взяли это деление на вооружение, хотя тот же Борис Бейзер первое время утверждал что знать не знает ничего ни о каких школах и не желает в этом принимать участие. Но со временем и они втянулись.
Это привело к определенной поляризации сообества и, местами, к более жесткой риторике, поскольку теперь неприятель был снабжен соответствующим ярлыком.
Но как представляется лично мне, Школы тестирования это отличная база для дискуссий, обучения и понимания. Но в реальности мы работаем не в рамках Школы, а в рамках организаций, у которых есть свой контекст, своя культура, свои цели, которым служит тестирование. В одних случаях лучше приживаются и работают одни Школы, в других другие. И когда мы собираемся на какую-то конференцию было бы неплохо иметь хорошую классификацию, чтобы не спорить о незначащих деталях, когда главная проблема кроется не в них, а в разице мировоззрения/парадигм.
Когда мы идем устраиваться на работу классификация тоже может пригодиться, чтобы не работать в идеологически далекой от вас среде, так как если у вас есть хоть какие-то принципы и устоявшиеся взгляды на тестирование, то работать в таких условиях может быть очень неприятно.
Вместо Послесловия
У Контекстной Школы, породившей это разделение, было четыре основателя.
Brian Marick тихо ушел в сторону.
Bret Pettichord
заявил, что Контекстное Тестирование это Гибкое Тестировние и тихонько ушел в ряды Гибкой Школы.
Cem Kaner
написал, что школы нет, даже если она когда-нибудь была и всячески отрицает концепцию школ.
И, как я уже заметил в начале статьи - James Whittaker и Alberto Savoia практически сразу после своих замечательных выступлений на тему "Test is Dead" покинули Google, где занимали руководящие посты в тестировании.
Прямо сейчас на наших глазах разворачиваются очень интересные события в мире тестирования - он меняется довольно быстро и, порой, весьма неожиданно. Это время возможностей. Это открытое будущее.
