Пролог
В этой записи я поделюсь личными впечатлениями о становлении и взрослении процессов тестирования ПО в Российском IT. Волею судеб, это происходило, можно сказать, у меня на глазах и в процессе освоения этой профессии на пути от младшего тестировщика в небольшой компании до директора по качеству в солидной компании с многомиллионными оборотами.
Рекомендуется несколько абстрагироваться от текущего восприятия читателем тестирования в современном его статусе, чтобы понять как это происходило в прошлом, дабы с лету не отмахнуть статью с возгласами «да это и так все понятно», «это давно известные факты, зачем об этом писать» и т.д. Я не пытаюсь Вам рассказать о том, как нужно ходить, а лишь хочу рассказать о том, как когда-то научился ходить сам и как научились этому все мы.
Жили-были
Лет 8 назад, когда я только начал заниматься тестированием ПО, мне казалось, что это работа «для галочки», мол кто-то там где-то там сказал, что тестировать ПО перед раздачей пользователям- это круто, модно и вообще хорошо, потому и нужно оно. Сама индустрия, к слову сказать, была схожего мнения о данном процессе. Конечно же были софтверные гиганты и представительства западных компаний, но им культура обеспечения качества и тестирования в частности были скорее навязаны снаружи и воспринимались, как данное, нежели стали плодом самого развития индустрии в РФ.
Начинал я с геймдева, который в чем-то был похож как раз на представительства западных компаний в плане отношения к тестированию. Контроль качества был неотъемлемой частью, но чаще не из-за понимания зачем и для чего, а потому что «на Западе есть тестирование, а значит и у нас будет», тем паче, что компания, в которой я на тот момент работал, была одним из крупнейших дистрибьюторов зарубежных игр. На тот момент там все было уже «серьезно» — коллектив из 10 специалистов, парочка ведущих специалистов, руководитель отдела, т.е. своя иерархия, порядки и некоторые зачатки системных процессов в духе «билд — тестирование — баги — фиксы — релиз». Безусловно каждый «понимал» зачем мы там работали- «ищем ошибки, чтобы их не нашли пользователи», по крайней мере к этому тогда сводилась генеральная линия управляющей партии и в че-то они безусловно были правы.
Через пару лет, перед уходом в веб-разработку, я увидел в компании зачатки системности — первые чек-листы, тест-кейсы и даже некие наброски отчетности по результатам тестирования. Но все они пока что не складывались в единый пазл «Мы тестируем потому что...»
Шли годы
После перехода в крупную медийную компанию, которая занималась разработкой целого ряда весьма популярных веб-проектов я заметил не только изменения в себе и восприятии тестирования, но и в процессах, окружающих это самое тестирование. Развитие касалось, как разработки, так и менеджмента проектов, нет, о Scrum'e и прочих Agile еще было рано говорить, но уже тогда зарождались первые ответы на «Зачем нужно тестирование?», «Как его можно внедрить?» и «Как его можно улучшить?» на уровне разработки.
Это были скромные начинания на уровне «мы тестируем, чтобы наши продукты были качественнее», «тестирование помогает сделать наши продукты лучше» и тому подобные умозаключения, которые уже больше походили на осмысленные фразы ребенка, чем на лепет младенца в начале пути.
Именно тогда, 5-6 лет назад, начали появляться тест-планы, чек-листы и тест-кейсы в массовых порядках, потому как появлялось понимание, что с помощью них можно ускорить процесс тестирования, сделать его прогнозируемым, стандартизируемым и управляемым. Наконец-то появилась возможность измерять покрытие не эфемерными человеко-часами, а вполне конкретными цифрами, отображающими пусть и приближенные, но реальные данные об объемах тестирования и проценте покрытия тестами кода.
Тестировщиков-профессионалов, а не обезьянок-нажималок, становилось все больше, некоторые даже сбивались в комьюнити, набирали мемберов тематические сайты и форумы, где-то в тоже время небольшая группа энтузиастов организовала первую и ныне достаточно известную конференцию посвященную тестированию и обеспечению качества.
Тогда же впервые заговорили и об автоматизации тестирования на уровне функциональных тестов, я собственноручно делал НИОКРы по TestComplete и Selenium'у (который тогда был не грозным орудием в руках сотен и тысяч автоматизаторов по всему миру, а лишь получил версию первой публичной беты, которую использовали отчаянные энтузиасты из мира веб-разработки). Это были первые попытки вывести процессы тестирования на новый уровень, когда процесс стал обязательным и неотъемлемым куском разработки, без которого не проходил ни один релиз. Пришло понимание, что тестирование может помочь оградить разработку от неоправданной нервотрепки и рисков правки на живом (или довыгрузки патчей, если брать софт), да к тому же помогает разработчикам-перфекционистам делать свою работу лучше в принципе.
Где-то тогда же я открыл для себя фриланс, но это были скорее редкие вылазки, нежели полноценные проекты, распределенные команды и т.п. Скорее это было некой аналогии подражанием большим компаниям, как и годами ранее большие подражали Западу. Изредка, у vip-заказчиков, это было вопросом имиджа, веб-студии писали в коммерческое предложение красивую строчку о проводимом тестировании, что увеличивало стоимость работ, но придавало солидности.
Вчерашний день
За качество руками тестировщиками стали бороться и небольшие компании, но уже не в попытке избавить от страданий, мук и рисков разработку, а с целью наживы. Если быть точнее, ради экономии, наконец-то стало появляться понимание, что тестировщики в состоянии экономить компаниям огромные деньги.
Как выяснилось (о, чудо, не правда ли?) баги несут прямые убытки компании, будь то уязвимость, через которую хитроумные взломщики стянули клиентскую базу аккаунтов крупной компании, криво сверстанный макет интернет-магазина, который отпугнул целевую аудиторию или даже незначительные баги, которые в следствии своей неисправленности клали ресурсы на долгие часы, тем самым нанося косвенные имиджевые и прямые финансовые потери.
В ту пору, 3-4 года назад, как многим могло бы показаться, я достиг солидной точки карьеры, сменив пару работодателей, я вернулся в ту самую крупную медийную компанию, где уже работал ранее тестировщиком, но теперь уже на позицию ПМа популярного и большого проекта. Пошел я на ту роль, не в желании развиваться к области управления проектами, как таковой, а чтобы научиться понимать ПМов как таковых и взглянуть на процесс с высоты птичьего, как говорится, полета (не стану углубляться, в детали, это тема для отдельного поста в духе «Почему я ушел из управления проектами и „даунгрейдился“ до тестировщика»).
С одной стороны я увидел как ничтожны порой плоды тестировщиков и почему когда тестировщик истошно кричит ПМу «У меня критический баг в Opera, релизить нельзя» тот делает скептически прикрывая рукой лицо говорит «Надо!», потмоу что нагибают по срокам выше, а за сегодян еще переговоры с партнерами, обсуждение рекламной акции с клиентами, 20 000 единиц контента на модерацию, постановка 3 задач и проработк 6 фич на следующую неделю.
Лирическое отступление:
«Когда пришел рпуководить проектов, то увидел 500 тикетов в тикет-системе назначенных на себя, в том числе баги, что ставил когда-то я сам, будучи еще тестировщиком 2-3 года назад. Первым же делом я этим багам… понизил приоритет. Ведь если проект прожил с этими багами 2-3 года, значит они действительно некритичные.»
С другой стороны были и обратные случаи, когда недостаточная глубина тестирования или отсутствие автоматизации приводили к тому, что сайт терял колоссальные деньги или падал на полдня, что для проекта с аудиторией 100к хостов было неприемлемо естественно.
Были, например, и такие случаи
«С 00:00 1 марта сайт отправился в даун до 12 часов утра (до фикса разработчиком) по причине того, что в личной карточке пользователя можно было указать фейковую дату рождения 30-31 февраля, которую волей судеб некорректно валидировал обработчик вывода юзернеймов в блоке „Сегодня день рождения у:“, который четко резал список родившихся 1 марта и выводил ограниченное количество юзернеймов на главной странице, а вот перемещаемых на эту дату фейков не резал, конфликт ПО решил легко- упасть и не подняться до прихода разработчика.»
«Неожиданно выяснилось, что наша распределенная система серверов для хранения данных дала сбой и прекратились регистрации аккаунтов на букву „P“. Все бы ничего, да в день у нас было 4500 регистраций. Т.е. по усредненным данным каждый день 200 человек сталкивались с необъяснимой проблемой при регистрации, если допустить, что половина уходила (100 человек), то компания теряла ежедневно порядка 30$, так как по статистике каждый третий покупал при регистрации „премиум-аккаунт за 1$“. Потери мизерные, но из-за неполноты покрытия автотестов на этом участке данный баг был обнаружен лишь… спустя полгода, т.е. на подобной мелочи компания потеряла порядка чистыми 5000$»
Автоматизация внедрялась на полную, порой очень невдумчиво, просто потому что «модно» и вроде как прибыль должно приносить. Опять же смаивает на подходы в прошлых вехах развития при внедрении тестировании, как такового.
Заказов по фрилансу стало много больше, теперь компании понимали, что взяв в команду тестировщика они также экономят на имиджевых и финансовых потерях (одно дело баг исправить спустя полчаса после заливки на тестовый сервер кода, другое дело- фиксить его на живом у клиента, которому проект по факту уже был сдан).
То была эпоха великой экономии на спинах тестировщиков, массовый спрос на тестировщиков породил не меньшее предложение, ведь порог входа в профессию остался по-прежнему невысоким. Появились компании и тренера обучающие азам профессии, люди стали использовать тестирование, как дверь в мир разработки все чаще, а компании использовали тестировщиков, как относительно дешевый способ оптимизировать процесс разработки своих продуктов в целом.
Сегодня
Из управления проектами 2 года назад я ушел в управление качеством, где став директором по качеству фундаментально стал заниматься оптимизацией не только процессов тестирования (разбив его на фазы, создав инструкции, шаблоны, метрики и т.д.), но и процесса разработки и даже аналитики в целом. Помогая тем самым сделать стоимость ошибок еще меньше, упреждая само их появление на уровне мысли, а не написанного кода. Если раньше ошибки правились де факто на боевых площадках, то сейчас процессы обеспечения качества позволяют «залезть в голову» аналитикам и еще до написания программистами первых строчек кода исправить их в постановке задачи. А разработчиков подвигнуть писать грамотные юнит-тесты, чтобы выходящий из их рук код подвергался проверкам не только тестировщиков, но и проверкам юнит-тестов, проходил код-ревью, а также перекрестное тестирование самими разработчиками.
Выросли коммьюнити, пополнившиеся рядами новобранцев, как грибы после дождя появились аутсорсинговые проекты по тестированию, тренинговые центры, конференции тестировщиков уже стали регулярными и два раза в год собирают несколько сотен увлеченных слушателей, а на конференциях общего характера все чаще и шире представлен блок посвященный качеству.
Процессы обеспечения и контроля качества во многих компаниях занимают сейчас очень заметное место, так как не только страхуют с экономической точки зрения, позволяют избегать стрессов от некачественной разработки, но и помогают создавать конкурентоспособные продукты на рынке. Ведь ни для кого не секрет, что качество продуктов на сегодняшний день- одна из определяющих характеристик при выборе любого товара.
И именно тестировщики во многих компаниях являются той самой движущей силой, что превозносят качество на пьедестал заслуженного почета, двигая все процессы вперед, делая не только продукты, но и этот мир качественнее.
Что нас ждет завтра?
Я не прорицатель, а лишь составил небольшой исторический срез развития тестирования по пути собственного роста в профессии. Посему скажу словами из знаменитого фильма:
«Будущее не предопределено и нет другой судьбы кроме той, что творим мы.»
Автор: pifagor_mc
