В 2016 году коллега с удовольствием и восхищением упоминал книгу Романа Савина "Тестирование дот ком". Тогда я только начинал познавать азы тестирования, читал серьезных и обстоятельных Каннера, Фолка и Нгуена. Романа Савина листал, но читать всю книгу автора мешало предубеждение, созданное строкой "лучшие мгновения моего студенчества прошли не в аудиториях моей альма-матер, не в залах библиотек, а в пивной Коптевского рынка". Сейчас получилось преодолеть предубеждение, поверить в автора, прочитать первую из четырёх частей книги. Приятно удивлён легкости чтения и массе мыслей возникших во время чтения книги.
Счастье пользователя
Роман Савин с первых же страница книги вдохновляет и на 13 странице формулирует единственный смысл работы тестировщика - результат в форме счастья конечного пользователя... причем „счастья“ не в глобальном его значении, а той его частью, которая связана с качеством вашего продукта. Необходимо понимать, что осознание понятия "счастью пользователя" и стремление к его воплощения не должно являться уделом одного или нескольких идеалистов в компании. Не могу удержаться от цитаты двух абзацев Романа:
"Менеджмент должен сделать так, чтобы персонал понимал, что "качество" и "счастье пользователя" - это не фикция, а путь к финансовому успеху компании и соответственно лучшей жизни каждого, кто работает над проектом. Если менеджеры посмеиваются над мерами по улучшению качества и отпускают шутки о пользователях (даже в курилке!), то это тлетворно действует на всех сотрудников компании и в конечном счете негативно скажется на пользователях, а следовательно, по принципу бумеранга и на самой компании, включая "юмористов".
"Пользователи знают, уважают их или нет, уже после одного сообщения об ошибке, одного е-мейла от компании или одного звонка в службу поддержки, и если философия компании — это "тупые юзеры", то, поверьте, она проявится, на радость конкурентам, во многих вещах", 96 страница.
Функциональная баги и баги спецификаци
Важные слова с 20 и 24 страницы посвящены главному источнику ожидаемого результата для тестировщика - спецификации. Роман выражается проще Канера, Фолка и Нгуена и на 20-21 страницах отходит от терминологии "ошибка проектирования" и "ошибка кодирования" в пользу понятной и равнозначной пары "баг спецификации" и "функциональный баг".
Идея о статистике для пострелизных багов
Непонятным осталось пренебрежение Романа к количеству багов, найденных до релиза, высказанное на 30 странице книги.
Искусство создания тест-кейсов
Понятным и полезным оказалась мелочь про название очередного тест-кейса, когда на 37 странице автор предлагает изящный пример "Оплата может быть произведена картой VISA". Не мелочью оказалось напоминание 40 страницы о приоритезации тест-кейсов особенно полезной при регрессивном тестировании.
Впечатлила своей идеей 43 страница книги, где описывается заманчивая практика написания data-driven тест-кейсов, когда происходит модификация только исходных данных: не нужно вносить изменения в шаги, а в каждом новом тест-кейсе подчеркиваем меняющиеся значения данных и меняем секцию ожидаемого результата. Замечательное разделение данных и инструкций по их применению.
Сбивает с толку 47 страница про один ожидаемый результат в тест-кейсе. Благо пару страниц спустя Роман подтверждает право на существование тест-кейсов, включающих более одного ожидаемого результата, что является нормальной ситуацией при проведении тестирования сложного программного обеспечения.
На 54 странице нашел характеристики хорошего тест-кейса, когда в кейсе отсутствуют ссылки на другие тест-кейсы и есть возможность выполнить тест-кейсы в любом порядке без ущерба для тестирования. Если же ссылки есть или тест-кейс не может быть исполнен никем, кроме его автора - публично сжечь сценарий, растереть пепел в порошок и развеять по ветру.
Цикл разработки программного обеспечения
Предотвращению тихого изменения спецификаций, внесению изменений без утверждения программистом и тестировщиком, посвящена 80 страница книги, описывающая процессуальную сторону вопроса и детали процедуры внесения изменений.
Подобные процедуры и устройство процесса разработки вдохновляет к работе. Как вдохновляет и напоминание Романа Савина про обязанность тестировщиков настаивать на максимальной иллюстрации спецификаций блок-схемами, макетами и примерами (БМП). БМП как чертеж физического объекта изображают объект, только не спереди, сверху и слева, а с описанием: алгоритма что и почему видит пользователь, с иллюстрацией графической и примером чего-либо описанного.
Обязательная к повторному чтению 89 страница про девять компонентов оздоровления кода и превентирования багов до передачи кода тестировщикам. Отмечаю для себя реализацию на работе только двух из девяти указанных пунктов. Такого компонента, как счастье пользователей уже касался в начале заметки и не могу не коснуться счастья команды разработки. Роман Савин очень живописно описывает заботу о команде через реальные финансовые рычаги стимуляция написания эффективного и "чистого" кода:
Хорошая заработная плата с возможностью увеличения; билеты в "Ленком"; премии за хорошую работу; неограниченные чипсы и диет-кола; оплата абонемента в бассейн и гимнастический зал; месячные проездные; выезды для игры в пейнтбол; беспроцентный кредит на машину; помощь при первоначальном взносе на квартиру, 95 страница.
Исполнение тестирования и ремонт багов
Роман предельно ясно описывает процесс тестирования. Сначала тест приемки (smoke test, sanity test или confidence test) для проверки основной функциональности. После его прохождения заморозка кода и тестирование новых компонентов (new feature testing) исполнением тест-кейсов, написанных по спецификациям данного релиза. После тестирования новых функциональностей выполнить "старые" тест-кейсы (regression testing), чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают. Баги в отчеты, а после правки недостатков провести тест сдачи (Acceptance or Certification Test).
Релиз
На 118 странице Роман формулирует железное правило для тестировщиков и приводит пример простого разделения багов по критичности. Правило: "на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности". Примеры: некритического бага - отсутствует проверка e-mail пользователя на два "@", можно отремонтировать в следующем релизе; критического бага - невозможно совершить покупку, отремонтировать и выпустить патч-релиз как можно быстрее.
122 страница книги учит, как во время релиза уважительно и предупредительно вести себя по отношению к пользователям. Вывешивать табличку о проведении технической поддержки, вернем работу сайта примерно в такое-то время и просим извинить за временные неудобства. Подробно объяснять обычную для on-line-бизнеса ситуацию и завершить вежливым "Извините". Быть честными перед пользователем.
Большая картина цикла разработки ПО
И в заключение первой части книги Роман делится парой важных моментов. Не могу их не затронуть, поскольку больная тема:
"Первое. Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже в электронном виде) и доступны на интранете.
Второе. Такие вещи, как утверждение спека, рассмотрение тест-кейсов или инспекция кода, — это не какие-то полицейские мероприятия, призванные подрезать крылышки творческим и свободным личностям. Совершенно наоборот - это средства, позволяющие (а) улучшить качество, (б) прикрыть спину, (в) стать хорошим людям еще лучше", 127 страница.
По итогу прочтения первой части книги "Тестирование дот ком" составил себе представление о компонентах рабочего процесса в достойной компании:
11.06.2017