Пролог В этом посте я поделюсь своими личными впечатлениями о становлении и развитии процессов тестирования программного обеспечения в российских ИТ.
Волею судьбы произошло это, можно сказать, на моих глазах и в процессе освоения этой профессии на пути от младшего тестировщика в небольшой компании до директора по качеству в солидной компании с многомиллионным оборотом.
Рекомендуется несколько абстрагироваться от текущего восприятия читателем тестирования в его современном статусе, чтобы понять, как это происходило в прошлом, чтобы не отмахиваться от статьи с возгласами «да, это уже все понятно, «это давно известные факты, зачем об этом писать» и т. д. Я не пытаюсь рассказать вам, как ходить, а просто хочу рассказать, как я когда-то научился ходить сам и как мы все научились ходить ходить.
Жил когда
Лет 8 назад, когда я только начинал тестировать ПО, мне казалось, что это работа «для галочки», типа кто-то где-то говорил, что тестировать ПО перед раздачей пользователям — это круто, модно и вообще хорошо, потому что и нужно..
В самой отрасли, кстати, сложилось аналогичное мнение по поводу этого процесса.
Конечно, существовали софтверные гиганты и представительства западных компаний, но культура обеспечения качества и тестирования в частности была им скорее навязана извне и воспринималась как данность, а не стала плодом самого развития промышленности Российской Федерации.
Начинал я с разработчика игр, который в чем-то был похож на представительства западных компаний по отношению к тестированию.
Контроль качества был неотъемлемой частью, но чаще всего не из-за понимания, почему и для чего, а потому, что «на Западе есть тестирование, значит, оно будет и у нас», тем более что компания, в которой я работал на том time был одним из крупнейших дистрибьюторов зарубежных игр.
На тот момент там уже все было «серьезно» - команда из 10 специалистов, пара ведущих специалистов, начальник отдела, т.е.
своя иерархия, порядки и некоторые зачатки системных процессов в духе «сборка - тестирование».
- ошибки - исправления - выпуск».
Конечно, все "поняли", зачем мы там работали - "мы ищем ошибки, чтобы пользователи их не находили", по крайней мере, к этому сводилась тогда генеральная линия правящей партии, и в чем-то они, безусловно, были верно.
Через пару лет, перед тем как заняться веб-разработкой, я увидел зачатки системной системы в компании — первые чек-листы, тест-кейсы и даже некие черновики отчетов по результатам тестирования.
Но все они пока не укладываются в единый пазл: «Тестируем, потому что.
»
Прошли годы
Перейдя в крупную медиа-компанию, занимавшуюся разработкой ряда очень популярных веб-проектов, я заметил изменения не только в себе и восприятии тестирования, но и в процессах, окружающих это самое тестирование.Разработка касалась и разработки, и управления проектами, нет, о Scrum и прочем Agile говорить еще было рано, но уже тогда появились первые ответы на вопросы «Зачем нужно тестированиеЭ», «Как это можно реализоватьЭ» и «Как это можно улучшитьЭ» на уровне разработки.
Это были скромные начинания на уровне «мы тестируем, чтобы сделать нашу продукцию лучше», «тестирование помогает сделать нашу продукцию лучше» и тому подобные выводы, которые уже больше походили на осмысленные фразы ребенка, чем на лепет младенца в начале века.
путешествие.
Именно тогда, лет 5-6 назад, стали массово появляться тест-планы, чек-листы и тест-кейсы, потому что появилось понимание, что с их помощью можно ускорить процесс тестирования, сделать его предсказуемым, стандартизируемым и управляемый.
Наконец, можно измерять покрытие не в эфемерных человеко-часах, а в вполне конкретных цифрах, отображающих пусть и приблизительные, но реальные данные об объёме тестирования и проценте покрытия кода тестами.
Профессиональных тестировщиков, а не насильников, становилось всё больше, некоторые даже образовывали сообщества, набирали участников на тематических сайтах и форумах, а где-то в это же время небольшая группа энтузиастов организовала первую и ныне достаточно известную конференцию, посвящённую для тестирования и обеспечения качества.
При этом, впервые заговорили об автоматизации тестирования на уровне функциональных тестов, я лично занимался R&D по TestComplete и Selenium (который не был грозным оружием в руках сотен и тысяч специалистов по автоматизации по всему миру).
мире на тот момент, но получила только версию первой публичной бета-версии, которой пользовались отчаянные энтузиасты из мира веб-разработки).
Это были первые попытки вывести процессы тестирования на новый уровень, когда процесс стал обязательной и неотъемлемой частью разработки, без которой не мог состояться ни один релиз.
Пришло понимание, что тестирование может помочь защитить разработку от ненужной мороки и рисков живого редактирования (или дополнительной загрузки патчей, если брать софт), а кроме того, оно помогает разработчикам-перфекционистам делать свою работу лучше в принципе.
Примерно в то же время я открыл для себя фриланс, но это были более редкие вылазки, чем полноценные проекты, распределенные команды и т. д. Скорее, это была своего рода аналогия с подражанием крупным компаниям, так же, как несколько лет назад крупные подражали Западу.
Иногда для VIP-клиентов это было вопросом имиджа; веб-студии написали в коммерческом предложении красивую строчку о проводимом тестировании, что увеличило стоимость работы, но придало ей авторитета.
Вчера
Небольшие компании тоже начали бороться за качество с помощью тестировщиков, но уже не в попытке спасти разработку от страданий, мучений и рисков, а с целью получения прибыли.Если быть точнее, то в целях экономии наконец-то начало появляться понимание того, что тестировщики способны сэкономить компаниям немало денег.
Как оказалось (о чудо, не правда ли?) баги приносят прямые убытки компании, будь то уязвимость, через которую коварные хакеры украли клиентскую базу аккаунтов крупной компании, кривая верстка интернет-магазина которые отпугнули целевую аудиторию, или даже мелкие ошибки, которые из-за отсутствия их исправления тратили ресурсы впустую в течение долгих часов, тем самым вызывая косвенный имидж и прямые финансовые потери.
В то время, 3-4 года назад, как многим могло показаться, я достиг твёрдой точки в своей карьере, сменив пару работодателей, я вернулся в ту очень крупную медиакомпанию, где до этого работал тестировщик, но теперь на должность ПМ популярного и крупного проекта.
Я взял на эту роль не желание развиваться в сфере проектного управления как такового, а чтобы научиться понимать ПМ как таковое и смотреть на процесс, как говорится, с высоты птичьего полета (не буду вдаваться в подробности).
, это тема для отдельного поста в духе «Почему я ушел из управления проектами и «понизился» до тестировщика»).
С одной стороны, я видел, насколько ничтожны порой плоды тестировщиков, и почему, когда тестировщик истошно кричит в личку «У меня критический баг в Опере, я не могу его выпустить», он, скептически прикрывая свою лицо рукой, говорит «Надо!», потому что сгибают сроки, но за сегодня еще переговоры с партнерами, обсуждение рекламной кампании с клиентами, 20 000 единиц контента на модерацию, постановка 3 задач и работа над 6 функций на следующую неделю.
Лирическое отступление: «Когда я пришел управлять проектом, я увидел в тикет-системе 500 тикетов, закрепленных за мной, включая баги, которые я сам когда-то поднимал, когда еще был тестировщиком 2-3 года назад. Первое, что я сделал, это.
понизил приоритет этих ошибок.
Ведь если проект прожил с этими багами 2-3 года, то они действительно некритичны».
С другой стороны, бывали и обратные случаи, когда недостаточная глубина тестирования или отсутствие автоматизации приводили к тому, что сайт терял огромные деньги или падал на полдня, что было недопустимо естественно для проекта с аудиторией в 100 тысяч хостов.
Например, были такие случаи «С 00:00 1 марта сайт провисал до 12 часов ночи (до исправления разработчиком) из-за того, что в личной карточке пользователя можно было указать фейковую дату рождения 30 февраля – 31, который волею судьбы был неправильно проверен процессором вывода имени пользователя в блоке «Сегодня день рождения:», что явно сокращало список родившихся 1 марта и отображало ограниченное количество имен пользователей на главную страницу, но не вырезал фейки, перенесенные на эту дату, конфликт программного обеспечения решил легко упасть и не подняться до прихода разработчика».
«Неожиданно оказалось, что наша распределенная система серверов хранения данных дала сбой и прекратилась регистрация аккаунтов на букву «П».
Все бы ничего, но у нас было 4500 регистраций в день.
Те.
по усредненным данным, каждый день 200 человек сталкивались с необъяснимой проблемой при регистрации, если предположить, что ушла половина (100 человек), то компания теряла около 30 долларов ежедневно, так как по статистике каждый третий купил «премиум-аккаунт за 1 доллар».
" Во время регистрации .
Потери незначительны, но из-за неполного покрытия автотестами в этой области данный баг был обнаружен только.
через полгода, т. е.
компания потеряла на такой мелочи около $5000 чистыми».
Автоматизация была реализована на полную катушку, порой весьма необдуманно, просто потому, что это было «модно» и якобы должно было приносить прибыль.
Опять же, это напоминает подходы, применявшиеся на прошлых этапах разработки при внедрении тестирования как такового.
Заказов на фриланс стало намного больше, теперь компании поняли, что нанимая в свою команду тестировщика, они еще и экономят на имиджевых и финансовых потерях (одно дело исправить баг через полчаса после загрузки кода на тестовый сервер, другое дело в том, чтобы исправить это вживую с клиентом, которому проект по сути уже сдан).
Это была эпоха огромной экономии за счет тестировщиков; массовый спрос на тестировщиков породил не меньшее предложение, ведь порог вхождения в профессию оставался низким.
Появились компании и тренеры, обучающие основам профессии, люди все чаще стали использовать тестирование как дверь в мир разработки, а компании использовали тестировщиков как относительно дешевый способ оптимизировать процесс разработки своих продуктов в целом.
Сегодня
Из управления проектами 2 года назад я ушел в управление качеством, где, став директором по качеству, я принципиально начал оптимизировать не только процессы тестирования (разбивка его на этапы, создание инструкций, шаблонов, метрик и т. д.), но и процесс разработки.и даже аналитики в целом.
Тем самым помогая сделать цену ошибок еще меньше, предвидя само их появление на уровне мысли, а не написанного кода.
Если раньше ошибки исправлялись де-факто на поле боя, то теперь процессы обеспечения качества позволяют «залезть в головы» аналитиков и исправить их в постановке задачи еще до того, как программисты напишут первые строчки кода.
А разработчиков следует поощрять к написанию грамотных модульных тестов, чтобы код, выходящий из их рук, подвергался проверке не только тестировщиками, но и проверкам модульных тестов, обзорам кода и перекрестному тестированию со стороны самих разработчиков.
Сообщества разрослись, пополнились рядами новичков, проекты по тестированию на аутсорсинге, учебные центры появились как грибы после дождя, конференции тестировщиков уже стали регулярными и дважды в год собирают несколько сотен восторженных слушателей, а на генеральных конференциях блок, посвященный качеству представлено все больше.
Процессы обеспечения и контроля качества во многих компаниях сейчас занимают очень видное место, поскольку они не только страхуют с экономической точки зрения, позволяют избежать стресса от некачественной разработки, но и помогают создавать конкурентоспособную продукцию на рынке.
Ведь ни для кого не секрет, что качество продукции сегодня является одной из определяющих характеристик при выборе любого товара.
И именно тестировщики во многих компаниях являются той самой движущей силой, которая возводит качество на пьедестал заслуженной чести, двигая вперед все процессы, делая не только продукцию, но и этот мир лучше.
Что нас ждет завтра?
Я не прорицатель, но составил лишь небольшой исторический снимок развития тестирования по пути собственного роста в профессии.Поэтому скажу словами из известного фильма: «Будущее не предопределено, и нет другой судьбы, кроме той, которую мы создаем».
Теги: #тестирование #история развития индустрии тестирования #опыт из первых рук #гарантия качества #тестирование ИТ-систем
-
Sua1500: Как Установить Аккумулятор
19 Oct, 24 -
Хватит Ставить Сову На Глобус
19 Oct, 24 -
Мы Закончили Игру!
19 Oct, 24 -
23-Й Подкаст Петербургской Группы Alt.net
19 Oct, 24 -
Успокойте Нервы С Помощью Perl И Gd
19 Oct, 24 -
Как Мы Сделали Робота-Футболиста
19 Oct, 24
