Меня зовут Лилия, я уже 21 год в QA и примерно лет 15 преподаю начинающим тестировщикам, а сейчас руковожу школой тестирования. Особенно люблю преподавать тест-дизайн и базы данных, но сам процесс преподавания увлекает меня, если честно, даже больше, чем конкретная тема.

И вот я задумалась - а почему вообще люди идут в QA-преподавание? Ведь причины у всех разные, зависят они и от свойств характера, и от печального опыта, и от желания поделиться знаниями или осознать себя гуру, сидящим на вершине горы. В серии статей я планирую остановиться на 10 мотивациях (и подозреваю, что даже это еще не все) и рассмотреть каждую из них с точки зрения изначальной болевой точки, сложностей и путей их преодоления. 

Сегодня поговорим о мотивациях “Не устраивает процесс разработки” и “Некуда применить свои обширные знания”

Мотивация 1. Не устраивает процесс разработки.

Болевые точки сеньора

Не секрет, что в процессе разработки скорость и качество сочетаются редко. Иногда приходится жертвовать скоростью для обеспечения качества продукта, но обычно  - наоборот. В первом случае в пределе мы можем получить монструозный waterfall, но и вылизанный со всех сторон продукт (который, впрочем, из-за изменившегося рынка может оказаться никому не нужен). 

Во втором - “раз-раз и в продакшн”, продукт, кишащий багами, как весеннее болото головастиками, но при этом все равно используемый, потому что альтернативы нет, или “наши деды этот софт юзали - и мы будем”.

Конечно, бывают счастливые исключения, когда процесс поставлен отлично, баги фиксятся вовремя, релизы выходят в срок, а продукт остается востребованным на рынке, но такая ситуация наблюдается в основном где-то на границе мира маглов и волшебной страны, по которой скачут розовые единороги.

Как же чувствует себя айтишник, которому не повезло оседлать единорога?

В случае качественной, но медленной разработки - как в замедленной съемке. Вроде бы все заняты, требования пишутся, встречи проводятся, но согласование тестирования может занимать недели, а фикс дефектов - растягиваться на месяцы. Потому что релиз - это что-то далекое, может, год, может, два, и если ты сегодня не доделал свою задачу - не случится абсолютно ничего страшного.

В случае быстрой, но некачественной разработки - как в немом кино. Все куда-то очень быстро бегут, периодически натыкаются на соседей, где-то что-то падает, поднимается, снова падает, вся работа должна быть сделана еще вчера, ничего, что критичный баг, у нас сегодня релиз, завтра пофиксим, впрочем, нет, завтра же тоже релиз! 

Конечно, можно время от времени перемещаться между компаниями и переключаться на другой способ разработки. Но на третьей-четвертой итерации это начинает надоедать, а разработчик или QA превращается в брюзжащего убеленного сединами старца (или старушку), который рассказывает всем, что “IT уже не то” и начинает посматривать в сторону других профессий.

Почему преподавание

Но самые стойкие пытаются что-то изменить. Например, хотя бы научить молодняк, “как надо”. Как программировать так, чтобы было не стыдно за свой код. Как обеспечить нормальное тестовое покрытие и не пропускать дефекты. Как настроить инфру, чтобы тебя не будили ночью с криком “опять энв упал, вставай чини”. И как жить в IT и, с одной стороны, не растягивать работу на годы, а с другой - не бегать, как бешеный конь, пытаясь одной рукой релизить, другой патчить, одновременно успокаивать заказчика и отвечать на вопросы подчиненных, когда же им наконец повысят зарплату.

И эти люди приходят в преподавание.

И вспоминают, что есть правильные процессы. Что можно рассказать новым разработчикам, как и когда их применять, чтобы сделать хорошо. И что можно обучить столько людей, чтобы IT наконец стало адекватным, а скорость разработки повышалась не за счет ненужной беготни, а за счет правильно настроенного процесса. 

Сложности и пути их преодоления

Иметь такую мотивацию, несомненно, хорошо. Но есть одна сложность. Дело в том, что зачастую студенты, приходящие на лекции, тоже прекрасно понимают, что на самом деле происходит в IT. Даже если они никогда не работали и только получают эту профессию, по рассказам, статьям и youtube они знают, как обстоят дела, и могут спросить, например, “а вот Вы тут рассказывали нам про требования, а что делать, если их совсем нет, а тестировать все равно надо?” Первый импульс в такой ситуации - ответить “Беги!!!”, но потом ты медленно считаешь про себя до десяти и осознаешь, что твой подопечный действительно, хотя бы на первой работе, может попасть в такую компанию. И разрабатываешь план побега разработки требований для таких тестировщиков, и включаешь в следующую лекцию этот план. Следующая группа этот план получает уже с самого начала, а ты понимаешь, что все-таки внес свою лепту в упорядочивание IT-хаоса, ведь где-то благодаря тебе могут появиться хорошие требования, и софт станет чуть лучше.

Итог

Итак, мотивация первая: Недовольство текущим состоянием дел в IT.

Что делать: Пойти преподавать и рассказывать начинающим, как надо.

Какие сложности: Объяснять новичкам, как делать правильно и отвечать на вопросы “А вот у Васи на работе все делают по-другому - и ничего”.

Как преодолеть: Понимать, что делать, если процесс выстроен неправильно, и уметь это объяснить. 

Мотивация 2. Некуда применить свои обширные знания

Болевые точки сеньора

Предположим, вы senior QA и хорошо разбираетесь в какой-то теме, например, в реляционных базах данных. Словосочетание “нормальная форма Бойса-Кодда” не вызывает у вас оторопь, вы понимаете отличия разных СУБД, владеете SQL на уровне “бог”. А теперь попробуйте поучаствовать в собеседовании миддла мануальщика, да что там, даже иногда автоматизатора, и поспрашивать его про базы данных. Сколько раз вам придется наступить на горло собственной песне и не задавать вопросы, которые вертятся у вас на языке, чтобы хоть кого-то нанять в команду? Сколько мысленных фейс-палмов вам придется сделать за время собеседования?

Проблема отсутствия нормальных кадров на рынке объясняется его потребностями. Рассмотренные выше “процессы разработки” - скорость в ущерб качеству - порождают неприменимость огромного пласта знаний разработчика и тестировщика. Ок, скажете вы, кто мешает уйти из QA и пойти в Data Science, если уж так хочется применять знания о базах? Это да, но что делать, если таких глубоких знаний много, они из разных IT-областей, вы понимаете, как их можно было бы применить, но на вашем текущем месте работы это не нужно, и ваш опыт собеседований подсказывает, что в таком объеме они, возможно, вообще нигде не пригодятся? Как успокоиться после очередного собеседования кандидата, резюме которого кричит о его невероятной сеньорности, но при этом после вопроса “По какому порту и протоколу работает https” он выходит из конференции и, судя по всему, бежит до самой канадской границы, а до нормализации баз данных даже дело не доходит?

Почему преподавание

И снова можно пойти в преподавание. Правда, есть одна сложность: голая теория воспринимается как должное лишь когда профессор вещает ее, стоя на университетской кафедре (после таких объяснений применять теорию тоже не всегда получается). Преподавание будущим инженерам по тестированию на практических курсах предполагает прикладные знания, и просто рассказать про нормальную форму Бойса-Кодда уже не получится, нужно будет объяснить скептически настроенным студентам, а зачем им эти кажущиеся бесполезными сведения. Но если вы не только теоретик, но и практик, и можете сходу придумать десяток задач, для которых нужно знать нормализацию, то такой проблемы у вас не возникнет.

Сложности и пути их преодоления

Сложностей здесь две.

Во-первых, не начать рассказывать о сложных вещах, не объяснив простые, а этим часто грешат начинающие преподаватели. Например, бессмысленно рассказывать студентам о подзапросах, если они еще не умеют писать SELECT * FROM table. Поэтому нужно разрабатывать поэтапный план, как добраться до Бойса-Кодда и не забыть перед этим про три предыдущие НФ.

Во-вторых, нужно не оторваться от жизни. Как уже было сказано, лавры университетских теоретиков не к лицу преподавателю-практику, и у каждой теории должно быть практическое применение, причем именно в той специализации, для которой вы готовите лекции. Один наш преподаватель - безопасник, читающий Линукс, иногда приходит и спрашивает, а для каких задач тестеру понадобится, скажем, mkdir, иначе он может попасть впросак на лекции.

Первую сложность можно преодолеть, устраивая так называемые dry runs для “тестовых студентов” - фокус-группы, полностью совпадающей с целевой аудиторией курса, но при этом не ставящих целью устроиться на работу тестировщиками, например, позвать чью-то жену или девушку послушать вас, если, конечно, она не работает в IT :) Поверьте, это крайне интересно и может вскрыть такие вещи, о которых вы даже не думали. 

Второй челленж победить еще проще, достаточно просто помнить о том, что вы должны на каждый кусок теории придумывать практическую задачу, а если она не пришла вам в голову, то можно апеллировать к знаниям товарищей. 

Но в любом случае - преподавание станет для вас способом применить ВСЕ ваши знания. И для этого даже не нужно будет постоянно менять работу.

Итог

Итак, мотивация вторая. Далеко не все знания нужны на работе, а тут их можно применить

Сложности: Не рассказывать о сложном, не потренировав простое и помнить, что на каждую теорию должна быть практика.

Как преодолеть: в первом помогает фокус-группа, во втором - часто коллеги. 

Итак, сегодня мы рассмотрели 2 преподавательские мотивации, продолжение читайте в следующих статьях. Буду рада вопросам и рассказам о собственной мотивации, если Вы преподаватель.