Міфи про тестування програмного забезпечення та про професію тестувальника

Професія тестувальника програмного забезпечення (QA) суттєво відрізняється від інших ІТ фахів,
зокрема, від фаху розробника. Але достеменно мало хто розуміє деталі відмінностей цієї професії,
якщо не має прямого відношення до ІТ галузі.
Професія тестувальника програмного забезпечення (QA) суттєво відрізняється від інших ІТ фахів, зокрема, від фаху розробника. Але достеменно мало хто розуміє деталі відмінностей цієї професії, якщо не має прямого відношення до ІТ галузі. Тому дуже часто недосвідчені айтішники чи люди, які от-от тільки входять в ІТ простір, плутають обов'язки QA і розробників, підміняють поняття, несвідомо применшують значущість фаху QA над іншими, вільно апелюють до понять в QA, на яких не розуміються, чим суттєво шкодять всій галузі як такій.

Саме тому в цій статті ми зібрали та розвінчали 10 гарячих міфів про тестування програмного забезпечення які активно ширяться на просторах Інтернету, зокрема в чатах в ІТ середовищі на форумах, в соціальних мережах, спеціалізованих сайтах і тому подібне.
Міф 1. Тестування проводиться лише з готовим ПЗ
Коли тестувальник розпочинає свою роботу, це не завжди тестування написаного коду програми. Частіше за все це навіть не зовсім тестування коду, а перевірка вимог та створення тестових файлів, які застосовуються заздалегідь до створення готового програмного забезпечення.

Крім цього, процес тестування програмного забезпечення і процес написання програмного коду незалежні один від одного. А створення та оформлення тест кейсів може займати до 80% часу тестувальника на робочому місці.
Міф 2. Програмне забезпечення тестується тільки комплексно
Не завжди. Інколи треба протестувати якусь частину написаного розробником коду. І навіть якщо тестувальник проведе нескінчену кількість тестів повного функціоналу ПЗ, це далеко не означає, що програмне забезпечення комплексно протестоване.

Тестувальник завжди може щось недогледіти, пропустити, адже це така ж людина, якій, як і всім іншим членам команди ІТ компанії, властивий людський фактор неуважності чи спотворення об'єктивної дійсності на рахунок помилок та недосконалостей в продукті. Тому основне завдання – довести програмне забезпечення до рівня, який влаштує замовника, а не комплексно його протестувати.
Міф 3. Якщо ПЗ після тестування все ще має баги – це вина тестувальника
Звісно, інколи це може бути і так, але не завжди, особливо якщо тестувальник здебільшого відповідальний та професійний працівник. Часто причинами пропущення дрібних багів та недосконалостей є:

- обмежений дедлайн
- відсутність часу на якісну підготовку тестів
- низька вартість розробки і якості самого ПЗ
- непрофесійна розробка ПЗ
- складність самої структури ПЗ

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

А вже команда, яка ці помилки буде виправляти, має таки виправити їх, і не перекладати на плечі тестувальника всю відповідальність за свою неуважність чи недостатню компетентність.
Міф 5. Тестувальник шукає тільки баги
Тестувальники мають в комплексі розуміти систему ПЗ. До того ж, тестувальник має добре володіти англійською мовою ІТ, щоб досконало прочитати тех документацію, та зрозуміти особливості та дрібні деталі, побачити структуру і суть ПЗ.

Адже не всі помилки в коді є технічними. Дуже часто ПЗ є просто не зручним у користуванні, за що відповідає недосконало створене тех завдання на стадії проектування продукту. І саме в таких випадках виявляється максимальна уважність та фаховість тестувальника. Він чи вона мають побачити такі деталі, та навіть за відсутності технічних багів, повідомити свою думку щодо випуску продукту та передачі його клієнту в такому незручному стані.
Міф 6. Тестувати ПЗ може будь-хто
Це абсолютно не відповідає дійсності. Сьогодні для того, аби стати тестувальником, необхідно як мінімум 4-5 місяців вчитися на курсах тестування ПЗ і плідно практикувати, аби отримати необхідні знання, опанувати термінологію, практикуватися написанні тестів та автоматичних тестів під кожне окреме програмне забезпечення та їх багаторазове написання й застосування аби «набити руку».

До того ж, тестувальник має фахово володіти ІТ англійською, щоб читати код, вміти бути посидючим, сконцентрованим та не поспішати.
Міф 7. Автоматизація ІТ галузі витіснить фах тестувальника з ринку
Це неправда. Так, дійсно, вже зараз існують тести, які автоматично перевіряють ПЗ, але, по-перше, розробляють їх саме тестувальники, а, по-друге, машинам недоступна деталізована перевірка ПЗ на такі критерії:

- зручність користування для юзера
- привабливий зовнішній вигляд
- компактний інтерфейс, який допомагає скоротити час юзера

До того ж, машини не можуть по-людськи оцінювати ПЗ. В іншому, всі вище перераховані складові – це суто людські чинники, які впливають на популярність ПЗ на ринку, і їх може перевірити тільки жива людина, професійний тестувальник, який володіє всіма необхідними навичками.
Міф 8. Тестувальники ненавидять розробників і навпаки
Буває і таке. Але це залежить не від специфіки фаху тестувальника і фаху розробника, а від взаємин між колегами в команді та якості роботи скрам мастера з командою.

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

Але якщо саме ПЗ від початку зроблено неякісно, код написаний з великими огріхами, кострубато та непрофесійно, тестувальник тут ні до чого, і тому покращити якість ПЗ він своєю роботою просто не зможе. Він може лише вказати на ту кількість помилок, яка за кількістю своєю, напевне, дорівнюватиме кількості символів в усьому коді.
Міф 10. Тестувальник сам виправляє виявлені ним дефекти в ПЗ
Насправді тестувальник знаходить ці помилки та описує їх для розробника в спеціальних програмах – дефект репортах, описує їх також не тільки розробнику, а й будь-якому відповідному ІТ фахівцеві для подальшого виправлення.

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

Стартуй з безкоштовного вступного курсу:
Хочеш продовжити навчання на повній версії курсу? Залишай заявку!


Залиште заявку
Сформуємо цілі
Визначимо рівень знань



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



Made on
Tilda