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

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

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

Розробка не дорівнює тестуванню

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

Звісно, теоретично тут немає нічого складного. Але на практиці є свої тонкощі, адже розробка і тестування - це абсолютно різні професії (хоча і засновані на взаємодії з програмним забезпеченням).

М’які навички дуже важливі для будь-якого тестувальника, який себе поважає. Адже QA-інженери повинні не просто писати якісні звіти, але й структурувати напівемпіричні результати, вміти детально описувати передумови та наслідки багів!

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

Любов до програмування набагато сильніша, ніж до тестування

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

Професійна деформація свідомості

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

Причини, чому не варто наймати QA-інженера

Їх не так багато, але ми можемо виділити принаймні дві:

1. Ніхто не знає програмне забезпечення краще за того, хто його створив. Адже саме програміст знає всі сильні та слабкі сторони продукту.
2. Розробник може створювати якісні тести, але тільки якщо він впевнений, що цю роботу оцінять, оплатять належним чином і не будуть сильно сварити за кількість пропущених багів.

Короткий висновок

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