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

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

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

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

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

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

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

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

А вже команда, яка ці помилки буде виправляти, має таки виправити їх, і не перекладати на плечі тестувальника всю відповідальність за свою неуважність чи недостатню компетентність.

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

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

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

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

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

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

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

Буває і таке. Але це залежить не від специфіки фаху тестувальника і фаху розробника, а від взаємин між колегами в команді та якості роботи скрам мастера з командою.

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

Тестування дозволяє виявити всі помилки та неточності, баги, обмеження, незручні та неефективні ділянки в коді, які не помітив чи не зміг виправити розробник.

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

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

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