Створювати продукти — складно, а створювати якісні продукти ще складніше. Якщо умовно порівняти створення продукту програмного забезпечення зі створенням десерту — то замість борошна і масла вам знадобляться професіонали, налагоджені процеси, надійні технологічні рішення і, звісно, не обійтись без “жменьки” корпоративної культури.
З середини технологічних рішень можна зустріти вічний процес: Build, code, test, deploy.
Сьогодні зупинимось саме на тестуванні програмного забезпечення, як невіддільній частині побудови та покращення продуктів компанії. Допоможе нам у цьому Іван Мосійчук — Quality Assurance інженер з 4 річним багажем знань та досвіду у тестуванні.
Мало хто за межами IT-індустрії чітко уявляє собі, чим саме займаються тестувальники програмного забезпечення. По секрету вам скажемо, що іноді навіть серед тих, хто безпосередньо залучений в розробку ПЗ, зустрічаються помилкові уявлення щодо роботи фахівців із забезпечення якості. Тому ми поставили Івану кумедні питання, знайдені на просторах інтернету та отримали безліч практичних інструментів для навчання та росту у професії QA інженера.
Ну що, розпочнемо?
Навіщо потрібні тестувальники на проектах?
Сам процес тестування надзвичайно важливий.
Це доведено і суперечки з цього приводу давно не актуальні.
В офіційній термінології цілями тестування визначаються: виявлення дефектів, запобігання появі дефектів та покращення якості продукту. Для більш детального опису краще звернутись до ISTQB експертів, або прочитати Syllabus. Якщо говорити про реальні проблеми, які можуть виникати на проектах, то ціль тестування полягає у зменшенні ризиків та збереженні коштів компанії. Ці два фактори є відповіддю на запитання навіщо потрібно тестувати продукти.
Очевидно, що чим пізніше знайдений дефект — тим більша його вартість. Наприклад, дефект, знайдений на продакшені, може спричинити втрату користувачів чи фінансів.У той самий час, та ж проблема, знайдена під час тестування, може коштувати годину додаткової розробки.
Щодо ризиків — ризики побудови неякісного продукту зменшується за умови чіткого і правильного тестування на проекті.
Існують проекти без окремої ролі тестувальника, і вони все одно успішні, тому я впевнений, що проекти можуть існувати без тестувальників (як ролі), але тільки за умови якщо інженери знають підходи до тестування та можуть поєднувати свою роль та роль тестувальника.
Чим займаються QA інженери/інженерки?
На цьому моменті Іван хоче впевнитись, що диктофон працює і буде чутно інтерв’ю 🔥😎👂
Повертаючись до баз — існує поняття Software Testing Life Cycle, в якому описуються процеси тестування, і зазвичай QA інженери та інженерки всім цим і займаються.
Потрібно розуміти, що позиція QA може бути сумісною з позицією Бізнес-аналітика, Власника Продукту чи Проектного Менеджера, в залежності від проекту.
Мені дуже подобається порівняння позиції QA спеціалістів та бігунів.
Є марафонці та спринтери і, дивлячись на їхні м’язи , можна побачити дві абсолютно різні статури. Ніби обидві людини займаються тим самим бігом, відмінна тільки дистанція, яку вони біжать, проте їхні м’язи виглядають та формуються інакше.
Так само різниця в проектах, де інженери-тестувальники можуть робити зовсім різні види роботи.
Наприклад, хтось працює з документацією, а інші спеціалісти ніколи з нею і не зустрічаються, пишуть код, або автоматизовані тести.
Обов’язки бувають зовсім різними. Якщо мова зайшла про документацію — то в Agile Manifesto (здається, зараз будь-яка компанія пише про те, що працює за цією методологією, застосовуючи фреймворки Scrum, Kanban) описані принципи самого Agile, де один з них, говорить, що працюючий продукт має стояти вище ніж всеосяжність документації. (working software over comprehensive documentation)
деякі люди, посилаючись на цей пункт, вважають, що документація зовсім не потрібна. Проте за якийсь час люди забувають, як працює продукт і не мають письмового джерела знань.
Тому я вважаю, що документація — це необхідність. Вона має бути своєрідною “вишенькою на торті”, її повинно бути в міру та вона обов’язково має синхронізуватись зі змінами вашого продукту, адже кому потрібна документація, якою ніхто не користується і користуватись не буде.
Які базові soft та hard skills необхідно мати людям, що займають/йдуть на посаду Quality Assurance engineer?
Якщо говорити про hard skills — це те чого не буває багато. Чим більше у тебе хард скіллів, тим краще.
Мені подобається тренд, який вже декілька років існує і дійшов до Українського ринку ІТ. Тренд полягає у тому, що тестувальники, незалежно від позиції, яку вони займають, хто б як себе не називав — Manual QA, Automation QA, SDET чи Test engineer — всі розвивають свої хард скіли. В Сполучених Штатах наявність хороших технічних знань для QA спеціалістів являється базовою вимогою. До нашого ж ринку ця практика дійшла після перекладу книги How Google tests software на російську мову.
З цієї книги можна дізнатись про те, хто такі SDET спеціалісти та про випадки, коли тестувальники майже не зустрічаються із UI частиною продукту, працюючи більшість часу із кодом.
Підсумовуючи твої слова: український ринок йде до того, що людина, яка займає позицію QA, має володіти технічними навичками. Якими саме?
Найадекватніший метод дізнаватись з описів вакансій, щоб визначитись, що саме актуально.
Важливо знати як працює АРІ, а також цінними є знання різних баз даних.
Завжди буде плюсом знання мов програмування, або хоча б розуміння базових принципів програмування.
Знання методології Agile та фреймворків Scrum, Kanban дадуть змогу покращувати самі процеси.
Одночасно з покращенням процесів люди починають краще працювати. Чим більш зручні умови — тим краще працюється. Тобто покращуючи процеси розробки, ми неопосередковано покращуємо подальший продукт. Відповідно, знання хороших практик буде додатковим плюсом до наявних технічних навичок.
Говорячи про гнучкі навички я б тричі зазначив комунікацію, комунікацію і ще раз комунікацію. Вміння комунікувати з замовниками та з командою.
Особисто для мене співпраця у команді є найважливіша. Адже, добре побудована комунікація може позбавити потреби виконувати зайву роботу.
Які існують види тестування?
Функціональне та нефункціональне також дехто виділяє такий вид тестування, як “пов’язане із змінами”.
Є люди, які розділяють автоматизоване та ручне тестування. Я б не робив цього, бо вважаю, що автоматизоване тестування це навичка, якою повинен володіти інженер чи інженерка з тестування, а чи застосовувати її на проекті — інше питання.
Оскільки про методику функціонального тестування можна здогадатись з самої назви, хочу зосередитись на нефункціональному тестуванні.
Нефункціональними видами тестування є: Performance and Load Testing, Stress Testing, Installation testing і тд. Всі ці види тестування використовуються в залежності від потреб самого продукта. Наприклад, для того щоб зрозуміти чи потрібне Performance and Load Testing, варто вирахувати ймовірність того, що продуктом користуватиметься велика кількість людей, а також чи буде виконуватись значна кількість дій одночасно — залежно від цього і визначається чи є необхідність у проведенні такого виду тестування.
Зі свого боку можу сказати, що зараз, при побудові будь-якого проекту, я завжди звертаю увагу на такий вид нефункціонального тестування як usability, тому що переконаний, що кожен продукт/проект має бути доступний для всіх людей, незалежно від обставин. Usability являється однією з ключових ознак хорошого продукта.
Мене дивує, як люди починають будувати нові продукти, не дивлячись на usability. Тим паче, якщо говорити з меркантильної точки зору — у багатьох розвинених країнах є штрафи за продукти, що є недоступними для людей з обмеженими можливостями.
Одне з найпоширеніших питань про QA професію: чи можливо провести тестування без спеціальних знань?
Існують платформи, де за знайдені баги навіть платять, але якщо говорити про аналогічні сценарії, то поділюсь історією, яка трапилась буквально вчора. У мене ремонтували інтернет, опісля чого протестували — кажуть, дивіться, яка хороша швидкість, все працює, але ввечері я вже не міг дивитись Нетфлікс, бо інтернету елементарно не було.
І ніби тестування було проведене, але якість сумнівна. Те саме з тестуванням без спеціальних знань. Так, будь-хто може тестувати продукти, але якість та кінцевий результат будуть відповідні, адже чим більше знань, тим краща якість тестування.
Поговоримо про автоматизоване тестування. Як побудований цей процес в Innocode?
В Innocode дуже хороша культура написання Unit tests.
Unit tests зазвичай пишуть розробники. У нашій компанії ця культура розвинена і це прекрасно.
На QA конференціях можна почути лекції з назвами на кшталт “як змусити девів писати юніт тести і що для цього потрібно робити”.
В Innocode немає потреби когось змушувати щось робити, адже розробники самі розуміють перевагу юніт тестів і навіть на продуктах, яким 10 років, ці тести працюють.
На проекті Swoosh ми вирішили застосувати більше автоматизованого тестування. Ідея була в тому, щоб додати Cypress і використовувати як інтеграційні, так і end-to-end тести. Коли я прийшов на цей проект, front-end розробники вже розпочали писати такі тести.
На той момент я не володів мовою JavaScript, застосовуючи яку потрібно писати тести на Cypress, тому довелось вивчити її. Коли я забрав від розробників роботу з написанням інтеграційних та end-to-end тестів, що логічно поєднувалось з моїм досвідом тестування та розумінням підходів, як краще протестувати той чи інший функціонал, то розробники змогли писати Unit тести ще й на front-end.
На наступному проекті ми продовжили цю практику. Так у нас з’явились звична піраміда тестів, де Unit тести пишуться розробниками, окремо як на Front-end так і на Back-end, а в мою відповідальність входить написання інтеграційних та E2E тестів використовуючи Cypress.
Чи можливе 100% автоматизоване покриття тестами?
Автоматизоване тестування допомагає своєчасно виявити помилки у системі, проте ручне тестування дозволяє відчути себе “у шкурі користувачів” та переконатись, що продукт дійсно зручний.
Є такий вид менюал тестування — exploratory testing і якщо вміти ним користуватись, то можна виявити незручності у системі, або протестувати сценарії, що не є покриті автоматизованими тестами. Потрібно розуміти, що автоматизоване тестування не знайде незручностей, які ти відчуваєш просто як людина, коли користуєшся продуктом.
Тому для мене частина меньюал тестування є обов’язковою.
Знаю, що у багатьох компаніях є практика розділяти тестувальників, які роблять або виключно менюал або виключно автоматизоване тестування. Це теж непоганий підхід. В Innocode ж зазвичай один QA на проекті, тому писати чи не писати автоматизовані тести — вибір за кожним із інженерів.
Я роблю так, що спочатку виконую ручне тестування і, упевнившись, що функціонал працює, пишу автоматизовані тести.
Якщо говорити про 100% покриття коду — то можна дивитись на code coverage (скільки коду покрито тестами);
Є безліч практик, рекомендую з ними ознайомитись у цій статті від гугл: https://testing.googleblog.com/2020/08/code-coverage-best-practices.html
Потрібно розуміти так само, що великий відсоток покриття коду тестами не гарантує їхню якість.
Чи доводилось переписувати тести за час проекту?
Так, це нормальна практика. Тести, як будь-який інший код, потрібно підтримувати і іноді переписувати. Наприклад, ми використовуємо GraphQL, і там бувають зміни у мутаціях чи кверях. Також виникає потреба поправити, чи змінити локатори, хоча цей сценарій є ще менш ймовірним, адже ми використовуємо тест атрибути, про які можна детальніше дізнатись за наступним посиланням: https://docs.cypress.io/guides/references/best-practices.html
Іншими словами: написані раніше тести можна використовувати знову і знову?
Саме так. Зручність у тому, що інженер чи інженерка можуть піти пити каву, а автоматизовані тести — ні.
Розкажи ще, будь ласка з чого почалась твоя історія в IT?
Мій вхід в ІТ був типовим — навчався в університеті банківській справі, зрозумів, що це не моє, найкращий друг, за професією QA, порадив пройти курси, почитати Савіна (мабуть, будь-який тестувальник починає з цієї книги) і це змінило хід моєї кар’єри.
Після курсів були різні компанії, додаткові проекти.
Загалом 4 роки займаюсь цією справою.
Найскладнішим за ці 4 роки були переходи у існуючі команди. Знайомство з новим колективом, знайомство з новим продуктом, необхідність швидко приносити результати.
Я завжди залежний від того чи приношу результат чи ні. Це може заважати моменту переходу в іншу команду і ознайомлення з новим продуктом, адже хочеться якнайшвидше приносити результат.
Фейли звісно були, як у кожного, але таких, від яких було б смішно, а не боляче — не можу пригадати. Усі помилки формують досвід.
Нещодавно читав про фейли QA, в одній з історій розповідалось про наслідки у 50 000 долларів через відсутність якісного тестування . На щастя, таких історій у моїй кар’єрі не траплялось 😇😅
Які поради можеш залишити для QA фахівців, що стають на шлях написання автоматизованих тестів?
Звертайтесь до Google.
Знайдіть собі ментора, є багато людей, які діляться своїми знаннями, варто лише запитати про допомогу. Є безліч курсів, які поповнять ваші знання та, звісно, корисні книги:
https://t.me/automation_remarks — думаю, що найкращий український телеграм блог по QA
https://t.me/qa_club_lviv — із назви все зрозуміло)
https://www.cypress.io/blog/ — Сайпрес блог, також у них є Ютуб канал, прикріпив знизу
https://www.youtube.com/channel/UC-EOsTo2l2x39e4JmSaWNRQ
https://github.com/Vladislav610/QA_bible — безліч корисних матеріалів по QA практиках
https://classroom.udacity.com/courses/ud891 — про тестування доступності
https://javascript.info/ — Книга і купа інфи по JS
https://www.udemy.com/course/the-complete-javascript-course/ — курси, що можу порекомендувати по JS (платно)
https://www.pluralsight.com/ — теж безліч JS курсів (платно)
Як тобі? Чи була корисною для тебе стаття?
About Innocode in short links:
Own Products: innocode.com/our-products
WordPress Projects in Kyiv: innocode.com/projects
News, vacancies, meetups — Facebook: www.facebook.com/innocode.no
Behind the scenes life —
Instagram:https://www.instagram.com/innocode.people/
Stories about us, people, who build Innocode: medium.com/innocode-stories
