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

Тем не менее, иногда происходят неприятности, - и вот сегодня случилось как раз такое недопонимание, которое и сподвигло меня написать этот пост.

Дело в том, что я принципиально не помогаю с тестовыми заданиями. Я не выполняю их за других ни частично, ни полностью, и не консультирую по тому, что сделано правильно, а что нет.

Почему так?

Во-первых, я нахожу это нечестным по отношению к тем, кто будет проверять работу человека. Так как большинство тестовых заданий дается "на дом", проверяющие не имеют возможности понять, делал ли человек задание сам или попросил кого-то более опытного помочь. Представляя себя на месте специалиста, который ищет в команду сотрудника, я не хочу быть обманутой, — ведь многие проверяют hard skills именно по ТЗ.

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

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

В заключение

Дискутировать на тему того, нужны ли вообще тестовые задания, я пока что не хочу (но могу поделиться быстрым мнением: мне кажется, они не обязательны для того, чтобы нанять классного человека, и легко могут быть заменены репозиторием с личным проектом на гитхабе). Однако моя позиция касательно помощи с ними остается твёрдой, — мне кажется, решение выполнять тестовое и результат этого выполнения — задача и ответственность того, кто претендует на ту или иную должность.

Итак, в 2020 году я:

• Провела 10 митапов, из них 4 в рамках Women in Tech и 2 — в рамках QA sisters. Последнее очень круто: мы больше, чем просто чат в телеграм, мы полноценное сообщество со своими мероприятиями и визиткой. У нас даже записи остались: раз и два!
• Кстати о визитке: сделала сайт QA sisters! Теперь нам проще привлекать новых участниц, давая ссылку прям на визитку со всей информацией.
• Преподавала курс по автоматизации тестирования в Stepik Academy, а потом мои лекции использовали в других запусках, когда я из-за смены работы перестала преподавать. По-моему, довольно клёво!
• Поступила как Иван Васильевич, то есть почти что сменила профессию. Ушла из тест-менеджмента обратно в инженерию и ни капли не пожалела: мне интересно, круто и драйвово. Поменяла место работы: теперь я в команде ВКонтакте, и я не могу представить лучшего и более заботливого работодателя, — мне до сих пор иногда хочется плакать от счастья при мыслях о том, сколько хорошего делает компания для моего комфорта.
• Выделю в отдельное достижение успешное прохождение испытательного срока и трогательный, вдохновляющий фидбек от коллег. Это приятно, важно и ценно.
• Мы сделали QA школу Women in Tech! Около 60 девушек прошли отбор на бесплатный курс, который вели волонтеры, и более половины успешно его закончили, выполнив финальный проект. Несколько человек нашли работу в процессе и после курса, — это тоже невероятно важный результат. Кстати, записи лекций можно посмотреть вот тут.
• Написала статью на Хабр про тестирование на основе моделей, а потом её опубликовали на software-testing. Бам!
• Поучаствовала в Heisenbug на онлайн-стойке от ВК, пообщалась с крутыми специалистами и классно провела время;
• Рассказала про удел тестировщика в рамках VK Tech | Lessons;
• Написала несколько статей-переводов на технические темы;
• Перешла на связку Java+Selenide+TestNG в автотестах, написала много тестов с нуля, в целом стала уверенным специалистом в автоматизации. Теперь на 2 инструментах, ура!
• Прошла курс по компьютерным сетям от Андрея Созыкина. Если вы ещё не прошли его, вы очень многое теряете! Скорее бегите на ютуб и вбивайте его имя в поиске :)
• Сделала себе сайт с портфолио. Планирую в будущем делать его менее квазимодным и учиться нормальной верстке на нем, но пока что есть, то есть. It ain't mush, but it's honest work!
• Впервые побыла гостем в вебкасте :) Рассказывала в "ПРО тест" (можно посмотреть в выпуске от 17.06.2020) про свой путь и поделилась советами начинающим специалистам, а ещё поучаствовала в обсуждении будущего тестирования.
• Подготовила и рассказала 6 лекций по тестированию для внутреннего использования. Получилось круто!
• Побывала членом жюри багатона Codenrock testing contest. Необычный опыт, который я надеюсь однажды повторить. Самой любимой частью было, конечно же, разрабатывать критерии оценки.
• Написала несколько клёвых статей в этот блог;
• Провела вебинар про фичу, надо которой работаю :)
• Получила приглашение выступать на конференции с мастер-классом и докладом, но отказалась, потому что времени на подготовку катастрофически не хватало. Отсюда вытекает ещё одно достижение: я наконец-то научилась ставить в приоритет себя, свой отдых и восстановление;
• И ещё поучаствовала в нескольких классных движах на работе.

Довольно насыщенно для года, в который я обещала себе ничего не делать, huh :D

Планы на 2021

Сначала честно хотела написать "отсутствуют", но, надо признаться честно, если нет целей, я не могу систематизировать то, что делаю, и ловлю ощущение, что безбожно стагнирую, даже если на самом деле качаюсь, — а меня это совсем не устраивает. Поэтому проще задать себе направления: спокойнее, удобнее, а главное, через год будет проще проводить личную ретроспективу.

Итак, куда я хочу двигаться в 2021:

• Продолжать качаться в плане автоматизации и работы с кодом. Хочется чуть ближе стать к инфраструктурным решениям, возможно, потрогать-поучаствовать в настройке CI/CD. Я умею с нуля писать систему автотестов для локального поднятия. Теперь хочу научиться делать красивые штуки и запускать тесты удаленно, чтобы быть совсем молодцом и швецом-жнецом.
• Вернуться к преподаванию. Я ещё не решила, это будет очередной запуск бесплатного курса, или я попробую подать заявку на какие-то курсы именно как на работу, но сделать это неистово хочется. Наверное, для меня преподавание — оптимальный формат передачи знаний и общения с людьми без ухода в руководящие позиции.

• Быть ментором. Я уже вписалась в менторскую программу от Women in tech и надеюсь дать хороший старт паре джуняш.
• Улучшить свой сайт. Я сверстала его под девизом "it ain't much, but it's honest work", но мне теперь хочется подключить туда что-нибудь прикольное, сделать его адаптивным, возможно, встроить туда плейлисты с нашими митапами из YouTube... Короче, есть, куда развиваться.
• Развивать коммьюнити QA sisters. Как минимум, повторить наши митапы! :)
• Заработать все деньги мира Увеличить свой доход. Пока я не решила, как именно (за счет преподавания, доп. активностей или инвестиций), но я совершенно точно закончу следующий год, твердо стоя на ногах в плане финансов.

А теперь — дорабатывать остаток 2020 и честно отдыхать. Чтобы набраться новых сил и честно приступить к реализации целей!

Когда я только начинала работать тестировщицей, я каждый день узнавала много нового. Привычка держать руку на пульсе индустрии осталась у меня до сих пор именно с той поры. Мне не терпелось поделиться информацией с коллегами, поэтому я начала сначала выступать на митапах, а потом организовывать.

Организовать свой первый митап было страшновато: никогда этого не делала, слишком много переменных и вообще, люди же будут смотреть, и я несу перед ними персональную ответственность. А потом всё прошло хорошо и гладко, публика оказалась благодарной. Поэтому, чтобы дальше не париться, я сделала любимое дело, чтобы закрепить успешный путь — составила по нему чек-лист.

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

Итак, о чем нужно подумать, если вы хотите организовать митап?

1. Общая тема митапа.

Про что вы хотите рассказать, что обсудить?
Не обязательно устанавливать слишком конкретные рамки (типа "Сегодня говорим про автоматизацию iOS-приложений с помощью XCUITest", хотя, в целом, в таких темах нет ничего плохого — только аудитория будет меньше); достаточно определить, что, например, сегодня мы говорим про технические средства для ускорения работы тестировщика, или про организацию процесса тестирования: планирование, метрики, тест-дизайн и т.д.

Это нужно не только для того, чтобы проще было сориентировать спикеров, но и для общего понимания потенциальной целевой аудитории. Например, если на митапе 2 доклада, один из которых рассчитан на новичков в индустрии, а другой — на очень опытных специалистов, то есть риск, что в итоге общее впечателние о событии ни у тех, ни у других не будет хорошим.

2. Формат.

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

3. Технические детали.

1. Количество докладов: сколько выступлений вы планируете включить в программу?
2. Количество участников (Zoom тоже не резиновый);
3. Тайминг: сколько всего продлится митап? Сколько времени уделяется одному докладу? Будет ли уделено время ответам на вопросы, или это останется для кулуарных бесед? Если будет, то сколько?
4. Будет ли запись? Если да, то надо подумать о средствах заранее. С онлайном всё стало в разы удобнее: можно сделать скринкаст пошаренного экрана с презентацией и рассказывать и одновременно записывать происходящее. Zoom умеет это делать автоматически.

4. Место.

Если онлайн, на какой платформе (или в каком мессенджере?). Если оффлайн — то в каком месте.
Хорошие места для онлайна: Zoom (если есть платный аккаунт — вообще кайф), Google Meet, Hangouts или Jitsi meet.
Хорошие места для оффлайна: коворкинг или библиотека, небольшой бар, конференц-зал в компании, которая согласится стать партнёром мероприятия (тут имеет смысл спросить даже на текущем месте работы: многие компании только рады поддержать своего сотрудника, если он проявляет инициативу, — проверено лично).

5. Save the date.

1. Дата и время митапа;
2. Дата и время репетиции (прогон очень желателен, но можно заменить его скринкастом с презентацией и рассказом спикера);
3. Дата брифинга с орг. командой (опционально, если кто-то помогает вам в организации). В целом, можно синхронизироваться и через мессенджеры без созвонов;
4. Даты регистрации слушателей (открытие/закрытие);
5. Контрольные точки для спикеров: дата готовности плана доклада, дата готовности презентаций, и т.п.

6. Инфоподдержка:

1. Анонсы в соц. сетях: где и что будем писать и анонсировать?
2. Ссылка для регистрации. Можно использовать Timepad. Вариант попроще — Google-формы или (экстремально) пошаренная таблица, в которую нужно вписать своё имя.
3. Могут ли дружественные сообщества помочь с распространением информации? Запостить у себя анонс, написать в чат и так далее.

7. Волонтёры.

Чем масштабнее планируется событие, тем больше вероятность, что потребуется кто-нибудь в помощь. Мне в этом плане повезло: со мной работают муж и лучшая подруга, поэтому у меня всегда есть как минимум пара людей, которые могут срочно помочь сделать что-нибудь важное.
Но если бы их не было, я бы обязательно заручилась поддержкой 1-2 человек на случай форс-мажора.

8. Действия по завершении

1. Часто по завершении митапов участники просят записи докладов, файлы презентаций и контакты спикеров, которые можно использовать для вопросов. Если есть возможность, круто после митапа обеспечить участников этой информацией, предварительно спросив разрешения у выступающих.
2. Собрать с участников фидбек. Таймпад позволяет сделать рассылку автоматически, но можно сделать и проще: отправить ссылку на Google-форму в общий чат, вывести на экран QR-код со ссылкой на опрос или опросить людей лично.
3. На основе обратной связи провести ретроспективу. Спикерам будет интересно узнать, что они могут улучшить и что прошло хорошо, а нам полезно проанализировать и запомнить, что прошло круто, а что было не так.

Как действовать: пошагово

Если подвести итог, из текста выше я бы выделила следующую последовательность действий:

1. Определиться с темой митапа;
2. Найти тех, кто может и хочет помочь в организации (это опционально, можно всё делать и в одного);
3. Определиться с пунктами из списка "О чем нужно подумать";
4. Найти потенциальных спикеров и дать им ориентир по формату, датам и контрольным точкам;
5. Найти волонтёров и спонсоров, рассказать им про событие, используя наработки с прошлых шагов (тоже опционально, может не быть ни тех, ни других);
6. Провести все встречи и репетиции, убеждаясь, что всё идёт по плану;
7. Наслаждаться процессом и результатом!
8. Не забыть выполнить завершающие активности: отправить материалы, собрать фидбек, провести ретро.

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

Мы редко задаем друг другу вопрос "Какой ты специалист" в лоб, но иногда об этом всё равно приходится рассуждать, и многие люди, максимально конструктивные по отношению к окружающим, начинают говорить про себя ужасные вещи.

Мне кажется, это происходит потому, что часто мы не умеем "экологично" оценивать себя: очень много говорят про корректное общение с другими, но факт в том, что мы сами не меньше нуждаемся в нетоксичности от себя же самих.

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

Виды профессиональной самооценки

Я не претендую на звание психолога, поэтому ниже буду делиться личными наблюдениями и мыслями. Принимать их или нет — дело каждого читателя, но я надеюсь, что этими рассуждениями помогу кому-нибудь быть к себе капельку добрее и внимательнее.

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

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

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

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

Иными словами, конструктивная профессиональная самооценка больше обращается к фактам/опыту и минимально привязана к характеристикам человека как такового, в то время как деструктивная как будто стремится закрасться и в другие сферы, — вне работы, — и повлиять на самооценку человека в целом, определяя его через профессиональную реализацию.

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

Профессиональная самооценка и работа

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

Я бы выделила примерно такие направления для сравнения, чтобы показать, как именно здоровая (или нездоровая) атмосфера вокруг способствует формированию у специалиста взгляда на себя.

Хочется подробнее отметить несколько пунктов.

1. Презумпция компетентности играет роль, даже когда речь идёт о начинающих специалистах. Я специально подчеркнула "разбирается в своей зоне ответственности": с ростом квалификации растёт глубина, ширина и сложность задач. Однако и стажёр может знать своё дело хорошо: просто его область условно меньше, а задачи проще. Но от того, что задачи простые, труд человека не становится менее ценным.
2. Поощрение успехов. На самом деле, это про фидбек, а не про тщеславие :) Эмоциональное подкрепление хорошо выполненной задачи позволяет запомнить, что делать надо именно так.
3. Про равномерное распределение ответственности можно говорить много и эмоционально, но я просто приведу пример, чтобы проиллюстрировать неравномерное деление прав и обязанностей.

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

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

А что с этим делать?

Первый шаг, как обычно, осознать, что проблема есть, если пункты из "деструктивных" колонок показались вам знакомыми.

Второй шаг — попробовать рассудить, что именно способствует текущей профессиональной самооценке. Воспитание и бэкграунд? Какие-то события? Слова важного/авторитетного человека? Коллектив? Настроения/взгляды в сообществе, в котором вы состоите? Факторов может быть очень много, главное выделить наиболее влияющие на происходящее.

Третий шаг — подумать, хотите ли вы что-то поменять. Если да — то делать это, — и тут уже у каждого свой путь: кому-то помогает общение с коллегами из других сфер или дружеская поддержка, кому-то сил для перемен придаёт психотерапия, а кто-то может поймать на ровном месте настолько сильный инсайт, что его жизнь никогда не будет прежней.

Почему стоит вообще заморачиваться с этим? Потому что жить с конструктивной самооценкой, несомненно, намного проще. Она автоматически даёт тебе план действий, карту собственных умений, на которой легко ориентироваться, и, самое главное, активирует прикольную фичу мозга: из любого рода профессиональных событий, будь то успех или ошибка, ты выносишь или радость, или опыт (или и то, и другое!).

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

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

Меня эта тема трогает не только как тестировщицу, но и как лингвистку. Я предпочитаю первую пару из прошлого абзаца. Почему? Давайте разбираться.

Язык - динамическая система, и он неразрывно связан с происходящим в обществе. Для этого даже есть отдельная область - социолингвистика.

• Почему "инженерка", а не "инженерша"?

Вообще это не то чтобы сильно принципиальный вопрос, но попробую обосновать свою позицию.

Долгое время привычные суффиксы женского рода, например, -ша-, подчеркивали не то, что женщина занимается тем или иным делом, а то, что она жена человека, который принадлежит упомянутой профессии. Типа “генеральша” - жена генерала, “директорша” - жена директора (хотя в простоязычном употреблении допускается как женщина-директор - но нормой остаётся “директрисса”).

В то время как суффикс -к- вполне нормален для славянских языков как маркер женского рода. Взглянем на парадигму словоизменения по родам в чешском языке:

В то время как для нас “авторка” звучит непривычно (хотя в 2020, хочется верить, это уже постепенно меняется), в других языках это абсолютно нормальное слово.

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

Моя позиция, разумеется, не истина в последней инстанции, но имеет право существование. Если хочется закопаться в тему поглубже, то вот неплохая статья.

Это была языковая часть, а теперь посмотрим на вопрос с социальной стороны.

• Но почему именно женский род? Ведь "инженерка" режет слух и звучит как будто бы оскорбительно! Типа "инженер" — серьёзная профессия, а "инженерка" — так, очередная мадам с цветными подмышками балуется.

Тут хочется задать встречный вопрос: а вы уверены, что дело просто в суффиксе?

Отсутствие / непривычное звучание феминитивов в русском языке, для которого грамматическая категория рода очень важна - настолько, что влияет на парадигму словоизменения (в отличие от английского, где и для него, и для неё глагол будет звучать одинаково: he told, she told, тогда как в русском: он сказал, она сказала), - не более чем исторический маркер того, что многие профессии раньше были доступны только мужчинам.

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

То же самое с женщиной-инженером — "инженерка" звучит для некоторых людей непривычно и оскорбительно потому, что суффикс и женский род, а потому что в их голове всё ещё живёт концепт, что женщина не может быть нормальным технарём (Ада Лавлейс, Грейс Хоппер и Хеди Ламарр покинули чат).

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

• Окей, я понял(а) твою точку зрения. Но что мне теперь с этим делать?

Принимать феминитивы, использовать их, бороться с внутренним неприятием этих слов, понимать, откуда ноги растут у истории всей дискуссии вокруг их употребления.

Уважать преподавательниц, учительниц, инженерок, программисток, менеджерок, директрисс, начальниц, авторок, организаторок и всех женщин, которые хотят называть свою профессию женским родом.

Ну или, как вариант, можно перейти на английский. Там всё проще, категории рода нет, всё спрягается только по лицам.

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

Итак, кому и почему вредит точка зрения «Тестирование — это способ войти в мир IT, если ты не прогаешь»?

• Новичкам.

Новичкам любого рода: и в тестировании, и тем, кто хочет программировать.

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

Тем, кто хочет стартовать в программировании, но не умеет писать код, еще «веселее». Человек идёт в тестирование — отдельную профессию, требующую навыков, умений, майндсета. Он учится быть тестировщиком, он тратит время на обучение тестированию. Неудивительно, что к концу рабочего дня у него вряд ли будут силы учить новые дисциплины: язык программирования, алгоритмы, фреймворки, паттерны проектирования ПО.

Простая истина, понимание которой приходит со временем, состоит в том, что, чтобы научиться писать код, надо... писать код. Нет другого варианта, обходного пути, волшебной пилюли.

Мы не учим латынь, чтобы заговорить по-итальянски, хотя, несомненно, знание lingua latina облегчит изучение родственного языка. Соответственно, здесь также: за счет работы в тестировании проще стартовать в разработке, потому что человек уже находится в контексте IT. Но тестирование не даст "подготовительных навыков" к программированию — это отдельная специализация!

Если, отдаваясь одной профессии, человек хочет заниматься чем-то другим и не находит сил, это демотивирует его, и сил становится ещё меньше. А еще его подстегивает то, что изначально в него заложили убеждение: из тестирования надо расти в разработку.

«Надо», но почему-то не получается? Привет, синдром самозванца и чувство неполноценности. У всех же выходит, а что со мной не так? Почему я не могу «просто взять и стать разработчиком», просто «вырасти»?

Осознание приходит позже, когда человек понимает, что переход тестирование --> разработка — это не рост, а полноценная смена деятельности. Говорить, что тестирование — это некая "пред-разработка" — это примерно как говорить, что гастроэнтеролог — это "пред-физиотерапевт".

• Командам, которые нанимают специалистов.

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

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

Командам разработки такая позиция не выгодна по тем же причинам. Существует чёткое разделение обязанностей, которе родилось не просто так. Если даже одна важная сторона жизненного цикла разработки ПО будет проседать — случится дисбаланс, порождающий проблемы.

• Сообществу в целом.

Во-первых, когда тестировщиков считают неудавшимися разработчиками, — это обидно. Я знаю кучу блестящих специалистов по тестированию, по отношению к которым такая позиция ужасно несправедлива.

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

Получаем ситуацию: позиция тестирования как первого шага в разработку (или как варианта лёгкого вхождения в IT) невыгодна ни новичкам, ни специалистам, ни командам, ни компаниям.

Кому же тогда это нужно? Получается, только организациям, получающим деньги за курсы.

Что делать? Пожалуй, как обычно: думать, анализировать информацию и не вестись на очевидный маркетинг. Рушить предубеждения и как можно больше говорить о том, что тестирование — отдельная сфера. Программировать, если хочется программировать, и тестировать, если хочется тестировать.

И главное — заниматься тем, что действительно драйвит.

TL;DR: Если хочешь сменить место работы, но боишься всех подвести, попробуй взвесить "за" и "против" ухода и честно ответь себе на вопрос, стоит ли желание побыть удобным другим твоего комфорта, твоих нервов и твоего здоровья — физического и душевного.

Я нередко слышала от людей, желающих сменить работу, что им страшно уходить, потому что они "всех подведут". Особенно часто это распространено среди тестировщиков: этому способствует и то, что мы аккумулируем знания о системе, и общая ответственность, присущая тем, кто работает в QA, и то, что иногда все ещё встречается ошибочное мнение, что работа тестировщика менее важная и ценная, чем, например, разработка.

Хочется просто обнять каждого и сказать "не бойтесь, не бывает незаменимых людей, ваше счастье и комфорт важнее всего!", но это, наверное, будет сродни "не грусти", поэтому попробую сделать мой любимый финт со страхами — рационализировать.

Я тоже там была: страшно было, когда нашла первую работу учителем и поняла, что не моё, идти к начальнице и увольняться спустя неделю; страшно было уходить с поста руководителя, потому что это повлияет на целый отдел, — да, честно говоря, любые глобальные перемены пугают, а когда они потенциально затрагивают других людей, страх усугубляется.

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

1. Не бывает незаменимых людей. Вернее, их не должно быть при качественном менеджменте. Еще ни одна компания не развалилась просто потому, что тестировщик Вася ушёл в более комфортное место. А если развалилась — дело было точно не в Васе.
2. Отсюда вытекает логичное желание повлиять на то, на что мы всё же можем повлиять, — например, на то, насколько комфортно следующий специалист будет принимать дела. Я вывела для себя формулу "документируй и фиксируй всё, что можешь".
   — Выдели наиболее важные кейсы, которые могут быть не так очевидны человеку, недавно познакомившемуся с системой.
   — Опиши процесс своей работы по шагам, не упуская деталей, — именно в них может скрываться что-то важное.
   — Собери все ссылки, явки и пароли в кучу, чтобы было легко найти нужную информацию.
   — Постарайся синхронизировать информацию и максимально передать её команде, чтобы они могли рассказать новому человеку важные вещи, не противореча тому, что писал/рассказывал ты.
3. Скорее всего, после документирования процессов появится понимание примерной картины работы, которую ты делаешь, и осознание, что твой уход не положит конец всему проекту. Кроме того, очень вероятно, что ты обнаружишь некоторую glue work, которую можно в случае необходимости распределить между всеми членами команды.
4. Если документирование, осознание скоупа собственной работы и убеждение не помогли, а страх остался, прислушайся к себе и задай пару вопросов:
• Ты сам боишься, или твой страх тебе внушают?
  К сожалению, иногда нам приходится сталкиваться с психологическим давлением со стороны коллег. В этом случае нужно вовремя понять, что страх и чувство вины у тебя не свои — тебе их внушили, и приложить силы для того, чтобы освободиться от них.
  Одна из тактик: задавать вопросы в ответ на обвинения.
  "Так нельзя" (а как можно?), "Без тебя тут всё сгорит" (а это только моя проблема?), "Тебя же недавно повысили" (чтобы удержать подольше или всё же потому что я хорошо работаю?), "Что скажет ..." (да какая разница), "Мы договаривались, что ты не уйдешь" (а крепостное право разве не отменили в позапрошлом веке?), "Ты всех подведешь" (а тут даже возражать не надо, эта фраза — прямая манипуляция).
• Готов ли ты оставаться на текущем месте только из-за страха?
  Наверняка решение уйти пришло не просто так, и есть очевидный дискомфорт, который и стал триггером для мыслей о смене места. Попробуй взвесить "за" и "против" ухода и честно ответь себе на вопрос, стоит ли желание побыть удобным другим твоего комфорта, твоих нервов и твоего здоровья (постоянный стресс не улучшает качество нашей жизни).

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

На этом желаю всем отличных выходных. Пусть все ваши серьезные решения будут правильными 😌

Будучи тестировщицей, я постоянно чувствую ответственность за качество продукта, который наша команда поставляет. Я стараюсь быть в курсе новых технологий, слушаю доклады, хожу на мероприятия и активничаю в сообществах. Я наизусть знаю большущую таблицу видов тестирования на сайте Святослава Куликова, могу перечислить с десяток техник тест-дизайна, — в том числе те, что уже вряд ли применимы в IT, но история упоминает их, — и не понаслышке знаю, каким обширным может быть список задач QA-инженера.

Я уверена, что я не первая и не последняя, кто может этим похвастаться. Также я точно знаю, что есть QA-инженеры, которые не запоминали столько теории, при этом показывают высококлассные результаты и успешно тестируют огромные системы.

Что же тогда делает QA-инженера особенным? Что мне нужно прокачивать, чтобы лучше находить баги?

Ответ, который сработал для меня:

внимательность.

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

Именно она помогает обнаружить проблемы там, где техники тест-дизайна почти неприменимы: на этапе ревью макетов и спеки, при тестировании вёрстки и при планировании моей работы.

Именно она помогает увидеть скрытые закономерности и подумать, ничего ли не забыли? Всё ли учли?

Для прокачки навыков автоматизатора у меня есть язык программирования и средства, которые я использую. Для прокачки навыка видеть то, что не увидел кто-то еще (и чего, я надеюсь, не увидит пользователь) — госпожа внимательность.

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

1. Игры на "найди отличие"

Я обожала их в детстве и до сих пор очень люблю. Из явных преимуществ до боли знакомое сходство с процессом тестирования вёрстки, только количество отличий изначально неизвестно, а вместо 2 картинок у тебя есть макет и фактическая реализация :D

Найти такие игры довольно просто: я, например, иногда захожу вот сюда или просто вбиваю в Google запрос "Найди 10 отличий" и иду в результаты выдачи по картинкам. Если скучно играть просто так, можно засекать время и бить свои же рекорды.

2. Судоку

Японская игра, суть которой — заполнить пустующие клетки сетки 9х9 так, чтобы в каждой строке, каждом столбце, каждой диагонали и каждом квадратике 3х3 внутри сетки было лишь по одной цифре от 1 до 9.

Поиграть можно много где:

• https://sudoku.com/ru — неплохая онлайн-версия, всё простенько и понятно.
• Приложения для телефона — достаточно забить "судоку" в поиск в сторе на вашем телефоне.
• Бумажный вариант: он точно не разрядится :D Но из трудностей — нельзя включить режим подсказок, — хотя он, наверное, только мешает, если речь про тренировку мозгов.

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

3. Шахматы

Хоть я и не фанатка шахмат, не могу не отметить, что они тоже очень хороши для прокачки мозгов. Опять же, здесь и видение деталей, пропуск которых может быть критичным для ситуации на поле, и умение думать наперёд, и логика.

Источник могу порекомендовать один на все платформы (веб и мобилки): https://lichess.org/. Ну и, согласитесь, есть какая-то особая магия в игре на доске, по-старинке.

4. Настольные игры типа "Доббль"

Этот вариант может показаться немного детским, но именно в "Доббле" я получила огромное удовольствие от необходимости найти небольшой конкретный предмет среди множества картинок. Бонус: в "Доббль" прикольно играть в состоянии легкого подпития :D

5. Вычитывание текстов

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

Я обычно рекомендую первые 2 пункта (помимо книг и курсов) тем, кто спрашивает, как подготовиться к работе тестировщика, если ты джуниор-специалист. Надеюсь, этот список окажется полезен и моим более опытным читателям :)

Наверное, похожая история всем так или иначе знакома.

Вот я молодая специалистка, у меня горят глаза. Я уже научилась чему-то, начала работать, узнаю много нового, параллельно не забывая учиться. У меня много сил, мотивации и энергии, и я достаточно дисциплинированна, чтобы каждый вечер по часу учить Java и писать свои первые автотесты. А еще я постоянно хожу на митапы, читаю книги и верещу от радости, участвуя в первой в моей жизни конференции.

Вот я миддл с 1-2 годами опыта за плечами. У меня было несколько повышений, я продолжаю расти. Я учусь уже не только тестированию, но и вещам из смежных областей: программирование, аналитика, планирование и менеджмент. Мне рисуют большое будущее и часто хвалят, а коллеги и друзья удивляются, как я нахожу время на всё-всё-всё. Я и сама удивлена и думаю, что мне просто повезло быть достаточно энергичной, чтобы находить время на все занятия, и чтобы при этом они приносили мне удовольствие. Митапы я уже не столько посещаю, сколько организую, а на конференции гоняю в роли спикера.

Спустя полгода-год в таком режиме время я понимаю, что сил становится как будто бы меньше. Но я закоммитилась уже в миллион и один проект, поэтому нужно все делать, как обещала. Работа, образование, организаторская деятельность, участие в конференциях и менторство сплетаются в один большой цветной мелькающий клубок, который я качу уже чисто по инерции. На вопросы "как ты всё успеваешь?" окружающих отшучиваюсь, что ничего не успеваю. Жизнь внезапно кажется слишком быстрой, и я как будто не успеваю за ней. Я все еще учусь и пытаюсь подтягивать свой уровень, но делаю это без прежнего огонька, а скорее из страха остаться "за бортом" последних технологий и потерять свою ценность как специалистка.

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

Мне приходится остановиться и задуматься.

Внезапно я понимаю, что у меня больше нет этой "кучи времени" и множества сил. У меня есть часы, в которые я должна хорошо потрудиться, и за их рамками я вряд ли смогу делать что-то, кроме как лежать и в лучшем случае читать художку, в худшем — смотреть пупы на Youtube.

Я уже не боюсь, что потеряю свои знания — мне просто всё равно. Кажется, что я потрачена, никому не нужна, и что все справляются лучше меня.

Я понимаю, что мои привычные 124 часа в сутках превратились в обычные 8.

И тут мой мозг выдал мне лучший совет:

ОСТАВЬ СЕБЯ В ПОКОЕ!

— То есть как это, оставить?.. — недоуменно возразила я сама себе.

— Вот так. Берешь и отдыхаешь, когда надо отдыхать. Работаешь, когда требуется работать: не по-стахановски, а просто качественно, ты ведь это умеешь. Не запихиваешь в голову еще миллион и один курс, а медленно и вдумчиво слушаешь только то, что тебе действительно нужно по работе вот прямо сейчас, — парировал мозг.

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

Что делать, если ты твердо решил(а) отвалить от себя и дать уставшему за годы обучения и активности мозгу восстановить ресурсы?

1. Отдыхать после работы. Даже если отдых — это тупить в смартфон или спать.
2. Не обманывать себя, что проходить курсы — это отдых. Ничего подобного, это та же интеллектуальная деятельность! И после нее нужно дать себе время восстановиться. Если надо срочно что-то выучить, и можно это сделать только за счет отдыха — ок, но только в разовом порядке и только если потом будет возможность переключиться и хотя бы немного расслабить мозг.
3. Перестать пытаться выполнить пятилетку за три года. У меня на работе однажды состоялся уморительный диалог:
   
   — Я обработала Х задач, прости, что так мало, надеялась сделать Х+20.
   — Мало? Да ты смеешься, я планировал, что ты сегодня сделаешь раза в 3 меньше.
   
   То есть я весь день переживала из-за плана, который сама себе поставила, в то время как могла спокойно радоваться, что уже выполнила и перевыполнила то, чего от меня ждут.
4. Не винить себя. Мы все иногда устаем. Нужно сфокусироваться не на том, что мы потеряли, а на том, что приобретаем. Например, я во время отдыха офигеннейше высыпаюсь.
5. Помнить, что это не насовсем. Тут как со сломанной ногой: чем меньше будем ее шерудить, тем быстрее срастется, и мы снова начнем бегать.

Спустя некоторое время жизни в таком режиме я вдруг поймала чувство, которое давно меня покинуло — чувство клёвости. Вот это суперское ощущение, когда ты ВСЁ делаешь с удовольствием. Почему-то в таком режиме, даже если я делаю меньше, чем привыкла, результат получается качественным (ну разумеется, в него же вложена любооооовь!). И я даже вдруг подумала, что если навсегда останусь такой медленной и с небольшим буфером обмена, я всё равно найду способ делать свою работу хорошо и получать от нее удовольствие.

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

Выводов не будет. Будет пожелания всем беречь себя и небольшой инсайт: от меня не ожидают 200% производительности! Это я сама ее от себя ожидаю, требую и ругаю себя, если не получилось. Жить стало проще, когда я научилась разделять то, чего ждут от меня другие, и то, чего жду от себя я. Если перестать постоянно гнать себя, то можно остановиться, глубоко вдохнуть и просто понюхать цветочки.

Но это уже совсем другая история.

И я решила, а почему бы им не поделиться. Очень надеюсь, что хотя бы что-то кому-то окажется полезным :) Как минимум мне, чтобы вспомнить все прекрасные моменты, когда ко мне приходило вдохновение сделать всё это!

Записи докладов

1. SPb SQA group meetup 10/10/2018 (доклад "Инструменты в помощь веб-тестировщику" https://youtu.be/60Wfa5wmePY)
2. PyLadies SPb (лайтнинг "Communication in IT: why being a good person is a kind of occupation nowadays" https://www.youtube.com/watch?v=yvqfXM1DuAY)
3. SQAdays 25: спикер (доклад "Грабли вхождения в автоматизацию" https://sqadays.com/ru/talk/69867, записи: https://www.youtube.com/watch?v=C5JkIFgENQg&list=PL_XScYmjXxkfH-8yD6-9eRs9APLYQxwk4&index=36&t=0s и https://www.youtube.com/watch?v=hlWugas5dMk&list=PL_XScYmjXxkfH-8yD6-9eRs9APLYQxwk4&index=37&t=0s)
4. Piter CSS accessibility meetup 24/09/2019 (доклад на тему "Тестирование доступности: что это, зачем и как" https://medium.com/pitercss-meetup/pitera11y-meetup-1-3a6a2c1a49c9; запись: https://youtu.be/ZLWbpQ_MXN8?t=2332)
5. Открытая лекция в Computer Science Center: "Профессия тестировщик ПО" (https://compscicenter.ru/videos/about-qa-professionals/)
6. SQAdays 26: спикер (доклад "Codeless-инструменты для автоматизации тестирования: в поисках лучшего решения" https://sqadays.com/ru/talk/76286)
7. Women in Tech: Пути в IT: организатор, спикер (https://women-in-tech.timepad.ru/event/1241933/, видео: https://vk.com/videos-187466314?z=video-187466314_456239029%2Fclub187466314%2Fpl_-187466314_-2)

Мои статьи

1. https://habr.com/ru/comany/jugru/blog/506048/ - Статья про тестирование на основе моделей
2. https://blog.noveogroup.ru/2020/02/kratkij-likbez-po-lokatoram-v-vebe/ - Краткий ликбез по локаторам в вебе
3. https://blog.noveogroup.ru/2020/01/testovye-ploschadki-dlya-trenirovok/ - Тестовые площадки для тренировок настоящих ниндзя
4. https://blog.noveogroup.ru/2019/12/codeless-instrumenty-avtomatizatii/ - Codeless-инструменты для автоматизации тестирования: в поисках лучшего решения
5. https://t.me/bugbusterva/34 - Грабли вхождения в автоматизацию
6. https://t.me/bugbusterva/41 - Рассуждения на тему разницы тестирования и QA
7. https://teletype.in/@qa_nastasiya/TB5O1GczB - Чему бы такому научиться: мой топ курсов
8. https://blog.noveogroup.ru/2020/03/svoi-sredi-svoih-gumanitarii-v-it/ - Свой среди своих: гуманитарии в IT
9. https://blog.noveogroup.ru/2019/10/testirovanie-dostupnosti/ - Тестирование доступности: что это, зачем и как
10. https://blog.noveogroup.ru/2019/05/juzabiliti-v-rukah-qa/ - Юзабилити в руках QA, или Создай пользователя сам

Переводы

1. https://blog.noveogroup.ru/2020/04/testirovanie-bd-1 - перевод “Тестирование БД. Часть 1”
2. https://blog.noveogroup.ru/2020/04/testirovanije-bd-2/ - перевод “Тестирование БД. Часть 2”
3. https://blog.noveogroup.ru/2020/03/testy-slishkom-suhie/ - перевод “Тесты слишком «сухие»? Сделайте их «мокрыми»!”
4. https://blog.noveogroup.ru/2018/10/3-sposoba-vnesti-vklad-v-kachestvo/ - перевод “3 способа внести вклад в качество продукта, если вы ручной тестировщик среди автоматизаторов”
5. https://blog.noveogroup.ru/2018/09/luchshie-praktiki-optimizatsii-protsess/ - перевод “Лучшие практики оптимизации процесса тестирования ПО”
6. https://blog.noveogroup.ru/2018/08/optimizatsiya-testirovaniya/ - перевод “Оптимизация регрессионного тестирования в гибкой разработке”
7. https://blog.noveogroup.ru/2018/07/6-problem-v-mobilnyh/ - перевод “6 наиболее частых проблем в тестировании мобильных приложений”
8. https://blog.noveogroup.ru/2018/06/issledovatelskoe-testirovanie-agile/ - перевод “Как внедрить исследовательское тестирование в гибкий проект и не пожалеть об этом”
9. https://blog.noveogroup.ru/2018/06/5-luchshih-praktik/ - перевод “5 лучших практик автоматизации тестирования”
10. https://blog.noveogroup.ru/2018/05/kod-revju-instrument-testirovschika/ - перевод “Код-ревью как инструмент работы тестировщика”
11. https://blog.noveogroup.ru/2017/12/evoljutsiya-test-avtomatizatora/ - перевод “Эволюция тестировщика-автоматизатора”