Мануальне тестування померло?

ЧИ РУЧНЕ ТЕСТУВАННЯ ПОМЕРЛО, АБО:

1. ЧИ ДОСТАТНЬО АВТОМАТИЗОВАНОГО ТЕСТУВАННЯ ДЛЯ ВАШИХ ПОТРЕБ У ТЕСТУВАННІ?

2. ЧИ МОЖЕ QA-ІНЖЕНЕР РОБИТИ ЩОСЬ ЩЕ, ОКРІМ НАПИСАННЯ СКРИПТІВ АВТОМАТИЗАЦІЇ?

Спочатку розберімося, що ми можемо зробити, щоб отримувати та підтримувати якісні програмні продукти?

У мене є приказка. Ми не просто проводимо бездумне тестування. Моя мета для моєї команди QA — стати силою, що зв’язує, рушійним вектором, який штовхає якість продукту вперед, ставши клеєм між командою розробників (front-end/back-end), DevOps, управлінням проєктами, власниками продукту та стейкхолдерами.

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

Але що ми маємо на увазі, коли говоримо про QA, QC та тестування програмного забезпечення? Що ж, розберімося.

QUALITY ASSURANCE

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

QUALITY CONTROL

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

SOFTWARE TESTING

• Підмножина QC
• Орієнтоване на продукт
• Перевірка продукту на відповідність специфікаціям
• Зосереджене на фактичному тестуванні продукту
• Знаходження і виправлення дефектів
• Реактивний процес

І далі, які обов’язки інженера із забезпечення якості? Ну, це те, що ви бачите вище!

Тепер подумаймо про автоматизацію. Чи все можна автоматизувати з усіх аспектів відповідальности, які ми визначили вище? Звісно, можна! Я б також сказав, що тільки останню частину, в списку software testing.

Перевірка продукту на відповідність специфікаціям. Це чудово — ми можемо автоматизувати функціонал продукту!

Але зачекайте — що станеться, якщо скрипт автоматизації знайде помилку — чи є це помилкою? Про цю помилку вже повідомлялося? Які наслідки цього дефекту? Наскільки критична ця помилка? Чи існує ця функція вже у виробництві? Чи потрібно робити виправлення? Обговоріть це з менеджером проєкту та власником продукту.

І це ще до того, як баг буде виправлено…

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

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

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

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

Це підводить нас до іншої частини обов’язків QA-інженера — визначення того, з якими браузерами та операційними системами повинен працювати продукт.

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

ЧОМУ НАМ ВСЕ ЩЕ ПОТРІБНЕ РУЧНЕ ТЕСТУВАННЯ У СВІТІ, ДЕ ВСЕ КЕРУЄТЬСЯ ШТУЧНИМ ІНТЕЛЕКТОМ? НА ДВОРІ 2023 РІК!

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

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

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

ВАРТІСТЬ ВИЯВЛЕННЯ ДЕФЕКТУ

• ВИМОГИ / АРХІТЕКТУРА: 1x
• КОДУВАННЯ / РЕАЛІЗАЦІЯ: 6.5x
• ІНТЕГРАЦІЯ / ТЕСТУВАННЯ КОМПОНЕНТІВ: 15x
• ПРОДАКШН / ПОСТ-РЕЛІЗ: 100x

Рухаємося далі.

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

Це неправдиве твердження!

Хороший QA-інженер — це той, хто переконується, що “необхідні помилки, які потрібно виправити”, виправлені до того, як ми відправимо нову функцію у виробництво. Іноді власник продукту або менеджер проєкту не до кінця розуміє тікет, і він потрапляє в беклог. В результаті, він призначається для виправлення в далекому спринті — замість того, щоб бути вирішеним перед випуском продукту.

ЦІЛІСНИЙ ПІДХІД

Хороший QA-інженер в команді SDLC буде використовувати “цілісний підхід”; з часом він буде розуміти більше про проєкт. Що станеться з іншою стороною проєкту, якщо ви “посадите” нову функцію прямо посеред нього? Але що це означає?

ГАРАЗД, ПОЇХАЛИ:

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

При такому “цілісному підході” команда QA враховує всі знання про проєкт, коли інтегруються нові функції. Приблизно так, як у нас була Піфія з “Матриці”? Роль інженера з контролю якості відіграватиме важливу роль, коли йому потрібно буде з’ясувати, як ця нова функція буде інтегрована в теперішній продукт — з чинними ролями користувачів і функціональністю — будь то веб, мобільний або бекенд.

Однак після того, як функція ретельно протестована, а необхідні помилки, які потрібно виправити, усунуті, настає час для того, щоб розробити оптимальну схему роботи функції та автоматизувати її. Ви не хочете повторно запускати один і той самий тест на всіх версіях iOS або Android. Або на всіх версіях десктопних браузерів / ОС. Саме тут вступають в дію блиск і сила автоматизації. Знайдіть повторюваний процес і автоматизуйте його до біса.

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

ЩО РОБИТЬ QA ІНЖЕНЕР НА ПРОЄКТІ?

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

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

Наприклад, для програмного продукту може знадобитися провести кілька тестів на iOS 13, iOS 14, iOS 15 і в декількох браузерах, таких як Safari, Chrome, Edge і Firefox. Тестування вручну зайняло б значну кількість часу, що є неможливим з огляду на часові рамки проєкту. У такому випадку, ви вирішили автоматизувати процес.

Як automation QA, ви здебільшого пишете тестові скрипти, повідомляєте про помилки, запускаєте тести та коригуєте тестові скрипти відповідно до потреб/вимог. Все, що не піддається автоматизації, надсилається на ручне тестування, яке виконується вручну. Припустимо, що automation QA виявлять проблему під час автоматизованого запуску. У такому випадку вони повідомляють про це ручному контролю якості, щоб той міг дослідити проблему, відтворити її та створити тікет, якщо це баг.

РОЗГЛЯНЬМО ЦЕ НА ПРИКЛАДІ РЕАЛЬНОГО ПРОЄКТУ

Контекст: Платформа, яка дозволяє пацієнтам створювати свої профілі та передавати їх до системи охорони здоров’я. Платформа містить додаток, який надає користувачам онлайн-форми для заповнення вручну. Після заповнення кожного поля додаток автоматично генерує pdf-файл і код, унікальний для кожного файлу, який потім надсилається до відповідних органів влади.

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

Цей проєкт використовує ручне та автоматизоване тестування для забезпечення якості продукту. Проте ручне тестування виявилося більш ефективним у виявленні помилок. Ви запитаєте, чому? Дозвольте мені пояснити.

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

ПРИКЛАДИ БАГІВ

Одне з полів у файлі .pdf має лише вісім комірок, тоді як у формі можна ввести вісім або дев’ять символів. Кроки для відтворення цієї помилки наступні: тестувальник відкриває сторінку, заповнює поле дев’ятьма символами, а потім переходить до генерації PDF-файлу. Як і очікувалося, оскільки доступно лише вісім комірок, цифри не заповнюють комірки відповідним чином — вони виглядають переповненими, щоб більший рядок все ще міг вмістити текст.

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

ВИСНОВОК

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

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

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

Джерело: BQA (оригінал допису)

Перекладено та адаптовано на основі оригіналу: редакція