В среде ИТ есть свои легенды, чьи имена знает сегодня чуть ли не каждый и чьи (что важнее) достижения в профессии показали другим новый путь к развитию. Одной из таких фигур для мира тестирования ПО был и остается Майкл Болтон, которого мы ждем на ближайшем 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, чтобы получить удовольствие от общения с этим замечательным докладчиком.
Автор: Олег Чирухин
