Про знання коду, навчання в університеті та баги: 13 дурних запитань QA Engineer компанії Reface
bit.ua знайомить із сучасними технологічними професіями. Для цього ми спілкуємося зі спеціалістами й ставимо їм 13 дурних запитань.
У цьому матеріалі ми мучимо QA Engineer компанії Reface Марію Ільїну. Фото в матеріалі також надав Reface.
Хто такий тестувальник і навіщо він потрібен?
Почнемо з того, що тестувальник – це дуже загальна назва. Зазвичай коли ми говоримо про спеціальність, то використовуємо поняття QA та QC.
Різниця в тому, що QA – це quality assurance, тобто забезпечення якості. QC – це quality control, тобто контроль якості.
Між ними є деякі відмінності, зазвичай ми хочемо, щоб у нас скрізь був QA-процес. Щоб ми забезпечували процес тестування впродовж усього процесу розробки, а не лише фіксили баги наприкінці.
Тобто QA Engineer – це саме та людина, яка й забезпечує якість на всіх етапах.
Тестувальник, який просто ходить і тикає всіх носом у помилки, а сам їх не виправляє?
В ідеальному світі QA – це людина, яка бере участь у кожному етапі розробки.
Цей процес є таким: є ідея, ми її проробляємо та створюємо документацію, аналіз, дизайн, розробка, потім тестування, потім «шліфування», потім підтримка тощо.
QA беруть участь і в ранніх етапах розробки, навіть під час проговорення ідеї та способів її реалізації. Це дає нам можливість поставити якісь запитання, щоб потім великі баги просто не зробити.
Не запрограмувати щось хибне значно дешевше, ніж потім ці баги видаляти.
Прогери самі не можуть там все перевірити? Чому для цього є окремі люди?
У деяких компаніях існує популярна тактика: якщо в штаті є тестувальник, то він і винен в усіх багах. Зазвичай це не так працює.
Баг – це наслідок роботи всієї команди. Код без багів неможливий. Окрім цього, слід зазначити, що баг не є завжди помилкою чи недопрацюванням, баг – це незбіг очікуваного результату й того, що ми маємо на виході.
Програмісти та дизайнери є людьми, і вони не можуть продумати всі-всі варіанти використання програми. А навіть якщо й можуть, то це не завжди вигідно з боку витрачених зусиль.
Приклад із власного досвіду. В Україні люди, у яких немає ІПН, за законом можуть робити всі операції за серією й номером паспорта.
Але, наприклад, monobank, який відкрили у 2017, видавав картки тільки за наявності ІПН. Без податкового коду можна отримати картку тільки з 2020 року.
Найімовірніше, для monobank тоді було пріоритетніше виправити інші баги й впровадити інші функції.
Тестувальнику треба знати, як писати програми, щоб знаходити баги? Чи в нього якісь окремі знання?
У нас в Reface ми часто відповідаємо наліпками, де написано «Да, но нет, но да». І це дуже добре описує відповідь на це запитання.
Я вважаю, що так, QA Engineer повинен мати базову технічну освіту й розуміти, як влаштоване та як працює ПО. Як будується архітектура, як працює API, бази даних та інше.
Лише так ти зрозумієш, як найкраще протестувати програму, які є потенційні слабкі місця.
Також тестер має додаткову базу знань. QA – це просто інша експертиза. Ти витрачаєш свої зусилля й час на вужчу спеціалізацію.
Тут є свої знання, своя теорія, своя практика, інші технічні рекомендації.
Натомість існує багато тестерів, які не вміють писати код. Я не можу сказати, що це норма. Насправді мене це засмучує.
У QA є досить багато зон відповідальності й завдань. Ти маєш слідкувати за процесом розробки, щоб він був правильним. Також маєш писати документацію, писати автотести та release notes, протестувати все перед релізом ще раз.
Якщо ти не розвиваєшся, не розвиваєш свої технічні навички, то ти назавжди залишишся людиною, яка вміє робити тільки якийсь маленький шматочок роботи.
Напевно на ринку ще є потреба в таких спеціалістах. Але, як завжди, чим глибша твоя експертиза, тим більше ти коштуєш, тим ти цікавіший і бажаніший для роботодавця.
Бачив відео на YouTube «Як стати тестувальником за 2 години». Це так легко?
Я ніколи не бачила таких відео, і, звичайно, це неправда. Ти не зможеш опанувати нову професію ні за 2 години, ні за 2 тижні, ні за пів року.
Я не розумію, чому люди думають, що все так просто. Якби гроші зароблялися просто, то вони були б у всіх. У цьому світі нічого не дістається на ізі.
Я не проходила жодні курси, я навчалася на програміста в КПІ. Десь в універі я почала цікавитися тестуванням. Мені сподобалося, що там все дуже динамічно й усього дуже багато.
Я почала читати книжки. Читала тестування батьків і матусь, які взагалі починали просувати QA як окрему сферу. Також дивилася відео, але вужчі, наприклад про security testing і його особливість.
Стати тестувальником так швидко – неможливо.
То що, треба йти в університет, вчитися на тестера чотири роки, а потім магістратура?
Я навчалася в університеті, і більшість тестувальниць, яких я бачила, також мали технічну профільну або якусь біляпрограмну освіту.
Так формуються спеціалісти, які здатні написати автотест і протестувати back-end, зв’язок із базою даних тощо. Такій людині можна доручити всі завдання.
Я не думаю, що історія з університетом обов’язкова для всіх. Якщо людина здатна технічно мислити, то самонавчання для неї теж спрацює.
Базисні знання програмування я здобула в універі. Але суто QAшні штуки я здобувала сама.
Можна стати професійним QAшником без освіти, але цей шлях також займе певний час, і доведеться докласти зусиль.
Наздогнала мене реклама у фейсбуці, кажуть, що вже через місяць почну заробляти більш ніж 1000 доларів, а через два – більш як 2000. Так багато платять за це?
Не знаю, де ви знаходите таку рекламу, але я й сама чула від людей з IT-сфери, що тестувальники – це якісь тупі люди, які просто клацають по кнопках.
Ну йди поклацай по кнопках, попрацюй, я подивлюся, як ти впораєшся.
За місяць можна щось вивчити. Навіть пройти якусь співбесіду й отримувати пару сотень доларів.
Але далеко не дві тисячі, і все не так просто. Загалом інформацію можна легко перевірити на DOU. Звісно, QAшником можна заробляти як $2000, так і більше. Але не після пів року роботи, навіть не через рік, і навіть не два.
Для високої зарплати потрібно знати автоматизацію, security testing, тестування навантаженості системи тощо.
Можна заробляти великі гроші, але це не буде щось легке. Це буде високий рівень відповідальності й високий рівень знань.
Пам’ятаю свою першу зарплату. Коли я вчилася в універі, мені підвернулася можливість потестити мобільний застосунок. Це був фриланс, ми домовилися на $200 у місяць. Але в результаті мені виплатили $200 за два місяці.
Проте за ці два місяці я встигла потестити ще два проєкти, здобула певні знання, маленьке портфоліо. Коли я йшла на свою першу повноцінну роботу, то вже могла щось там відповісти й зробити. На цій повноцінній роботі моя зарплата становила $400.
Фейсбук нещодавно повністю впав через оновлення маршрутів з’єднання, як таке могло статися у світі, де існують тестувальники?
У фейсбуку немає тестувальників, там все в автотестах, і роблять їх програмісти. Це нормальна практика.
Загалом такі глобальні збої необов’язково є очевидними для програмістів, завжди існує якась похибка.
Завдання QAшника – знайти якомога більше багів, але такі збої можуть іноді траплятися. Це нормально, ми не можемо передбачити всі кейси.
Якби тестування не існувало взагалі, то збої ставалися значно частіше.
У нас є різні алгоритми, штучні інтелекти, чому вони самі не можуть виявляти баги?
Можуть і роблять. Автоматизація тестування – це створення ПО, яке тестує ПО.
Проблема в тому, що перед тестуванням потрібно розробити дизайн перевірки. Продумати, як із найменшими зусиллями та якомога швидше охопити більший пласт програмного забезпечення.
Я все одно людина, я думаю більш непередбачувано, ніж ПО. Плюс усе що ми розробляємо, ми розробляємо для інших людей.
Алгоритм класно оптимізує час і продуктивність роботи, але все одно багато функцій перевіряє людина.
А чого не можна просто написати код без багів?
Автотести використовують не тільки QA, розробники також пишуть їх для своїх потреб. Завдяки їм можна побачити помилки в коді й виправити їх.
Автотести самі собою неідеальні й можуть щось пропустити. Вони потребують додаткової перевірки з боку людини.
Писати код без багів не можна, бо ми всі люди й не можемо зробити нічого ідеального.
Чув, що на деяких багах тримаються цілі сайти, як це зрозуміти, щоб раптом не виправити?
В ITшних тусовках багато є жартів про так званий legacy code (поганий код, який дістався у спадок від минулих програмістів). Що з ним робити? Або переробляти, або не чіпати.
Але зазвичай, якщо в компанії є ресурс, то такий код переписують.
Де та межа між знаходженням помилок і прискіпуванням до чужого коду?
Завжди є межа, і в кожного ця межа своя. Напевно, деякі розробники вважають, що я прискіпуюсь. Здається, деякі тестувальники бувають ще прискіпливішими.
Тестування може не закінчиться ніколи. Але існують відповідні метрики, після яких ми зупиняємося. Коли код пройде якісь певні перевірки, деякі моменти працюватимуть, і тоді ми вирішимо, що вже досить.
Якщо бути відвертим, то найчастіше піджимає час, і ти робиш максимально можливу кількість перевірок, щоб не затягувати випуск нового білда.
Є якісь мінімально необхідні штуки, без яких не можна випускати реліз.
Як не наробити ще більше багів, коли виправляєш старі?
Добре знати affected areas (зона функціоналу, яку зачіпають зміни певного шматка коду). Добре розуміти архітектуру саме твого ПО, що з чим пов’язано. І думати. Спочатку думати, лише потім робити.
