- 1.А чи так важливі софт скіли?
- 2.Мало просто ставити запитання, треба ще знати, як ставити їх правильно і коли
- 3.Навчися не тільки говорити, а й слухати
- 4.Вчись зосередитися на тому, в чому всі зацікавлені … про все інше просто забудь
- 5.Вчися налагоджувати стосунки з іншими: поклич колегу на обід
- 6.Вчись відстояти тестування
- 7.Тайм менеджмент
- 8.Довіряй своїй інтуїції
- 9.Говорячи з досвіду
Відкривши будь-яку вакансію мануального тестувальника або автоматизатора (та й загалом будь-якого IT-шника), ти завжди виявиш необхідний список вимог та певного досвіду. Термін Soft skills (або «Гнучкі навички») у реальному житті ніхто не використовує, їх практично ніколи немає в списку вимог до кандидата, хоча ці навички не менш важливі, і вже повір, — на співбесіді тебе розглядатимуть саме з точки зору наявності Soft skills.
Звичайний список вимог виглядає як перелік завдань із тими чи іншими технологіями, досвідом роботи з конкретними базами даних та середовищами розробки, навичками написання тест-кейсів та чек-листів, знаннями методології розробки, процесу контролю якості тощо.
Якщо у списку взагалі є Soft skills, то зазвичай наприкінці чи в категорії «додаткові навички». Наприклад, згадка навичок комунікації, часто має на увазі можливість проговорити завдання з розробником зрозумілою йому мовою, не вдаючись до допомоги «технічного перекладача».
А чи так важливі софт скіли?
Для продуктивної роботи важливо вміння ясно викласти суть проблеми інженерною мовою, але не менш важливі і навички міжособистісного спілкування.
Які ж ключові софт скіли треба розвивати, коли опановуєш будь-яку IT-спеціальність? Або на які навички тобі варто звернути увагу, якщо береш людину в команду чи компанію?
Ось вам мій короткий суб'єктивний список недооцінених Soft skills для тестувальників.
Рекомендуємо публікацію по темі
Мало просто ставити запитання, треба ще знати, як ставити їх правильно і коли
Наразі не існує двох однакових проектів. Тому неважливо, у скількох ви вже взяли участь або про які чули на співбесідах, краще почати роботу над проектом з таких питань:
- Як ця програма буде використовуватися?
- Хто кінцевий користувач цієї програми?
- Які найпоширеніші конфігурації браузера, обладнання чи операційної системи?
Якщо ти не почнеш із цих фундаментальних питань, твоя робота із забезпечення якості може внести великий ризик в додаток. Наприклад, якщо тестований продукт використовується для покупок у дні розпродажів, має сенс запланувати та приділити велику увагу стрес-тестуванню та тестуванню продуктивності.
А якщо програма має справу з обробкою конфіденційних або персональних даних — слід додати до тест-стратегії тестування безпеки. Якщо домінуюча частина користувачів використовує лише один браузер при відвідуванні сайту, це заощадить багато зусиль, оскільки тобі не доведеться тестувати у великій кількості браузерів.
Вміння ставити правильні питання, знати, коли залишати питання відкритим, а коли дотиснути до кінця — це дуже важлива комунікативна навичка для будь-кого, хто займається тестуванням, особливо в просуванні кар'єрними сходами до лідської або менеджерської позиції, де ваші рішення безпосередньо впливають на якість програми .
Навчися не тільки говорити, а й слухати
Всі ми любимо поговорити, кожен має свою думку. Ми часто перебиваємо співрозмовника, який ще навіть не довів думку до кінця, щоб запропонувати своє вирішення проблеми чи завдання. Така поведінка не завжди вітається, навіть якщо ваше рішення може бути в рази краще продуманим та актуальним.
Вміння слухати — це теж навичка, і протягом своєї кар'єри я зустрічав кілька людей, які слухали, не перебиваючи, і справді чули те, що намагається сказати інша людина. Бути проактивним добре, але у робочому колективі треба знати міру. Наприклад, якщо тебе просять провести смоук-тест, не треба розгортати цілий регресійний сьют чи намагатися протестувати з надмірною деталізацією.
Просто почуй, що від тебе хочуть і зроби. Саме за це тобі сплачують гроші.
Вчись зосередитися на тому, в чому всі зацікавлені … про все інше просто забудь
Ніхто не любить безглузді мітинги, а безглузді мітинги тестувальників можуть бути просто гіршими.
Я чудово розумію, коли розробник хоче розповісти, як було складно вирішити поставлене завдання чи тестувальник хоче посвятити всіх в найменші деталі того, як він відловив критичний баг. Усі хочуть, щоб їхні заслуги були гідно оцінені. Але саме такі люди перетворюють щоденний стенд-ап на тортури. Зрозумій, що в цьому випадку від тебе хочуть почути лише те, що було зроблено, без деталей.
Як тестувальник, ти повинен уміти перетворити свій спіч на інформацію, що стосується бізнесу. Так що відмовся від тонни слайдів з купою тексту, графіків та таблиць.
Натомість покажи один слайд, на якому відзначені бізнес ризики та терміни завершення тестування. Ти не просто викладеш інформацію мовою, яку розуміють власники бізнесу, але ще й збільшиш цінності, зусилля та досягнення команди в очах замовника.
Вчися налагоджувати стосунки з іншими: поклич колегу на обід
Навіть при гнучкій розробці, де девелопер, DevOps, бізнес-аналітик і тестувальник повинні працювати пліч-о-пліч, між різними функціями є невидимі стіни. Найкращий спосіб подолати це — ініціювати спілкування.
Вже написано нескінченна кількість статей та книг про важливість роботи команди: регулярні особисті зустрічі, дейлі-стендапи, а також використання відеоконференцій для спілкування. Причому в останньому пункті використання камери просто обов'язково. Все це — чудові ідеї для обміну інформацією та взаємодії.
При цьому навички міжособистісного спілкування членів команди також важливі для успіху. Людина, яка ладнає з іншими, яку легко запросити на обід або побалакати у кулера, більш цінна. Проста розмова з розробником у кафетерії або на курилці, допоможе краще зрозуміти програму, ніж купа документації та нескінченний потік мітингів.
Вчись відстояти тестування
Протягом своєї кар'єри я став свідком дивовижної кількості знущань у світі тестування.
Я говорю про ситуації, коли люди з боку бізнесу чинять сильний тиск на тестову команду, щоб зменшити терміни, підживлюючи нескінченним попитом клієнтів на більш швидкі, кращі, нові програми або додатковий функціонал. Причому, як дивно це не звучало, нехтуючи якістю.
Коли бізнес не до кінця розуміє, чому так довго, він починає тиснути на останню ланку в ланцюзі виробництва, а саме на тестування, адже це остання барикада на шляху випуску продукту. Важлива навичка тут полягає в умінні відстояти свою позицію та вміти вести переговори, а не піддаватися тиску та погоджуватися на недосяжні терміни. Особливо не варто намагатися релізнутися будь-що за рахунок переробок або поспіху.
Завжди будуть терміни і люди, які продовжують думати, що розробник пише вже протестований код, а тестування — марний крок у життєвому циклі.
Отже, вміння відстоювати терміни без шкоди якості програми — це навичка, яку повинен відточити кожен тестувальник. Але мало бити себе кулаком у груди та заявляти: «Ми не встигаємо». Для цього додай собі в арсенал таку навичку, як робота з ризиками. За допомогою якісного аналізу ризиків ти зможеш наочно показати бізнесу, які наслідки його очікують у разі ігнорування чи стиснення того чи іншого циклу тестування.
Тайм менеджмент
Сюрприз, сюрприз! Роботи буде багато, дуже багато. Тому тестувальники часто виявляються чи не в змозі виконувати найтерміновіші завдання. І, намагаючись все встигнути, вони можуть знехтувати іншими, менш цікавими завданнями, які ще потрібно виконати, як оновлення регресійних тестів і побудови тестових сценаріїв.
Організованість та завчасне планування може заощадити тижні вашого часу на проекті. На одному з моїх проектів моя тест-менеджер постійно відстоювала позицію, що краще витратити день на аналіз і планування, ніж потім місяць займатися чим завгодно. На тему тайм-менеджменту є багато добрих статей та книг. Але пам'ятай невелику пораду — забудь про мультитаскінг, вона не працює.
Рекомендуємо публікацію по темі
Довіряй своїй інтуїції
Не має значення, наскільки успішно ти закінчив курси або як швидко тобі вдається вивчати нові технології, іноді інтуїцію тестувальника ніщо не замінить — і це не приходить лише з досвідом. Якщо на співбесіді ти проявиш себе як кандидат із допитливим розумом, бажанням докопатися до суті першопричини проблеми, це може перекрити певні прогалини та недоліки у резюме.
З особистого досвіду можу сказати, що я скоріше візьму собі в команду джуна, у якого горять очі і є бажання докопатися до істини, ніж аморфну людину, але з більшим списком технічних навичок.
Говорячи з досвіду
На щастя, часи, коли питання контролю якості вважалося другорядним, здебільшого залишилися позаду. Тому що якість стає важливою частиною кожного етапу життєвого циклу програми. І навіть якщо ти обереш повністю технічний шлях у кар'єрі, тобі знадобляться перераховані вище софт скіли, щоб стати ефективним командним гравцем та ефективно працювати в організації.
Ці навички можуть бути менш відчутними, але абсолютно необхідні як для тестувальників, так і для їх менеджерів.