Профессия тестировщика зародилась не в последние годы, с появлением Python и автотестов, а гораздо раньше. «Дедушка российского тестирования» Александр Александров рассказывает об истоках тестирования в России и о становлении целой отрасли, объясняет, почему отношение к профессии было и бывает неверным, а также дает советы начинающим тестировщикам.
Именно здесь начинался путь российского тестирования (Главное здание МГУ. Фото ТАСС)
В иерархии ИТ-профессий тестировщик зачастую оказывается в самом незавидном положении. В последние годы сформировался устойчивый тезис: тестирование — первая ступень на пути к серьезной аналитике или программированию, самый легкий способ «войти в ИТ» и добиться финансового успеха. В интернете можно обнаружить множество курсов с обещаниями «научить профессии тестировщика за неделю с нуля».
Впрочем, такое снисходительное отношение к тестированию — не новость. В 1974 году на нас, первых тестировщиков, ИТ-сообщество тоже смотрело свысока.
С чего все начиналось
В 1967 году, когда я учился на третьем курсе мехмата МГУ, я посещал семинар Евгения Андреевича Жоголева — совершенно легендарного человека, соавтора первого в СССР учебника по программированию. Однажды дверь на семинаре открылась, и в аудиторию вошел 26-летний Виталий Шахнович Кауфман. Послушав его лекцию, я сразу понял, что хочу работать под его руководством.
Первая ЭВМ, на которой я учился программировать в 1963 году, будучи школьником 9-го класса. (ЭВМ «Стрела». Фото «РИА Новости»)
Встречи с Е. А. Жоголевым и В. Ш. Кауфманом (после продолжительной дружбы с ним мы договорились не употреблять отчества и в таком формате общаемся до сих пор) практически определили мою дальнейшую жизнь. Защитив диплом под руководством Виталия Кауфмана, я остался в МГУ уже в качестве сотрудника Вычислительного центра (ВЦ) и приступил к разработке компилятора первого языка программирования высокого уровня — Fortran (FORmula TRANslator).
В 1973 году по договоренности с Объединенным институтом ядерных исследований (ОИЯИ) на ВЦ МГУ возложили задачу разработки государственных стандартов Fortran. Это работа, которую в СССР на тот момент никто не делал, а во всем мире по этой теме первая книга появилась только в 1980 году.
Разрабатывать государственные стандарты было очень интересно, но при этом и невероятно сложно. Задача стандартизации — сделать так, чтобы программа, выполненная на разных машинах, выдавала один и тот же результат. Без единого стандарта прикладные программисты могли столкнуться с такой ситуацией: на одном компиляторе языка Fortran повторное возведение в степень интерпретировалось слева направо, а на другом — справа налево. В итоге написанная программа выдавала ошибочные результаты.
В это же время в ИК АН УССР Екатерина Логвиновна Ющенко и Людмила Петровна Бабенко разрабатывали стандарт языка COBOL (COmmon Business-Oriented Language). Значительная часть остального программистского сообщества СССР показывала на нас пальцем и говорила, что мы занимаемся чем-то бессмысленным.
Но мы упорно продолжали делать свое дело. Разработав ГОСТы 23056-78 и 23057-78, мы не стали останавливаться на достигнутом и перешли ко второй задаче — разработке «эталонного компилятора» — контролера программ, который бы проверял соответствие программ стандарту. Это был второй такой компилятор в мире — первый был создан в США Барбарой Райдер. Помню, как я с интересом читал ее работу в журнале Software: Practice & Experience. В чем-то она опередила нас, а в чем-то — мы ее. В частности, мы первыми реализовали контроль межмодульного взаимодействия.
Третьей нашей задачей стала разработка тестов для компиляторов. Применение этих тестов, которые занимали приличный ящик перфокарт, позволяло ответить на вопрос, полностью ли конкретный компилятор поддерживает стандарт Fortran. Потом я объездил с этим ящиком полстраны.
На такой ЭВМ я работал, будучи студентом мехмата МГУ и сотрудником ВЦ МГУ. Первая реализация конролеров программ и компиляторов была сделана именно на такой ЭВМ (ЭВМ БЭСМ-6. Фото ОИЯИ)
С этими тремя артефактами — стандарт, контролер программ и контролер компиляторов — я вышел на защиту кандидатской диссертации. Моим первым оппонентом был Михаил Романович Шура-Бура, заведующий кафедрой системного программирования ВМК МГУ. Шура-Бура был (и не только для меня) безупречным авторитетом, практически небожителем. Его точка зрения, по сути, определяла точку зрения ученого совета. Прочитав первый вариант моей работы, Шура-Бура сказал: «Второго и третьего артефакта было бы достаточно для диссертации. А первый ставит под сомнение диссертабельность всей работы». В конце концов, нам, моему научному руководителю Виталию Кауфману и мне, удалось его переубедить. Правда, за это время я переписывал диссертацию шесть или семь раз! При стандартной продолжительности защиты кандидатской диссертации в 40 с небольшим минут, моя длилась 1,5 часа — настолько активные вокруг нее разгорелись дискуссии.
Постепенно, с началом перестройки (то есть примерно к середине 80-х), к научному сообществу пришло осознание тестирования как сложной специфической инженерной дисциплины. Когда я перешел на работу в отдел информационных систем в том же Вычислительном центре МГУ, где мы занимались не разработкой компиляторов, а прикладными задачами, то и там результаты моей диссертации нашли свое применение. В какой-то момент наш отдел поддерживал одновременное функционирование 44 информационных систем для нужд МГУ. В частности, мы отвечали за бесперебойный расчет зарплат и стипендий для всех сотрудников и аспирантов университета — а это порядка 40 000 человек. Позже мы перевели всю эту работу на персональные ЭВМ.
В какой-то момент я понял, что хочу двигаться дальше. В мае 1991 года я пришел в IBS, увидев объявление на карьерном портале о вакансии технического писателя в дивизионе заказных решений. В итоге меня взяли на должность тестировщика, а позже перевели в центр программных разработок, из которого потом выросла известная ИТ-компания Luxoft. Так я начал полноценно заниматься тестированием в коммерческих проектах. На моих глазах из «непонятного» направления тестирование выросло в целую отрасль.
Каково сейчас отношение к профессии
Если сначала приходилось убеждать людей, что тестирование — это полноценная профессия, то в XXI веке мы должны убеждать топ-менеджеров, что тестирование — не та область, на которой всегда можно сэкономить без ущерба для заказчика и для конечных пользователей. Есть критически важные проекты, в которых на тестирование должно отводиться около 80% всех трудозатрат проекта. В авионике или, например, в медицине ошибка в коде буквально может стоить жизни. История знает как минимум о двух громких катастрофах самолетов Boeing, причинами которых послужили недостаточно тщательно протестированные датчики на борту.
Но это не значит, что во всех остальных сферах тестирование — бесполезная вещь. Например, на наших глазах сейчас происходит революция в области больших языковых моделей. ИТ-гиганты один за другим выпускают свои поспешные аналоги вездесущего ChatGPT. При такой жаркой конкуренции времени на полноценное тестирование толком не остается. И что мы получаем? Неправильный ответ чат-бота Bard (разработка Google) на простой вопрос о космосе обвалил акции Alphabet (холдинговой компании во главе Google) на 7%. Надеюсь, никто от этого не умер, но рыночная стоимость корпорации снизилась на $100 миллиардов.
Несмотря на громкие примеры, бизнес продолжает экономить на полноценном тестировании. А отношение заказчиков влияет, в свою очередь, на отношение к профессии технологических компаний и специалистов отдела кадров. Мы видим, что в целом в индустрии сложился устойчивый миф о легкости профессии тестировщика. Постепенно этот миф распространяется во внешний мир, и вот уже каждый первый бухгалтер уверен, что сможет переквалифицироваться в тестировщика на простых курсах, а каждый второй студент — что это «некрутая» профессия для не самых светлых умов. Кажется, что эти стереотипы множатся ежедневно.
Хуже того, в последнее время все разговоры о тестировании ведутся в основном в ключе его максимальной автоматизации. Возвращаясь к упомянутому выше ChatGPT, некоторые эксперты даже высказывают мысль о том, что в ближайшем будущем живых тестировщиков полностью заменят нейросети, которые будут самостоятельно писать и прогонять автоматизированные тесты при каждой новой итерации программы.
Проблема в том, что все тесты не напишешь, а потому исчерпывающее тестирование в принципе невозможно. Автоматизированные тесты — это, безусловно, хорошо. Но финальное слово должно оставаться за человеком. Если мы переложим всю ответственность на искусственный интеллект, не стоит потом удивляться рухнувшим акциям или рухнувшим самолетам.
Каким должно быть отношение к профессии
Посыл, который мне кажется крайне важным донести до нового поколения ИТ-специалистов: не нужно идти в тестирование как в джуниор-профессию «с легким порогом вхождения». Тестирование — это тяжелый, кропотливый труд, который требует высокой профессиональной инженерной квалификации, огромной внимательности, любопытства, дотошности и даже занудства.
При этом в тестирование стоит идти только тем, кто умеет, что называется, держать удар. Нередки случаи (к счастью, не в нашей компании, но в индустрии в целом), когда тестировщиков объявляют виновниками всех ИТ-провалов. Как писал Александр Твардовский, «города сдают солдаты, генералы их берут». За успешный проект принято хвалить разработчиков, а за любые баги — винить тестировщиков. Так что в этой профессии нужна железобетонная нервная система.
Кроме того, тестирование — это в чем-то призвание. Нужно по-настоящему хотеть быть тестировщиком, то есть любить находить в продукте какие-то проявления, которых в нем быть не должно, и выявлять отсутствие чего-то, что быть должно. Для людей с таким подходом к делу и с определенным складом характера тестирование — невероятно увлекательное дело. Я работаю в этой сфере без малого 50 лет и при этом продолжаю учиться каждый день. Тестирование — абсолютно технологичная область, которая требует большого объема знаний и навыков.
Но прежде чем изучать технические аспекты тестирования (на какую кнопку нажать, какой инструмент выбрать и т. д.), нужно сформировать понимание фундаментальных вещей в профессии на уровне ее концепции. Тестирование — это не про то, как запустить автоматизированный сценарий использования. Тестирование — это про то, как не допустить катастроф на стороне заказчика, будь то разочарование пользователей, падение акций или даже крушение целого самолета. В идеальном мире будущего именно такое понимание профессии должно быть у молодых специалистов, их наставников, работодателей и, главное, бизнес-заказчиков.
P. S. Это была вводная статья про прошлое, настоящее и будущее профессии тестировщика — что называется, с высоты своего опыта. Если тема вам интересна, следите за блогом IBS. Коллеги хотят дать мне возможность вести свою рубрику в рамках корпоративного блога. В будущих статьях я планирую разобрать реальные кейсы из нашей практики, рассказать про карьерный и профессиональный рост в тестировании или объяснить, как, на мой взгляд, должно выглядеть качественное образование тестировщика. Пишите в комментариях, что именно вам бы хотелось узнать про эту столь важную и столь недооцененную профессию.