Смысл тестирования — в процессе, а не в оставшихся артефактах. Майкл Болтон и Rapid Software Testing

    В среде ИТ есть свои легенды, чьи имена знает сегодня чуть ли не каждый и чьи (что важнее) достижения в профессии показали другим новый путь к развитию. Одной из таких фигур для мира тестирования ПО был и остается Майкл Болтон, которого мы ждем на ближайшем Heisenbug 2018 Piter. В этой статье мы поговорим о Rapid Software Testing, о Майкле и его докладах.




    Имея за плечами 20-летний опыт тестирования, разработки, управления и написания программного обеспечения, Майкл не просто не устает учить других, как делать тестирование наиболее эффективно, но и разрабатывает новые подходы к, казалось бы, привычному искусству тестирования ПО. Он налетал более миллиона миль на самолете, проведя сотни и сотни консультаций, лекций, учебных- и мастер-классов, и всё еще полон сил наставлять специалистов по всему миру на путь истинный — проводить тестирование быстро и эффективно.


    Майкл, вместе со своим другом и коллегой Джеймсом Бахом, является соавтором отличной методологии и набора воззрений, который они называют Rapid Software Testing и о которой я решил сегодня рассказать. Rapid — это не про то, как побыстрее прогнать набор тестов, нет. Совсем наоборот, разговор о том, чтобы убрать из работы тестировщика рутину и ощущение бесконечного потока новых багов.


    Авторы RST описывают его примерно так: это набор подходов и навыков, заточенный на то, чтобы делать тестирование быстрее, дешевле и с отличными результатом. Это методология, учитывающая, как люди учатся и самоорганизовываются под давлением обстоятельств. RST исходит из интересных посылок:


    1. Процесс создания программного продукта — это отношения между людьми, как эмоциональные, так и рациональные.
    2. Каждый проект находится в условиях неопределенности и давления фактора времени.
    3. Несмотря на наши лучшие ожидания и намерения по отношению к проекту, некоторая степень неопытности, небрежности и некомпетентности является нормальной.
    4. Тест — это деятельность; смысл его в процессе, а не в артефактах.
    5. Цель тестирования — выявить статус производимого продукта и оценить, что может угрожать его полезности, так, чтобы наши клиенты могли принимать обоснованные решения по поводу него.
    6. Мы обязуемся проводить надежное и экономически эффективное тестирование, и мы будем информировать наших клиентов о чем-либо, что угрожает этому обязательству.
    7. Мы не станем сознательно или по небрежности вводить в заблуждение наших клиентов и коллег.
    8. Тестеры несут ответственность за качество своей работы, хотя они не могут контролировать качество продукта.

    Мысли интересные, но еще интереснее познакомиться с подводящими к ним аргументами. Они просты, но порой заставляют по-новому взглянуть на привычное, в частности, на само понимание, в чём цель нашей работы.


    Зачем в принципе проводить тестирование ПО? Как ни хочется сказать, что мы делаем его ради уменьшения числа ошибок в каждом очередном релизе нашей программы, правильный ответ звучит иначе: при помощи тестирования руководство проекта получает оценку рисков того, что разрабатываемое ПО поведёт себя не так, как ожидается. В итоге тестированием мы боремся не с тем, чтобы ошибок в программе не было вовсе, а оцениваем, насколько и нам, и пользователям будет хуже, если мы выпустим продукт с текущим числом недоработок и багов.


    Многие воспринимают тестирование ПО просто: к каждой функции нашего кода пишется небольшая проверка, дающая возможность убедиться, что при каких-то определённых входящих значениях на выходе получается именно то, что мы ожидаем там получить — и вот уже мы уверены, что весь проект делает то, что должен! Эх, хорошо бы так, но нет, в жизни так не бывает, особенно, если проект крупный.


    Для начала, чем крупнее проект, тем больше будет проверок. Очень скоро, с ростом объёма кода, мы обнаружим, что никаких сил не хватит, чтобы покрыть тестами его весь, и от проверки каких-то, как мы решим в тот момент, мелочей придётся не то чтобы отказаться, но отложить их «на потом» (от этого сил и рук больше не становится, мы просто получим не одну, а минимум две очереди работы: «важное» и «сделать, когда будет время» — и долг в виде этой второй очереди будет копиться и копиться). Получаем бесконечную битву, итог которой заранее понятен: объять необъятное не получится (хотя мы, несомненно, можем мечтать, что однажды мы это и сделаем). При этом не всякий код мы можем протестировать изолированно, и баги могут вылезти в реальных условиях работы даже при полностью успешном прохождении набора тестов.


    Далее, порой может оказаться, что проверки, написанные согласно имеющейся документации на проект (и на код проекта), относятся к неактуальной уже версии кода — тот неловкий момент, когда «код поправили, а доку не успели обновить». В результате конкретный тест будет «светиться зелёным», но на самом деле результату проверки доверять уже не имеет смысла. Кроме того (пусть даже мы не будем ждать обновления документации), корректно написанная и актуальная сегодня проверка может стать неактуальной завтра, когда тестируемый ею код допишут/переделают, а тест переделать забудут, и он уже не будет в состоянии ответить ни на какие разумные вопросы по поводу качества тестируемого кода.


    Занудно? Ещё можно вспомнить про бюрократию, которая со временем разводится вокруг результатов более-менее объёмного по покрытию тестирования. Неуспешные тесты (особенно автоматизированные) ведут к созданию тикетов, которые, по-хорошему, тоже нужно исследовать — хотя не всегда понятно, есть ли в этом большой смысл.


    Это я к тому, что даже в светлом деле уменьшения в ПО числа багов можно найти много спорных моментов, которые со временем создают некий антураж деятельности, но пользы не приносят. Такая «движуха ради движухи», создающая впечатление, что у нас всё схвачено и всё под контролем, — она не полезна ни для проекта в смысле роста качества кода, ни для его сотрудников в отношении их личного развития.


    Самое важное, что нужно держать в голове — мысль, что тестирование совсем не про качество кода, а про оценивание вероятности получить с этим кодом ту или иную проблему. Опираясь на эту оценку, руководство проекта может более обоснованно принимать решения, и именно за это, вообще говоря, оно и готово платить тестировщикам за их работу. Можем, кстати, заметить, что для вероятностного определения наличия проблем в проекте исчерпывающее (полное) покрытие тестами вовсе не обязательно, оно повлияет лишь на доверие к полученной оценке.


    Я отлично понимаю тестировщиков, которые работают планомерно, день за днём покрывая ещё непокрытые куски кода проверками, постоянно гоняющих автотесты, разбирающихся с «покрасневшими» проверками и заводящих тикеты по поводу каждой подозрительной «красной метки»: в иных проектах только так и можно сохранить душевное равновесие. Беда только, что по мере роста объема кода и числа проверок всё многообразие тестов прогоняется совсем не быстро, так что ощущение динамики жизни проекта как-то само собой притупляется. В итоге имеем ощущение бесконечной борьбы с ветряными мельницами.


    Что же устами Майкла Болтона предлагает нам 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, чтобы получить удовольствие от общения с этим замечательным докладчиком.

    • +19
    • 7,5k
    • 7
    JUG.ru Group 503,90
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Комментарии 7
      +3
      Я так понял, что общий смысл этой статьи это знакомство читателя с неким гуру тестов Майклом который приедет на некие доклады. Другой практической информации наподобие «если у вас проект А то вы делаете Б» увы не нашел. Думаю Майкл тоже не сможет дать ответа на подобные вопросы. Все таки ездить с докладами 20 лет и не работать на практике, накладывает свой отпечаток.
        +2

        Да, цель статьи — познакомить с Майклом и RST, если кто-то его еще не знает.


        У них есть своя консалтерская контора, которая ведет тренинги по тестированию. Так что практического опыта ответов на вопрос «если у вас проект А то вы делаете Б» у него предостаточно.


        Другое дело, что Болтон — это скорей не про простые шаги «делай А, делай Б», а про то, как думать головой.


        (По этому поводу мне почему-то вспоминается доклад другого товарища с Гейзенбага-2016 — No Such Thing as Manual Testing — он доступен прямо сейчас на ютубе).

          0

          Вы можете достаточно просто узнать есть ли у Майкла Болтона ответы на такие вопросы. Достаточно зайти в слак комьюнити: https://testersio.slack.com и спросить. Отвечает он там весьма охотно и появляется регулярно.

          0

          Как тестировать-то? Все эти посылки и размышлизмы на хлеб не намажешь. Предположим, что я со всем идеологически согласен, как мне теперь выбирать наиболее важные куски функционала для тестирования?

            0

            Если касаться конкретно Болтона и конференции — то посмотреть описания докладов (раз, два) и предположить, отвечают ли они на твой вопрос. Еще Болтона можно встретить в дискуссионной зоне и задать вопросы — он консультант, и на вопросы должен отвечать очень хорошо.


            Если вообще, то как мы знаем, существует несколько "школ" тестирования. Context-Driven школа (насколько я это понял) говорит, что результаты тестирования — это отображение мгновенного состояния проекта по самым важным для этого момента времени метрикам. Вот тут есть какая-то статья про это. Соответственно, мы приходим к понятию контекста, являющегося функцией от времени, и общего решения "как мне теперь выбирать" не существует. Нужно каждый раз думать головой и решать изобретательские задачи. Компьютер не умеет решать изобретательские задачи — умеет только человек, поэтому нам так нужны тестировщики. Некоторые интересные стратегии можно подсмотреть в докладах, что-то можно понять по какому-нибудь ТРИЗу, но это всегда будут очень "высокоуровневые" идеи, а не скрипты "делай раз, делай два".

            0
            Зачем в принципе проводить тестирование ПО? Как ни хочется сказать, что мы делаем его ради уменьшения числа ошибок в каждом очередном релизе нашей программы, правильный ответ звучит иначе: при помощи тестирования руководство проекта получает оценку рисков того, что разрабатываемое ПО поведёт себя не так, как ожидается.

            А почему автор выдает правильные ответы за других людей? Может, он сам и тестирует для оценки рисков, но с чего он взял, что другие делают так же? Он опрос какой-то проводил, типа "зачем вы тестируете"? Какая выборка? Какие результаты опроса?

              0
              Мое первое и единственное правило критического мышления: «Как только твои мысли и суждения приняли четкие очертания и осели в виде универсальных правил, ты перестаешь критически мыслить».
              Поэтому, хоть Джеймс Бах своими лекциями и воодушевил меня пойти в тестирование, я не хочу становиться приверженцем его «школы», как в прочем и чьей-то другой.

              А самая суть в статье уже дана:
              … неуверенность в очевидном, привычка задавать вопросы про вещи, кажущиеся окружающим понятными и неизменными,… способность видеть сложность за видимой простотой, поиск альтернативных интерпретаций всего,… внутренняя вера в то, что баги могут быть во всем

              Во время тестирования нужно повторять себе «я ничего не знаю». И когда ты достигаешь этого состояния, ты начинаешь видеть вещи совсем по другому. Мозг перестает цепляться за знакомое, и твое сознание свободно перемещается по приложению.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое