Смысл тестирования — в процессе, а не в оставшихся артефактах. Майкл Болтон и Rapid Software Testing
В среде ИТ есть свои легенды, чьи имена знает сегодня чуть ли не каждый и чьи (что важнее) достижения в профессии показали другим новый путь к развитию. Одной из таких фигур для мира тестирования ПО был и остается Майкл Болтон, которого мы ждем на ближайшем Heisenbug 2018 Piter. В этой статье мы поговорим о Rapid Software Testing, о Майкле и его докладах.
Имея за плечами 20-летний опыт тестирования, разработки, управления и написания программного обеспечения, Майкл не просто не устает учить других, как делать тестирование наиболее эффективно, но и разрабатывает новые подходы к, казалось бы, привычному искусству тестирования ПО. Он налетал более миллиона миль на самолете, проведя сотни и сотни консультаций, лекций, учебных- и мастер-классов, и всё еще полон сил наставлять специалистов по всему миру на путь истинный — проводить тестирование быстро и эффективно.
Майкл, вместе со своим другом и коллегой Ричардом Бахом, является соавтором отличной методологии и набора воззрений, который они называют Rapid Software Testing и о которой я решил сегодня рассказать. Rapid — это не про то, как побыстрее прогнать набор тестов, нет. Совсем наоборот, разговор о том, чтобы убрать из работы тестировщика рутину и ощущение бесконечного потока новых багов.
Авторы RST описывают его примерно так: это набор подходов и навыков, заточенный на то, чтобы делать тестирование быстрее, дешевле и с отличными результатом. Это методология, учитывающая, как люди учатся и самоорганизовываются под давлением обстоятельств. RST исходит из интересных посылок:
- Процесс создания программного продукта — это отношения между людьми, как эмоциональные, так и рациональные.
- Каждый проект находится в условиях неопределенности и давления фактора времени.
- Несмотря на наши лучшие ожидания и намерения по отношению к проекту, некоторая степень неопытности, небрежности и некомпетентности является нормальной.
- Тест — это деятельность; смысл его в процессе, а не в артефактах.
- Цель тестирования — выявить статус производимого продукта и оценить, что может угрожать его полезности, так, чтобы наши клиенты могли принимать обоснованные решения по поводу него.
- Мы обязуемся проводить надежное и экономически эффективное тестирование, и мы будем информировать наших клиентов о чем-либо, что угрожает этому обязательству.
- Мы не станем сознательно или по небрежности вводить в заблуждение наших клиентов и коллег.
- Тестеры несут ответственность за качество своей работы, хотя они не могут контролировать качество продукта.
Мысли интересные, но еще интереснее познакомиться с подводящими к ним аргументами. Они просты, но порой заставляют по-новому взглянуть на привычное, в частности, на само понимание, в чём цель нашей работы.
Зачем в принципе проводить тестирование ПО? Как ни хочется сказать, что мы делаем его ради уменьшения числа ошибок в каждом очередном релизе нашей программы, правильный ответ звучит иначе: при помощи тестирования руководство проекта получает оценку рисков того, что разрабатываемое ПО поведёт себя не так, как ожидается. В итоге тестированием мы боремся не с тем, чтобы ошибок в программе не было вовсе, а оцениваем, насколько и нам, и пользователям будет хуже, если мы выпустим продукт с текущим числом недоработок и багов.
Многие воспринимают тестирование ПО просто: к каждой функции нашего кода пишется небольшая проверка, дающая возможность убедиться, что при каких-то определённых входящих значениях на выходе получается именно то, что мы ожидаем там получить — и вот уже мы уверены, что весь проект делает то, что должен! Эх, хорошо бы так, но нет, в жизни так не бывает, особенно, если проект крупный.
Для начала, чем крупнее проект, тем больше будет проверок. Очень скоро, с ростом объёма кода, мы обнаружим, что никаких сил не хватит, чтобы покрыть тестами его весь, и от проверки каких-то, как мы решим в тот момент, мелочей придётся не то чтобы отказаться, но отложить их «на потом» (от этого сил и рук больше не становится, мы просто получим не одну, а минимум две очереди работы: «важное» и «сделать, когда будет время» — и долг в виде этой второй очереди будет копиться и копиться). Получаем бесконечную битву, итог которой заранее понятен: объять необъятное не получится (хотя мы, несомненно, можем мечтать, что однажды мы это и сделаем). При этом не всякий код мы можем протестировать изолированно, и баги могут вылезти в реальных условиях работы даже при полностью успешном прохождении набора тестов.
Далее, порой может оказаться, что проверки, написанные согласно имеющейся документации на проект (и на код проекта), относятся к неактуальной уже версии кода — тот неловкий момент, когда «код поправили, а доку не успели обновить». В результате конкретный тест будет «светиться зелёным», но на самом деле результату проверки доверять уже не имеет смысла. Кроме того (пусть даже мы не будем ждать обновления документации), корректно написанная и актуальная сегодня проверка может стать неактуальной завтра, когда тестируемый ею код допишут/переделают, а тест переделать забудут, и он уже не будет в состоянии ответить ни на какие разумные вопросы по поводу качества тестируемого кода.
Занудно? Ещё можно вспомнить про бюрократию, которая со временем разводится вокруг результатов более-менее объёмного по покрытию тестирования. Неуспешные тесты (особенно автоматизированные) ведут к созданию тикетов, которые, по-хорошему, тоже нужно исследовать — хотя не всегда понятно, есть ли в этом большой смысл.
Это я к тому, что даже в светлом деле уменьшения в ПО числа багов можно найти много спорных моментов, которые со временем создают некий антураж деятельности, но пользы не приносят. Такая «движуха ради движухи», создающая впечатление, что у нас всё схвачено и всё под контролем, — она не полезна ни для проекта в смысле роста качества кода, ни для его сотрудников в отношении их личного развития.
Самое важное, что нужно держать в голове — мысль, что тестирование совсем не про качество кода, а про оценивание вероятности получить с этим кодом ту или иную проблему. Опираясь на эту оценку, руководство проекта может более обоснованно принимать решения, и именно за это, вообще говоря, оно и готово платить тестировщикам за их работу. Можем, кстати, заметить, что для вероятностного определения наличия проблем в проекте исчерпывающее (полное) покрытие тестами вовсе не обязательно, оно повлияет лишь на доверие к полученной оценке.
Я отлично понимаю тестировщиков, которые работают планомерно, день за днём покрывая ещё непокрытые куски кода проверками, постоянно гоняющих автотесты, разбирающихся с «покрасневшими» проверками и заводящих тикеты по поводу каждой подозрительной «красной метки»: в иных проектах только так и можно сохранить душевное равновесие. Беда только, что по мере роста объема кода и числа проверок всё многообразие тестов прогоняется совсем не быстро, так что ощущение динамики жизни проекта как-то само собой притупляется. В итоге имеем ощущение бесконечной борьбы с ветряными мельницами.
Что же устами Майкла Болтона предлагает нам Rapid Software Testing? Для начала вместо полного покрытия тестами с этими бесконечными прогонами большого числа проверок мы переходим на быстрое тестирование очередного места, о котором сами, в силу опыта работы, знаний о проекте и некоторого профессионального чутья, догадываемся как о содержащем потенциальные проблемы в коде. Мы стараемся сделать проверку короткой (по времени), нересурсоёмкой (во всех смыслах), такой, чтобы ее результатам можно было доверять и чтобы эти результаты можно было понятным образом изложить. Возможно, при этом мы перейдем от автоматического запуска тестов к ручной проверке и сделаем число проверок меньше, но проверять мы будем в тех местах, где они действительно нужны, где, как наш опыт нам подсказывает, вероятнее всего и может приключиться баг из серьезных.
И здесь мы подходим к тонкой грани, разделяющей миры разработчиков и тестировщиков. Девиз RST в этом случае — общение, общение и еще раз общение. Идея проста: если участники команды не делятся друг с другом знаниями, как идет развитие проекта, тестировщикам существенно труднее отслеживать, что и как следует проверять, поскольку работать им остается лишь по постоянно устаревающей документации. А мы с вами знаем, как порой документация может отставать от реального положения дел, даже если очень хочется этот разрыв свести к минимуму.
RST на первый взгляд не выглядит эффективной методологией: слишком многое в ней построено на вере в живого человека, а мы, проведя половину жизни за терминалом, сегодня уже отвыкли от подобного. Но стоит подумать чуть отстранённо, и многое встает на место — достаточно, чтобы понять, почему методология живет и используется годами.
Положив руку на сердце, скажем: квадратно-гнездовой подход к тестированию, ярко заметный при создании традиционного полного покрытия тестами всего кода, хорошо работает для доказательства собственного участия в процессе, но не особо влияет на результат. Другими словами, нам нужно выбирать: мы стараемся быть «при деле», или мы стараемся помогать проекту. Причем решающим фактором выбора я бы назвал мысль о том, что в ИТ (как и в жизни) нельзя остановиться на месте; ты либо растешь, либо теряешь в знаниях — и, в результате, в перспективах дальнейшего движения. Другое дело, что покрывать тестами всё и вся можно механически, не особо включая голову, а с RST придется думать, и думать интенсивно, но результат того стоит!
Помните Чебурашку из мультика, когда он произносил речь на завершении постройки дома: «Мы строили, строили, и наконец построили»? Авторы RST представляют команду разработки идущей к одной общей цели (что, конечно, чаще правда; упомянутый суровый «ынтерпрайз» и иже с ним не берем, там свои законы джунглей), так что сидящий и смотрящий в бесконечные списки раз за разом проделываемых проверок человек вызывает недоумение, но, заодно, и надежду, что ему самому хочется больше вовлечься в процесс работы — и вместе с остальными приблизить момент выкатывания очередной версии ПО.
Не может быть «правильного» и «неправильного» тестирования. То, что подходит для банка, не подойдёт ни для разработки ПО в военной промышленности, ни для небольшой софтовой компании, так что о тех или иных подходах можно говорить только в привязке к контексту, из чего, очевидно, выводим, что невозможно выделить пресловутые «best practices» для тестирования в целом — нужно выбирать техники и подходы, согласующиеся с ситуацией и окружением. Как пример: столь популярный в среде стартапов Agile довольно покладист в вопросе дотошности тестирования, полагая, наоборот, что код в любом случае «скорее жив, чем мертв». Есть даже такая шутка: Agile изобрели, уволив из проекта всех тестировщиков. Что же, логику подхода понять можно — Agile делался разработчиками для разработчиков, не имея целью улучшение тестирования кода. Причины этого коренятся в культуре стартапов: там, где тестировщик по натуре своей будет сомневаться в работоспособности, предприниматель, вложивший в стартап деньги, скажет: «Ок, пусть так, но оно же может и заработать?!»
Что действительно нужно для успеха внедрения RST (и, согласно её воззрениям, для последующих улучшений в жизни проекта и его команды) — опыт, знания и страстное желание со стороны участников. Уточним: разговор про реальный опыт, а не про корочки и сертификаты о прохождении курсов и экзаменов. Последние никак не гарантируют, что, пройдя экзамен из 40 вопросов с готовыми ответами, не предполагающими выполнения какой-либо реальной работы по тестированию, человек сумеет включить интуицию в любой жизненной ситуации. Несомненно, посадить на тестирование можно почти любого человека, способного выполнять действия по стандартному алгоритму —, но большой пользы проекту от таких проверок не будет.
Важным для RST является особый образ мышления: неуверенность в очевидном, привычка задавать вопросы про вещи, кажущиеся окружающим понятными и неизменными, автоматическое добавление «что, если?» в начале каждой фразы, которую мы читаем или слышим, способность видеть сложность за видимой простотой, поиск альтернативных интерпретаций всего, с чем сталкиваемся. Это своеобразная внутренняя вера в то, что баги могут быть во всем; если тестировщик думает по-другому, ему будет трудно выполнять свою работу.
Майкл Болтон говорит о себе скромно: «Учу людей, как эффективнее отвечать на вопрос, действительно ли продукт, который они получили — то, что на самом деле ожидали получить». На деле его область знания (и вовлечения слушателей) гораздо шире, именно благодаря ему многие осознали весь объем (и изящество) профессии тестировщика в принципе.
В этот раз Болтон приезжает с двумя докладами: «The logic of verification» (про фазу верификации в процессе тестирования и про избегание неверных предположений и ложных выводов) и «Testers as their own worst enemies» (о том, как тестировщики могут поднять свою репутацию и имидж в компаниях, где отношение к ним разработчиков традиционно было с позиции превосходства). Приглашаем и вас посетить Heisenbug 2018 Piter, чтобы получить удовольствие от общения с этим замечательным докладчиком.
