Володимир, QA Team Lead: "Рівень підготовки двох людей після тих самих курсів може бути дуже різним"

Сьогодні про ціну помилки, вхід у професію та про те, як не допустити «замилювання ока», поговорили в рамках інтерв'ю з QA Team Lead у компанії Yellow Stone Володимиром. Надаємо йому можливість представитися самостійно :)

«Мене звуть Володимир, я працюю в ІТ сфері вже близько 6 років. За плечима маю досвід роботи як у невеликих продуктових компаніях, так і у великих аутсорсах. На даний момент обіймаю посаду QA Team Lead у компанії Yellow Stone, де QA відділ налічує 16 осіб.»

1. Як ви потрапили у тестування?

Потрапив у тестування я у 2014 році. Довго думав над вибором професії, але кілька моїх друзів, які на той момент вже якийсь час працювали в IT-сфері, порадили прочитати всім відому книгу Романа Савіна і пробувати свої сили в ролі тестувальника. Професія здалася чимось новим, і я почав шукати більше інформації в Інтернеті, переглянув кілька онлайн-курсів, оновив резюме та, звичайно ж, почав шукати роботу. Щодня мій ранок починався з того, що я розсилав резюме на всіх можливих ресурсах з пошуку роботи, де бачив вакансію з позначкою Intern/Junior QA, але звичайно ж, відповідей я не отримував, тому що на той момент посада тестувальника почала набирати популярності на ринку і розглядати людину без досвіду ніхто не хотів. Потім один мій знайомий порадив мені закінчити курси, де я міг би отримати якийсь досвід, що вже було б непоганим пунктом у резюме. Що, власне, я зробив. Пройшовши курси, я також отримав трохи практики, тому що ми проводили тестування на продукті, що розроблявся в той момент, і знаходили там реальні баги, які ми ще вчилися правильно описувати. Проапгрейдив своє резюме новим пунктом про успішно пройдені курси, я взявся заново розсилати резюме і також продовжував вечорами для себе вчити щось нове. Паралельно один мій знайомий на той момент працював у маленькій веб-студії, яка займалася розробкою сайтів в області e-commerce (і навіть не було тестувальників, оскільки розробники самі тестували всі свої продукти). Він запропонував мені попрактикуватися в тестуванні на їхніх сайтах, де я почав набивати руку. Я тестував сайти які він скидав, описував у гугл-доку знайдені баги, за що отримував найцінніше на той момент - досвід та запис у резюме про фріланс. Через кілька місяців і кілька співбесід, я отримав довгоочікуваний оффер і почав повністю освоювати роль тестувальника.

2. Наскільки ефективні, на вашу думку, різні курси QA? Чи наймали в команду хлопців одразу після них? Якими навичками та базою повинен у принципі мати Junior-тестувальник?

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

Мені доводилося співбесідувати хлопців одразу після курсів – і рівень підготовки був абсолютно різним. Іноді навіть у двох людей, які закінчили одні й самі курси, рівень отриманих знань дуже відрізнявся, так що тут, швидше, справа в бажанні розвиватися і мотивації кожного, хто претендує на посаду Junior QA. Основні навички, якими повинен мати початківець тестувальник, крім теорії, можуть бути досить різними, в залежності від проекту та вимог компанії, але потрібно розуміти основні принципи клієнт-серверної архітектури, розуміння front-end частини (це не означає, що потрібно вміти верстати, але треба розуміти принципи того, як створюються HTML-сторінки), а також знання бази даних і написання простих SQL запитів завжди будуть корисними.

3. Наскільки нині важливі навички програмування для QA?

Знову ж таки, все залежить від компанії та вимог до даного фахівця. Наприклад, якщо тестувальник хоче надалі розвиватися більше в технічну сторону, припустимо, в автоматизацію тестування або в розробку, тоді, безумовно, навички програмування must have для даного фахівця. В іншому випадку програмування не обов'язково в тестуванні, але зайвим ніколи не буде, тому що з навичками програмування приходить більше розуміння того, як працює система зсередини, і завжди можна спростити монотонну роботу.

4. Де брати новий досвід тестувальнику, котрий вже довго працює на одному проекті?

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

Завжди можна розглядати різні типи тестування, приділити більше уваги, наприклад, back-end тестування, API (у цьому може допомогти кілька відмінних інструментів, таких як Postman, SoapUI та інші), спробувати себе в автоматизації або навантажувального тестування. Не варто забувати про написання документації, будь то прості тест-кейси, чек-листи або тест-план, це завжди буде корисним особистим досвідом, а також буде користь для проекту.

5. Якою може бути ціна помилки на хайлоаді?

У плані фінансових та репутаційних питань втрати можуть бути колосальними, тому що навіть незначні візуальні баги (проблеми з версткою) можуть назавжди відлякати нового користувача, котрий до нас більше ніколи не повернеться. Якщо говорити про більш глобальні помилки, то все може бути набагато гірше, наприклад, багато хто пам'ятає кейс, коли Apple викотила оновлення операційної системи, в якій знайшли досить критичний баг, який полягав у наступному — якщо користувач встановлював руками час у телефоні 1 січня 1970 року , то телефон перетворювався на «цеглу».

Чому так сталося? 1 січня 1970 - це дата, від якої ведеться обчислення так званого UNIX-часу, іноді також називається «комп'ютерним часом»; і на будь-якому iOS-пристрої час обчислюється в секундах від півночі 1 січня 1970 (01.01.1970 00:00). А через різні часові пояси стандартний час на пристрої віднімається/додається до GMT. Якщо кількість секунд стане негативним, це призводить до збою.

Іншими словами: в коді операційної системи iOS є операція поділу на поточний час, а поділ на нуль призводить до помилки.

Часовий пояс iPhone відстає від GMT, що може призвести до негативного значення UNIX-часу, а це, у свою чергу, призводить до помилки.

У той період зчинився галас через цей баг, що призвело як до фінансових, так і репутаційних втрат. Звичайно, кейс не з простих, всього цього можна було уникнути, якби їх QA-відділ провів тестування, застосувавши техніку аналізу граничних значень, як мінімум.

6. Чи є принципова різниця між QA та QC?

Якщо ми загуглимо дані значення, то побачимо приблизно таке: “QC (Quality Control) – контроль якості продукту – аналіз результатів тестування та якості “білдів” у процесі розробки.

QA (Quality Assurance) вирішує більш глобальні завдання. Аналізуючи роботу тестувальників та QC, у разі виникнення проблем, вчасно знаходить шляхи її вирішення і не дає їй розвинутись та вплинути на якість продукту.” Виходить, що QC є частиною QA, але на практиці ці поняття рідко розрізняють, зазвичай будь-якого спеціаліста називають просто QA, навіть якщо він займається лише тестуванням та нічим іншим. Так що не раджу занадто сильно зациклюватися на термінології, якщо від вас цього не вимагає поточний роботодавець :)

7. Розкажіть улюблений жарт про тестування

Звичайно, це баян, але все ж таки:

«Тестувальник заходить у бар і замовляє: кухоль пива, 2 кухлі пива, 0 кухоль пива, 999999999 кухоль пива, ящірку в склянці, –1 кухоль пива, qwertyuip кухоль пива.

Перший реальний клієнт заходить до бару і питає, де туалет. Бар спалахує полум'ям, усі гинуть.»