Кодинг
February 22

Первые впечатления тестировщика после кодинга

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

Почему начал?

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

На тему нужно ли уметь кодить тестировщику, и будут ли тестировщики неумеющие кодить в будущем, круто обсудили в подкасте QAk-QAk и в продакшен.

Как начал?

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

Начал с самых простых задач:

  • поправить пару строк код,
  • обновить записи в БД,
  • почитать логи и понять почему падаем.

Этот период можно назвать знакомством с кодовой базой и осознанием, что ничего не знаешь! Тут важно иметь поддержку. Мне казалось, что я никакой ценности не приношу, но руководители всегда подсвечивали важность (Таня, Дима <3) и что прогресс есть. Самую мощную поддержку оказывал автор инфраструктурного проекта (Ерке, ты лучший!). Объяснял архитектуру, показывал как оптимизировать код, как деплоить и откатывать в случае фэйла (да-да, один раз слегка положил прод), по любому вопросу можно было пойти к нему и даже созвониться (это очень круто, потому что он техлид и времени у него оооочень мало).

Дальше задачи стали сложнее:

  • написать новую логику в старый функционал,
  • реализовать простые фичи

Этот этап можно назвать окрылением. Еще нахожусь на этой стадии и тут задачи интересней, а также приобретаешь новые навыки. Узнаешь как взаимодействовать со связанными сервисами на уровни API, получаешь доступы, больше погружаешься в работу сис. контроля версий, создаешь модели данных и т.п.

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

Чему научился?

Выше уже немного рассказал, но теперь по пунктам:

  1. Никогда не лезьте в продовую базу. Как вы поняли я и тут успел чуть нафакапить. Перезаписал одну строчку код, а это могло лишить нужных уведомлений команду. Но к моему счастью сразу это заметил и ментор помог быстро решить.
  2. Все факапят и начинают с простого топорного написания кода. Чтобы понимать, где нахожусь при выполнении кода или при дебаге, обкладывал чуть ли не каждый шаг простыми print(smth). Мне казалось, что такое стыдно показывать даже когда задаешь вопросы ментору по зуму, но он меня успокоил сказав, что даже самые топовые разрабы так начинают. А еще его спокойствие и поддержка в случае факапа придавало уверенности. Кстати, и команда относилась с пониманием, если что-то ломалось и правилось не так быстро, как хотелось бы.
  3. Никогда не давайте писать тесты разработчику. Это понял немного косвенно, потому что когда ты пишешь код, ты не думаешь "а что если так", твой основной вектор "как сделать чтобы так". Из этого можно сделать вывод, еще раз подтвердить майндсет тестировщиков, что тесты лучше писать тестировщикам (оставив юнит-тесты разработке).
  4. У разработчиков много инструментов, которые пригодятся тестированию. Почаще общайтесь с разработкой и узнаете много разных плагинов для командной оболочки или IDE, какие утилиты использовать для написания скриптов или как мокать гео на iPhone.
  5. Начинаешь лучше понимать, когда автоматизация не нужна. Только начав писать код понимаешь, что часто автоматизация это не единственное решение, и часто, не самое верное. По другом смотришь на построение процессов, т.е. анализируешь и понимаешь, что дешевле, быстрее и правильней описать флоу, чем долго кодить и не решить проблему. Надеюсь смог передать мысль :)

Пока это все. Но я продолжаю кодить, а значит еще будут посты про влияние кодинга на жизнь тестировщика. Лайки, подписка, репосты приветствуются :)

Картинки, как всегда, генерирует Алиса в нейробраузере Яндекс