Почему сложно быть QA? (часть 2)

Чем больше возможностей, тем труднее выбрать. Вадим Мозговой

Сложно быть QA потому, что много дорог развития

Присмотритесь к пути: в одной широкой дороге сходятся многие тропинки

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

Сам я попал в тестирование с университетского курса прикладной физики по совету моего близкого друга, который уже тогда был успешным программистом. Его мнение тогда было “Пойди, подучись пару месяцев программировать”. Прошло 8 лет. Программировать учиться можно всю жизнь. А вот профессию свою я бросать пока не собираюсь:)

Но есть две опасные крайности, которые встречаешь через некоторое время после начала:

  1. Всё кажется понятным, человек попадает в зону комфорта – и остаётся “на всю жизнь” “кликером”: кофе, новости, посмотреть котиков, просмотреть зафикшенные баги, посмотреть рабочую почту и новые хотелки заказчика, пообедать – а там и домой пора, расслабиться в компании любимых сериалов.
  2. Всё кажется понятным и хочется бежать дальше: вырасти в QA лида, тим-лида, директора, автоматизатора, свой бизнес и полет фантазии.

QA на распутье

Проблема в том, что QA – это гораздо более комплексная, чем кажется на первый взгляд. Тест-кейсы придумывать – нужно как понимание продукта, так и определенный, хотя бы интуитивный, математический аппарат. Нужна определенная дисциплина для поддержания документации в актуальном состоянии. Для того, что бы понимать, какая документация эффективная и нужная, а какая будет только зря потраченным временем. Понимание “тайм-менеджмента”, “риск-менеджмента”. Понимание того, как работает “железо”, на котором крутится создаваемый продукт, как работает операционка. Потому, оставаясь “в своей профессии” для того что бы делать свои задачи эффективно, QA постепенно осваивает следующие:

  1. Программирование; причем, далеко не всегда на одном языке
  2. Программирование на уровне ОС: bash, powershell; нужно будет как для автоматизации задач следующего пункта, так и для нетривиального тестирования безопасности
  3. Базовые знания в DevOps: что бы не ждать пока до тебя дойдет сис.админ , что бы подправить настройки тестового окружения или просто развернуть пару дополнительных виртуалок
  4. Проектный менеджмент
  5. Бизнес-анализ
  6. В зависимости от продукта – может быть дополнительное развитие в “не-айтишные” области экономики, медицины, финансов, продаж
  7. Дизайн и приграничные области: как для тестирования юзабилити так и для того что бы делать няшные скриншоты в джиру.
  8. SEO, SMM и прочие сетевые и маркетинговые технологии – для понимания, какие элементы нужны будут бизнесу
  9. Психология, умение решать конфликты, вести переговоры, мотивировать
  10. И еще 100500 пунктов, с которыми вы встречаетесь так или иначе

Что же делать?

Самое важное и самое сложное – выбрать для себя цель. Или цели. Перестать обманывать себя и – что самое главное – не давать тебе заснуть в “зоне комфорта”. Мир IT развивается очень быстро 24 часа в сутки: если это не сделали мы сейчас, то вечером, ночью или утром это сделают вместо нас в Америке, Китае или Индии (как бы не любили у нас шутить по поводу кода “индусов” – на десять тысяч пару гениев можно встретить, которые займут руководящие должности в Google, Microsoft и других гигантах). Выбрать и развивать себя в определенной сфере тестирования: до сих пор профессионалов в тестировании безопасности, производительности не так много. А с развитием операционных систем и увеличением BigData продуктов потребности в них будут только расти.

Это сложно, но это важно. Challenge, который необходимо пройти. И даже оставаясь “просто тестировщиком” – нужно оттачивать искусство тест-дизайна (потому что вчерашние тест-кейсы могут стать завтра неактуальными).

Так что, как бы не говорилось в “рекламе” разнообразных курсов, что за пару месяцев из домохозяйки можно стать супер-высокооплачиваемым QA – это не так легко. Это сложный путь развития QA. Более того, написанное выше – это больше развитие QA как “технического специалиста”, а именно про QA – в следующий раз.