Как я работаю: Сергей Король, Technical QA Manager в Waverley Software
[В рубрике «Как я работаю» мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]
Сергей Король — Technical QA Manager с более 10 годами опыта в IT, который развивает в себе навыки тестировщика, разработчика, аналитика и менеджера. Сергей — член программного комитета и постоянный спикер крупнейших украинских конференций по обеспечению качества QA Fest и Selenium Camp, а также прошлогодний финалист конкурса Ukrainian IT Awards в номинации Quality Assurance. Автор нескольких open-source библиотек для тестировщиков, модератор и редактор крупнейшего украинского портала автоматизаторов AT.INFO. Проводит тренинги, занимается консалтингом и обучает молодых специалистов.
Сейчас Сергей отвечает за развитие направления автоматизации, активно участвует в улучшении процессов, проведении аудитов и пресейлов, а также ведет Back-end разработку и «техлидит» один из проектов в компании Waverley Software.
О себе
«Садись рядом, смотри и запоминай. Последний раз переустанавливаю тебе Windows!» — такими были слова моего крестного, который еще в далеком 2000 году третий раз подряд приезжал и переустанавливал ОС. И это спустя месяц после того, как у меня появился ПК. На следующий день меня накрыла пытливость ума, и я сам снес Windows из-под DOS через Volkov Commander, чтобы по горячим следам усвоить новый материал.
В этот период я постоянно что-то ломал и много экспериментировал с разным софтом и системными настройками. При этом чувствовал себя как рыба в воде. В свои 13 лет я и представить не мог, что во мне подрастает будущий — до мозга костей — тестировщик.
«Диплом вуза — это лишь дорогое украшение. Самому важному в жизни мы учимся самостоятельно»
Свою первую работу на должности Manual Test Engineer я получил в 2009 году, когда учился на
«Самые правильные решения в моей жизни были приняты, когда я стоял на краю пропасти»
Хочешь быть лидом? Хочешь стать начальником QA-департамента? Эти вопросы мне начали задавать на четвертом году работы на позиции Manual TE. С одной стороны, это означало невероятные перспективы. С другой — огромную ответственность.
Я не зря упомянул пропасть — ощущения были приблизительно такие же, как при первом в жизни параглайдинге: ты подписался на какую-то авантюру, а через пять минут уже разбегаешься для прыжка с высоты 2,5 тысячи метров в неопределенность. Подобного рода прыжки сыграли ключевую роль в моем дальнейшем развитии: они придавали чувство уверенности в своих силах и наращивали навыки самоорганизации.
«Каким бы крутым специалистом ты ни был, всегда оставайся человеком»
Переход от Manual Lead TE сразу на автоматизатора высокой должности выглядел довольно авантюрным. Но на тот момент я уже привык к покорению заведомо высоких планок, и мне казалось, что знаний по написанию своих Selenium Frameworks велосипедов, а также умения настраивать CI/CD должно быть достаточно. А вот и нет...
В 2013 году я проходил собеседование в одну из небезызвестных контор на Senior-позицию и был, мягко говоря, закидан тряпками одним, может и хорошим, специалистом. Но его подход к интервью оставил довольно неприятные ощущения. Существует модный термин для случаев выражения своего профессионального превосходства путем высмеивания остальных — intellectual violence.
Из этой истории я извлек несколько уроков:
- не стоит указывать в CV того, с чем очень давно не работал;
- автоматизация — это хорошо, но без хорошего знания языка программирования это всего лишь monkey job;
- я должен сделать все возможное, чтобы никто и никогда больше не смог поставить меня в такое положение;
- и главное — нельзя вести себя как г**но, независимо от обстоятельств.
Переход в автоматизацию
«Синдром самозванца — отличный стимул для саморазвития»
Собеседование на Senior TAE я все-таки прошел в одной из контор. Это также открыло мне глаза на то, что Senior Senior’у рознь. У каждой компании свои требования и ожидания. Тем не менее, недавний провал еще долго меня преследовал и заставлял сомневаться в себе и своих решениях. Но, с другой стороны, такой пинок стал мощным мотиватором, чтобы глубоко погрузиться в изучение языков программирования, а также разобраться во внутренней специфике работы всех необходимых мне инструментов автоматизации. Со временем это дало свои плоды: и на карьерном уровне (в виде позиции лида), и на социальном (в форме постоянных выступлений на конференциях).
«Современный инженер — это высокомотивированный исследователь с хорошими софт-скиллами, который при необходимости без труда сможет переключиться на любую технологию»
В своем выступлении на Selenium Camp в феврале 2020 года я много говорил о развитии и перспективах автоматизаторов, о том, что мы не вправе называть себя QA, если абсолютно не понимаем, как устроены все процессы изнутри. Во многом именно желание сложить в голове весь пазл, а также довольно обширный опыт в автоматизации и побудили меня в определенный момент попробовать чистую разработку.
Спустя полгода мои привычки задавать много вопросов, системно мыслить, докапываться до любых мелочей, увлеченность абсолютно всем происходящем на проекте (Front-end, Back-end, инфраструктура, бизнес-анализ и тому подобное) привели к тому, что наш Solution Architect предложил мою кандидатуру на роль техлида — в дополнение к Back-end разработке.
Роль и обязанности
Если провести декомпозицию моего тайтла в Waverley — Technical QA Manager, вышло бы приблизительно следующее:
Technical — совокупность технических навыков, которые позволяют решать задачи разного уровня сложности независимо от направления. К примеру, проектная разработка, автоматизация, пресейл-, R&D- и консультативная деятельность.
QA — аббревиатура, которую я бы не использовал в привычном всем виде, так как один человек ну никак не сможет обеспечить качество всего продукта. Это ответственность всей команды. Поэтому я бы расшифровывал QA как Quality Auditor на уровне проектов всей компании. Меня подключают как на узконаправленные аудиты, так и на полномасштабные Architecture Review.
Manager — сюда можно отнести развитие экспертизы по Test Automation и на уровне компании (процессы, инструменты и best practices), и индивидуально (менторинг, тренинги, цели и тому подобное).
В процентном соотношении выходит приблизительно 80% проектных активностей (development, tech leading) к 20% задач масштаба компании (presale, processes’ improvements, competence evolution, audits).
Тем не менее, именно последние представляют наибольший интерес. Если говорить о presale, к нам в компанию довольно часто заходят весьма амбициозные стартапы, требующие R&D. Погружение в бизнес-анализ, участие в построении Initial Architecture и Proposal — это бесценный опыт.
Приходится довольно много прототипировать, изучать сильные и слабые стороны существующих решений, а также оценивать риски, прогнозировать необходимые ресурсы и сроки. И все это с учетом постоянного поиска компромисса, ведь предложение должно быть выгодным обеим сторонам.
Аудиты — тоже довольно увлекательная активность. Именно здесь, на мой взгляд, и формируется идеальная среда для раскрытия QA-потенциала. Аудиторы буквально раскладывают весь продукт, команду и процессы на атомы в поисках того, где в этом огромном и сложном организме что болит, преподнося на выходе значимые рекомендации по улучшению ситуации.
При этом я не могу сказать, что лишь только эти 20% приносят мне удовольствие от работы. Отнюдь. Мозгу необходима постоянная техническая подпитка, дабы не потерять хватку. С другой стороны, после определенной ступени в карьере сознание претерпевает определенные трансформации.
Начинаешь немного иначе смотреть на проблемы, ведь угол обзора становится гораздо шире. Отпадают вопросы из серии: «Как решить?». На их место приходят совсем другие: «Каков бюджет и дедлайн?». Многие задачи превращаются в шаблонные, а зрение — в рентгеновское. Соответственно, далеко не каждый проект может оказаться достаточно интересным, чтобы надолго увлечь и приковать внимание.
Типичный рабочий день
У меня есть несколько сверхпродуктивных фаз:
В пиковые периоды я выполняю творческую работу: разработка, код-ревью, бизнес-анализ (если нет выделенного аналитика), улучшение процессов и тому подобное. Остальное время распределяю на более высокоуровневые активности: собеседования, менторинг, нетехнические обсуждения и другое.
В нашей компании есть замечательный слоган — Responsible Freedom. По сути, можно работать откуда угодно, если вы качественно выполняете свои обязанности и нет жалоб со стороны клиента. На самом деле такой подход заставляет держать себя в узде и намекает на самоорганизацию.
Если мне нужно очень быстро решить какую-то проблему или реализовать маленькую фичу — я остаюсь дома. Если же задача комплексная, то наиболее эффективным будет приехать в офис для парного программирования и истязания доски различными диаграммами.
С точки зрения распределения и приоритизации задач на день, я всегда стараюсь держать наиболее важные вещи исключительно в голове. Как бы странно это не звучало, но попробовав однажды все выписывать на бумагу или в специализированные тулы, я начал со временем замечать, что мой мозг теряет хватку в запоминании информации. Я обнаружил жуткую зависимость от сторонних инструментов, без которых совершенно не мог вспомнить, а что же мне нужно сегодня сделать. Более того, с учетом разнообразных активностей на уровне компании, приоритеты частенько приходится менять на лету. Поэтому, я вернулся к идее хранения важной информации с коротким жизненным циклом (несколько дней) в голове. Соответственно, пул задач ежедневно обновляется. А при резкой смене приоритетов мозг, как ни странно, справляется с такой активностью моментально, без потребности в синхронизации с какими-либо тулами. Конечно, везде бывают исключения, и кое-что нотировать таки приходится, если мозг сигнализирует о переполнении буфера.
Сейчас, во время карантина, работаю только удаленно. Работа из дома меня привлекает прежде всего тишиной, которая способствует максимальной концентрации (да-да, детей пока нет). Минусы — отсутствие социальной активности, но в нынешних реалиях это частично компенсируется ежедневными созвонами с коллегами.
Обычно я работаю
Если мысль пошла, то я предпочитаю закончить начатое и не переносить задачу на потом. Опытным путем выявил, что «потом» может быть сложно быстро и эффективно войти в контекст и продолжить в том же ритме.
Но незначительную переработку можно смело компенсировать, закончив раньше в другой день. Особенно, если видишь, что новая задача довольно объемная, чтобы стартовать ее с вечера. Другой пример: представьте, что вам по какой-то причине нужно ООО посреди рабочего дня.
В классическом случае вас бы попросили в тот же день задержаться в офисе ровно на столько, сколько вы отсутствовали. Только толку от этого не будет никакого. И скорее всего, сотрудник просто просидит это время, ковыряясь в носу и просматривая Instagram.
Поэтому, на мой взгляд, всегда нужно искать баланс. В целом за свою карьеру я успел поработать в совершенно разных режимах, включая и строгую почасовку, и довольно гибкий график. Как результат, первое место в моем личном хит-параде с точки зрения комфорта и продуктивности занимает режим Responsible Freedom.
Говорить сейчас о балансе между работой и личной жизнью очень сложно. Ведь когда мы сидим в четырех стенах, когда у нас ежедневно перед глазами одни и те же картинки, а любимый человек — в соседней комнате, привычная нам реальность искажается. С психологической точки зрения нельзя давать мозгу размывать эти границы.
Мы с супругой стараемся придерживаться того же режима, что и до карантина. Даже желаем друг другу хорошего дня, расходясь по разным комнатам после завтрака. Разве что обедать стали вместе. В остальном с точки зрения рабочих процессов ничего не поменялось. А в чем-то стало даже проще: кто заканчивает работу раньше, может легко проследить за тем, чтобы партнер не засиживался.
В течение дня я стараюсь уделять внимание и физической нагрузке. В условиях карантина это тем более важно. Закрытые фитнес-центры — это не повод беречь себя любимого до лучших времен. Мы с супругой перешли на онлайн-тренировки: карематы, гантели, музыка, тренер в телевизоре — и вперед.
Конечно, тип тренировок пришлось немного поменять: теперь мы делаем акцент на функционалке и растяжке. Но
Подход к продуктивности
На мой взгляд, любые рассуждения о продуктивности очень субъективны без контекста, а также в отрыве от остальных метрик. Ведь нам не платят за количество строк (попахивающего) кода в день или за быстро (наполовину) проанализированные требования, или за (на коленке) спроектированную архитектуру для высокорискового домена.
Бездумные попытки измерения продуктивности ключевых IT-специальностей могут привести в тупик. Ведь многие вещи оцениваются в комплексе и частенько — по косвенным признакам. Особенно в мире тестирования.
К примеру, можно ввести метрику количества написанных тест-кейсов за день, месяц или год. А затем поощрять либо штрафовать людей в зависимости от каких-то усредненных показателей. Только вот продукт как был г****м, так и продолжает таковым оставаться.
Вы в недоумении побежите к тестировщикам (!) с криками: «Как так?». В результате долгого и нудного разбирательства окажется, что товарищ Петров, написавший 100 тест-кейсов за месяц, вообще не понимает, как работает продукт. А его тесты не обнаружили ни одного дефекта за последние полгода. А вот Сидоров с показателем в 20 тестов только и успевает заводить критикалы и блокеры.
«Ок, — скажете вы. — Давайте ориентироваться на количество заведенных багов и их severity!». Получаете цифры, хвалите одних, порицаете других. Только на качество продукта это почему-то никак не повлияло. «В чем же опять дело?» — спросите вы.
Да все просто, Карл! Процессы-то у вас совсем протухли! Разработчики не пишут тесты, о coding standards никто не слышал, статические анализаторы не подключены, прекоммит-хуков нет, код-ревью — для галочки, весь мусор летит прямо в master. Тестировщики ничего не успевают и совершенно не слышали об impact analysis, планирование проходит в полторы калеки под пивко и Spotify (причем без Product Owner’а и бизнес-аналитика), уровень токсичности в команде просто зашкаливает. А вы в это время все меряете продуктивность тестировщиков?!
Безусловно, метрики важны и нужны. Но реальная оценка продуктивности должна идти бок о бок с показателями эффективности. А здесь уже все становится куда запутанней.
Вот несколько примеров:
- Вася за два дня не запушил ни одной строчки кода. Ведь он продумывал то, как можно наиболее эффективно решить поставленную задачу, чтобы сэкономить команде кучу времени на реализацию и поддержку. Только вот он может вовсе и не найти оптимального решения. Означает ли это, что Вася потратил время зря? А если все же нашел, но через неделю требования переиграют? А вдруг в процессе реализации окажется неучтенным существенный нюанс — и это приведет к полному редизайну?
- Федор уделяет по часу в день на менторинг Пети. Через время Петя начинает неистово коммитить. Внимание, вопрос: это Федор так позитивно влияет на Петю или Петя просто много времени тратит на самообучение?
- Валя — тестировщица. Она пишет на 20% меньше тестов, чем остальные. Но на планировании всегда задает очень правильные вопросы, которые зачастую ставят разработчиков в тупик, а Product Owner’а заставляют взять паузу на обсуждение требований с остальными стейкхолдерами. Означает ли это, что Валя снимает часть рисков с команды и оказывает положительное влияние на развитие продукта? Или, может, в команде не хватает бизнес-аналитика, а Валя попросту занимается не пойми чем?
- Макс — автоматизатор, который покрыл 90% регрессии UI-тестами, встроил свой пайплайн в development flow и регулярно коммитит в Git. Но его тесты находят не больше пяти багов за год. Означает ли это, что такие тесты — неэффективны, а он делает бесполезную работу? Или просто у разработчиков на более низких уровнях все настолько хорошо покрыто, что большая часть багов находится еще до непосредственного запуска UI-тестов?
Таких примеров можно привести много. И вы вряд ли сможете адекватно такое измерить или автоматизировать. Несомненно, бывают исключения. Но на моей памяти, эффективность оценки продуктивности конкретного человека явно проявлялась лишь в негативных сценариях. К примеру, разработчик за неделю закоммитил лишь две строчки кода, не являясь при этом лидом или архитектором. Здесь метрика продуктивности выстрелит идеально. Но если подобного рода аномалий нет, то оценивать продуктивность в изоляции имеет смысл лишь на командном уровне. И только при возникновении тенденции к деградации следует опускаться на более низкий уровень и локализировать причины.
Ну и давайте не забывать о человеческом факторе. Ведь смышленые IT-специалисты очень легко адаптируются к метрикам и нередко начинают подгонять цифры под конкретные ситуации
Случай из реальной жизни. Допустим, в ваших критериях к качеству прописано, что количество багов за спринт не должно превышать пяти. И вот однажды тестировщики находят целых 32 дефекта! Прибегает Product Owner к менеджеру с криками: «WTF?!» Менеджер — к тестировщикам. У всех паника, все горит, срочная ретроспектива.
В следующем спринте принимается решение вычистить все баги, с чем команда успешно справляется. Только цифру 0 в графе багов уже никто не может зарепортить, так как Product Owner подумает, что с продуктом наконец все хорошо. И, следовательно, будет очень сложно ему объяснить в следующем спринте, почему опять полезли дефекты.
Тут же возникает обратная ситуация. Тестировщиков запугали, что нельзя так много багов находить (это ж отчетность, страх гильотины). И что вы думаете? Люди просто между собой договариваются не заводить «лишние» баги перед отправкой отчета, решив перенести это на грядущую неделю. Вот вам и темная сторона метрик.
Возвращаясь к изначальной постановке вопроса, мой личный подход к продуктивности и эффективности плотно завязан на специфике работы мозга и постоянном расширении информационного покрытия. Решая какие-либо проблемы, я всегда стараюсь копать немного глубже того, что требуется для их решения, применяя аналитический и системный подходы. Любую новую информацию я пробую подкреплять практическими примерами использования.
Под многие классические задачи у меня есть quick-start шаблоны, из которых я могу быстро воссоздать среду, необходимую для работы или прототипирования. Периодически пересматриваю свой старый код — это один из немногих способов самостоятельно понять и оценить, насколько ты вырос за фиксированный промежуток времени.
Я нахожу для себя кумиров, на которых можно ориентироваться с точки зрения саморазвития. А также порой устраиваю встряски для мозга, делая вещи, которых действительно боюсь, к примеру, публичные выступления.
Это и многое другое позволяет выстраивать более прочные информационные связи, создавая своеобразные маркеры в голове. Таким образом, когда всплывает какой-то вопрос или задача, мозг вначале разворачивает карту потенциальных решений и допущений, попутно генерируя ряд наводящих вопросов. А дальше дело техники: любопытство, аналитика и прочный технический бекграунд в большинстве случаев с легкостью позволят довести начатое до ума. Особенно ввиду осознания того, что мы окружены немыслимой базой знаний и инструментов, значительно упрощающих нам жизнь.
Кто я? В правильном ли направлении двигаюсь? Те ли скиллы качаю? Насколько хорошо делаю свою работу? А ту ли работу я вообще делаю? Почаще задавайте себе такие вопросы. Ведь именно они зачастую и выступают для нас в роли своеобразных эволюционных триггеров.
Инструменты и рабочее окружение
Я придерживаюсь мнения, что самый главный источник продуктивности и эффективности — неподдельная любовь к своему делу и проактивность. А вот разнообразные инструменты я бы отнес к средствам тюнинга нашего мозга.
Начну, пожалуй, с менее абстрактного. Будь то дом или работа: личное пространство, хорошее «железо», обзорность и комфорт — это must have. В условиях карантина некоторые вещи особенно важны.
Моё окружение:
- рабочий лэптоп Macbook Pro 13’, i5, 16Gb RAM;
- ПК i7, 32Gb RAM, SSD + HDD (Linux + Windows 10);
- USB-хаб на 7 слотов;
- 2×27’ монитора с настольным креплением;
- камера Logitech C922 (Full HD);
- микрофон Blue Yeti Pro + наушники закрытого типа Koss;
- роутер TP-Link Archer C1200;
- стул KULIK SYSTEM;
- на работе — надстройка для работы стоя STIY STIL.
Классические задачи разработки и автоматизации решаю за лэптопом. ПК в основном задействую для следующих задач:
- Эксперименты с различными инструментами. К примеру, как-то раз мне нужно было изучить все возможности связки Jira Server + Bitbucket Server + Jenkins. Чтобы не ждать две недели апрувов, доступов и прочей бюрократии, мне проще было развернуть все у себя.
- Поддержка пет-проектов, требующих кроссплатформенности.
- Работа с
ML-задачами (все-таки загружать, допустим, 8 Гб векторов в RAM и отъедать по 50 Гб SSD для решения точечной задачи — это overkill для лэптопа), а также распознаванием и синтезом речи в реальном времени.
Для разработки предпочитаю продукты компании JetBrains. Хорошая IDE дает серьезный прирост производительности. Когда занимался автоматизацией на Java, мне хватало одной лицензии на IntelliJ IDEA. Как только влился в разработку — сразу подтянулся JS/TS и Python стек. Ну а IoT-хобби добавило сюда еще C++. После недолгих размышлений я купил лицензию на весь Toolbox. В целом для среднестатистического инженера цена вполне приемлемая.
Из-за разброса по стекам мне частенько приходится параллельно работать в разных IDE. Потому они обычно занимают оба монитора. Если IDE нужна только одна, то второй экран всегда занят браузером: для код-ревью, анализа билдов, гугления и дебага. Экран лэптопа в основном остается для мессенджеров и дополнительных окон терминала.
К слову, терминал тоже играет немаловажную роль. Мне понравилась связка iTerm2 + Zsh. Под него есть много полезных плагинов. Ну и куда же без алиасов? Я даже своим падаванам начал добавлять в цели: «Автоматизировать часть рутинных операций при помощи алиасов/функций».
Продолжая говорить о незаменимых вещах: Docker — наш самый верный друг. И для разработки, и для автоматизации, и для экспериментов с разнообразным софтом. При работе с облаками очень спасает ngrok, если нужно быстро связать какой-нибудь сервис с локальным окружением.
Всего остального хватает и на уровне браузерных возможностей и расширений: Dev Tools, React Dev Tools, Talend API Tester, Octotree, Clear Cache, ImTranslator/Grammarly, JSONView, Jira HotLinker и JetBrains IDE Support. Ну а полезные рабочие и нерабочие линки у меня все сгруппированы в Bookmark folders.
Что касается основных средств коммуникации, то это Slack, Skype, Zoom, Hangouts и Gmail. У нас в компании официально используется G Suite, потому довольно удобно иметь все необходимое под рукой прямо в браузере. Даже с точки зрения управления почтой: Google позволяет гибко работать с несколькими профилями одновременно. У меня всегда открыты и рабочие, и личные табы. Почта всегда в поле зрения. Ну а фокусироваться на самом важном помогают фильтры и лейблы. Ввиду того, что частота приоритетных почтовых нотификаций не очень высокая, просматривать письма стараюсь ориентировочно раз в
Все рабочие чаты организованы в Slack, что тоже удобно. Туда легко встраиваются всякие боты, календарь с напоминалками, статусы сборок и тому подобное. Здесь, помимо прямых username-упоминаний и ключевых тегов, высокий приоритет всегда у проектного, CTO и presale каналов — бывают довольно срочные запросы, которые нужно обрабатывать ASAP.
Все нерабочие каналы мессенджеров, например Telegram и Viber, у меня всегда по умолчанию стоят в беззвучном режиме.
Явный фаворит видеосвязи — Zoom, на карантине он шикарно справляется с нагрузками. Более того, если вы действительно хотите сэкономить уйму времени на обсуждении рабочих вопросов, старайтесь максимально уходить от переписок в пользу аудио- и видеозвонков. Практика показывает, что 15 минут голосового общения зачастую заменяют часы бестолковой переписки, где люди могут неправильно интерпретировать поступающую информацию, прочно затягивая узел взаимного недопонимания.
Помимо этого, я частенько задействую Zoom для тренингов, видеоуроков и консультаций. Вот здесь как раз и вступают в игру ранее упомянутые микрофон, камера и наушники. Чем более качественный контент необходим, тем больше придется уделить внимания «железу».
Если вы часто выступаете на публике, рекомендую посмотреть на ScreenBrush — это десктопное приложение, которое позволяет рисовать или писать поверх всех окон. Очень эффектно получается подчеркивать свои мысли, акцентируя внимание на важном.
Возвращаясь к вещам абстрактным, хотелось бы добавить следующее: если вы действительно кайфуете от того, чем занимаетесь, то хороший инструментарий только усилит ваши позиции, помогая мозгу быстро и эффективно материализовывать задуманное. Поэтому экономить на своей продуктивности не стоит.
Книги и самообразование
К чтению я отношусь весьма своеобразно. В школе совсем не любил читать — наверное, из-за навязанного и порой очень депрессивного материала. Сейчас же я читаю только то, что мне действительно нужно и интересно в данный момент времени. Причина очень проста. Мы живем в эпоху безграничных информационных потоков, которые породили массу соблазнов и искушений.
Ежедневно в различных соцсетях, чатах и на форумах мимо наших глаз пролетают сотни шальных ссылок на всякие статьи, видео и курсы. Они, может, интересные, но если вам сейчас это не нужно, то не стоит даже открывать их и тратить свое время. Вы лишь «зашумите» разум ненужной информацией.
Помимо этого, у технической литературы есть одна большая проблема: пока та или иная книга проходит этап ревью и публикации, информация в ней попросту устаревает. Ну и не стоит забывать, что матерые разработчики и тестировщики учились на очень древней (по нынешним меркам) литературе.
Простой пример. Допустим, ко мне приходит начинающий автоматизатор и спрашивает, что можно почитать по Java. Но я понимаю, что не могу ему посоветовать «Thinking in Java» 2006 года, по которой я учился азам. Или «Java 8 in Action» — ведь недавно был релиз
Сейчас же начал читать «Leading Quality» by Ronald Cummings-John and Owais Peer. А из недавнего нетехнического выделил бы следующее:
Так или иначе, мы всю жизнь чему-то учимся. У меня уходит на самообразование примерно 2+ часа в день. Но это может выражаться в совершенно разных формах. По характеру восприятия информации я визуал, практик и исследователь. Зачастую мне нужно вначале все внимательно «пощупать» и только потом приступать к матчасти. Сухая теория вообще не заходит на первых порах — наверное, не хватает обратной связи. Но опять-таки все зависит от контекста, целей и предполагаемой продолжительности обучения.
К примеру, если компании понадобились сертифицированные специалисты в Google Cloud и мне это тоже интересно, я буду распределять время ежедневными небольшими порциями и чередовать теорию и практику, так как общий объем материала огромен, а на выходе предполагается экзамен.
Если же я просто хочу разобраться в новом фреймворке или библиотеке, то прежде чем читать API reference, я попытаюсь его запустить по Quick Start Guide и посмотреть, как это работает.
Но тут есть обратная сторона: если нужно исследовать несколько инструментов или сервисов, то одного лишь «Hello, World» запуска недостаточно. Придется нырять гораздо глубже: изучать возможности API, пробовать писать micro-POC и тому подобное.
Подтягивать теоретическую базу по книжкам лучше в связке с реальными практическими задачами. У меня обычно для таких целей есть несколько пет-проектов, с которыми я экспериментирую в отдельных ветках
Если мозгу хочется чего-то свежего и интересного, то переключаюсь на IoT-хобби. Там и в «железках» можно покопаться, и покодить на других языках программирования.
Во всем остальном срабатывает эффект настроения. Если мне хочется отдохнуть и что-то посмотреть, то включаю условный Netflix c сериалами на английском. Для прокачки софт-скиллов и всяких философствований, пожалуй, нужен особенный настрой. В будни такое редко случается, а вот на выходных заходит неплохо.
Ну и, пожалуй, самое главное — менторинг, консультации и публичные выступления. Подобного рода активности позволяют постоянно держать себя в тонусе, на стабильно высоком уровне.
Ретроспектива и планы на будущее
Долгосрочные планы сейчас строить нецелесообразно: наше сознание уже давно не в состоянии удерживать темп развития технологий. Человечество находится на пороге революционных прорывов, которые могут существенно поменять все в нашем мире.
Соответственно, моя основная цель сейчас — заложить необходимый фундамент и гибкость, которая позволит в будущем быстро адаптироваться к совершенно любой, даже самой агрессивной среде существования. В краткосрочной перспективе я все так же позитивно настроен нести просвещение в массы, а также помогать своей компании наращивать обороты и укреплять позиции на рынке.
Что касается молодых специалистов, которые начинают свой путь в качестве тестировщиков, — хотелось бы дать один совет. В условиях нынешней неопределенности очень важен прочный технический бекграунд. Не зацикливайтесь на конкретных технологиях — они не вечны.
Со временем вы поймете, что сбалансированное сочетание фундаментальных технических знаний и софт-скиллов позволят вам достаточно быстро впитывать материал любой сложности и переключаться между совершенно разными задачами.
