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

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

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

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

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

Это методология, учитывающая, как люди учатся и самоорганизовываются под давлением обстоятельств. Авторы 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 является особый образ мышления: неуверенность в очевидном, привычка задавать вопросы про вещи, кажущиеся окружающим понятными и неизменными, автоматическое добавление «что, если?» в начале каждой фразы, которую мы читаем или слышим, способность видеть сложность за видимой простотой, поиск альтернативных интерпретаций всего, с чем сталкиваемся.

На деле его область знания (и вовлечения слушателей) гораздо шире, именно благодаря ему многие осознали весь объем (и изящество) профессии тестировщика в принципе. Майкл Болтон говорит о себе скромно: «Учу людей, как эффективнее отвечать на вопрос, действительно ли продукт, который они получили — то, что на самом деле ожидали получить».

Приглашаем и вас посетить Heisenbug 2018 Piter, чтобы получить удовольствие от общения с этим замечательным докладчиком. В этот раз Болтон приезжает с двумя докладами: «The logic of verification» (про фазу верификации в процессе тестирования и про избегание неверных предположений и ложных выводов) и «Testers as their own worst enemies» (о том, как тестировщики могут поднять свою репутацию и имидж в компаниях, где отношение к ним разработчиков традиционно было с позиции превосходства).


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Как Яндекс применил компьютерное зрение для повышения качества видеотрансляций. Технология DeepHD

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

Security Week 36: Telnet должен быть закрыт

Telnet — это очень старый протокол. Википедия сообщает, что он был разработан в 1969 году, много лет активно использовался для удаленного доступа к компьютерам и серверам, причем как под управлением Unix/Linux, так и для систем под Windows (telnet можно было ...