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

[![Складно бути QA тому, що багато шляхів розвитку]Придивіться до шляху: в одній широкій дорозі сходяться багато стежок

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

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

Але є дві небезпечні крайнощі, які зустрічаєш через деякий час після початку:

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

QA на роздоріжжі#

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

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

Що ж робити?#

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

Це складно, але важливо. Challenge, який потрібно пройти. І навіть залишаючись “просто тестувальником” – потрібно відточувати мистецтво тест-дизайну (бо вчорашні тест-кейси можуть стати завтра неактуальними).

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