Програмного забезпечення стає дедалі більше, і звісно ж, кожній команді розробки потрібні люди, здатні перевірити його якість. У цій статті Senior QA Engineer із SoftServe Сергій Христич розповість, хто такі тестувальники, чим вони займаються у процесі розробки ПЗ та які кар’єрні перспективи існують для QA Engineer.

Зміст:

• У чому відмінність тестувальника і QA Engineer
• Яка роль і місце QA Engineer в процесі розробки ПЗ
• Коли починати тестування, і коли воно закінчується
• Важливі якості для QA Engineer
• Кар’єрні перспективи для QA Engineer

Що таке “якісний продукт”?

Якість для ІТ-продукту — це дещо специфічне поняття, яке визначається кінцевим користувачем (не інженером, не маркетингом і не менеджментом).Тестування є одним зі способів забезпечити цю якість.

Якісний програмний продукт — це продукт, який:

1. Потрібний користувачеві.
2. Є зручним у використанні з точки зору кінцевого користувача.

Що означає “продукт, потрібний користувачеві”? Будь-який програмний продукт, який випускається у користування, має задовольняти певну потребу користувача. Наприклад:

• Прослухати музику.
• Проїхати з точки А в точку В.
• Зробити переказ грошей зі своєї банківської картки.
• Придбати товар в інтернет-магазині та багато-багато іншого.

Продукт, який гарно працює — це продукт, який відповідає очікуванням і прагненням користувача.

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

Quality Control Engineer vs Quality Assurance Engineer

Говорячи про тестувальників, Quality Control Engineer, Quality Assurance Engineer, слід зазначити, що часто у джерелах відбувається змішування цих понять.

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

Тестування —  це найпростіший рівень процесу забезпечення якості. Воно охоплює таку діяльність:

• Написання тест-кейсів.
• Виконання тест-кейсів.
• Якщо тест виконаний успішно — відмічаємо його, як пройдений (все ОК).
• Якщо тест-кейс не пройдений, тоді ми сповіщаємо про дефекти.
• Після виправлення дефектів проводимо повторне (перевіркове) тестування для того, щоб упевнитися, що дефект дійсно виправлений.
• Потім робимо звіт за результатами тестування.

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

Quality Control — це ширша діяльність, спрямована на досягнення належної якості продукту. Quality Control Engineer вже може вносити пропозиції з покращення ПЗ. Наприклад, якщо є відгуки користувачів, або якщо в процесі виконання тестів Quality Control Engineer помічає, що щось могло б працювати краще.

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

Тобто, підсумовуючи сказане:

• Тестувальник виконує тести.
• Quality Assurance забезпечує в цілому якість продукту від самих початкових етапів його створення.

Слід також знати, що у стандарті ISO немає такого поняття, як “тестування”. В ньому зазначено лише, що є Quality Assurance та Quality Control. Тобто, контроль якості та тестування у цьому стандарті поєднані в одне, але по факту існує саме такий розподіл, що зображений на схемі, наведеній нижче.

Курс за темою: QA з нуля

Місце і роль QA у процесі розробки

Є багато моделей розробки програмного забезпечення. В процесі навчання ви почуєте такі назви, як Waterfall, V-model, ітеративна модель, Agile (та його підвиди Kanban і Scrum). Але сутність усіх циклів розробки одна:

• Спочатку відбувається планування — етап, де треба визначити, який функціонал буде реалізований, як він буде реалізований, які ресурси для цього необхідні.
• Етап визначення — збираємо вимоги для функціонала та детально їх проробляємо. Наприклад, які розділи та кнопки повинні бути на екрані, які дії може виконати користувач, знаходячись на цьому екрані.
• Дизайн — етап, на якому проробляється графічний інтерфейс і технічний (внутрішній) дизайн — тобто те, що відбувається під капотом програми.
• Побудова — написання коду.
• Тестування — перевірка коректності роботи ПЗ.
• Розгортання — переміщення написаного коду в середовище продакшену, тобто туди, де його будуть експлуатувати кінцеві користувачі.

Які дії виконує Quality Assurance Engineer?

Quality Assurance Engineer бере участь в усіх етапах циклу розробки програмного забезпечення.

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

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

На етапі дизайну QA Engineer співпрацює із дизайнером для того, щоб переконатися у зрозумілості та інтуїтивності інтерфейсу. Враховується досвід користувача (як він звик діяти у програмах з аналогічним функціоналом).

Поки йде побудова, тобто написання програмного коду програмістами, QA Engineer також не гає часу і зі свого боку проробляє можливі сценарії використання програми. Він описує покрокові дії користувача: що він буде робити від моменту відкриття програми і до моменту, коли досягне кінцевої мети, для якої відкрив програму.

Наприклад, якщо це банківський додаток:

• Відкрити.
• Залогінитись.
• Вибрати свою картку.
• Подивитися залишок грошей на картці.
• Ввести картку отримувача.
• Ввести підтвердження переведення грошей.

Результати дій користувача можуть бути різними:

• У користувача достатньо грошей і результатом транзакції буде підтвердження успішної операції.
• У користувача може бути недостатньо грошей, тоді користувач може повернутися до поля введення суми, або відмовитися від цього.

Тобто QA Engineer проробляє усі можливі сценарії та на їх основі пише тест-кейси.

На етапі тестування QA Engineer виконує написані тест-кейси. Якщо на проекті є автоматизація, то пишуться автоматизовані тести (ще одна програма, яка буде виконувати дії користувача, які ми прописали у тестових сценаріях).

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

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

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

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

Коли починати тестування, і коли воно закінчується

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

Якщо дефекти виявлені на етапі збирання вимог (ми виявили, що якась одна вимога суперечить іншій) — на цьому етапі виправлення є найпростішим, тому що треба лише переписати вимогу.

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

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

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

Найдорожчими є дефекти, виявлені на етапі використання ПЗ кінцевим користувачем.

Тому відповідаючи на запитання “коли починати тестування?”, скажу: якомога раніше. Як тільки це стає можливим. Тобто, якщо у нас є хоча б якісь документально оформлені вимоги — вже можна починати тестування на цьому проекті.

Якості, які є must have для QA Еngineer

У всіх якостей, про які я розповім, є одна спільна риса — їх можна набувати та розвивати.

• Спостережливість. QA Engineer має бути уважним і помічати будь-які невідповідності.
• Вміння слухати. Важливо вміти вислухати протилежну сторону і дійти до якоїсь згоди.
• Бажання постійно вчитися. ІТ — дуже динамічна сфера, тут постійно з’являються нові технології, а також нові методи та інструменти тестування.
• Орієнтація на користувача. QA Engineer має мислити як кінцевий користувач, щоб належним чином розробити сценарій використання ПЗ.
• Володіння критичним мисленням. QA Engineer не має сприймати все на віру. Коли програміст, який не хоче виправляти дефект, починає переконувати, що “воно і так буде нормально працювати”, — важливо вмикати критика.
• Оптимізм, звісно. Потрібно вірити в те, що програмне забезпечення буде написано належним чином і що воно буде робитиме саме те, що треба кінцевому користувачу.
• QA Engineer завжди повинен мати власну думку. І крім того, вміти її відстоювати.
• Також допоможе нестандартне мислення. Так QA зможе подати більше оригінальних ідей для покращення ПЗ, вигадати більше сценаріїв використання програми.
• Потрібно володіти тайм-менеджментом, оскільки мета будь-якої команди, будь-якого проекту — випустити ПЗ швидко та у гарній якості. Якщо при плануванні на написання коду, як правило, закладається достатньо часу, то на тестування може взагалі не закладатися часу, або закладатися менше, ніж його потрібно. Це сувора реальність QA Engineer’а: майже завжди доводиться працювати в умовах обмеженого часу, отже треба дуже гарно вміти планувати свою діяльність.

Ріст і кар’єрні перспективи для QA Engineer

Окей, ви прийшли в компанію, опанували всі можливості тестування, що ж може бути далі?

QA Engineer може розвиватися в адміністративному, або в технічному напрямку.

Якщо це адміністративний напрямок, то це різні види менеджерів — це Team Lead, QA Lead, Test Lead і так далі. QA Engineer також може піти у бізнес-аналітики, оскільки хто, як не він, має досвід із роботи з вимогами до продукту, їх систематизації та перевірки.

Якщо QA Engineer хоче розвиватися в технічному напрямку, то він може перекваліфікуватися у розробники, оскільки QA Engineer часто має справу з програмним кодом. Інколи навіть вміє його читати (не на рівні розробника, але все одно може зрозуміти його). Якщо ж QA Engineer пише автотести — він вже наполовину програміст.

Також це можуть бути спеціалізовані напрямки. Один із них — автотести, створення програм для перевірки сценаріїв. Є ще нішеве тестування:

• Performance-тестування — перевірка наскільки швидко здатна працювати програма під навантаженням.
• Security-тестування — тестування безпеки ПЗ (наскільки воно захищене від зломів і хакерських атак).
• Usability-тестування — тестування програми на предмет зручності та зрозумілості у використанні.