Як мануальному тестувальнику уникнути рутинності та зберегти ефективність в роботі

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт усім вигорілим та не дуже!

Мене звати Галина Захарова, і я працюю Middle QA Engineer у ІТ-компанії Customertimes. Ви вже могли читати мої статті на DOU про те, як я шукала роботу в ІТ, як пройшов мій перший рік в ІТ та техніки тест-дизайну для «чайників». Настав час поговорити про рутину!

Впевнена, всі знайомі з робочою рутиною, яким би цікавим проєкт не був. У вас немає сил, ви втомлені, фокус уваги постійно перемикається, мозок кричить «нумо дивитись YouTube», а сповіщення з Instagram так і манять, як сирени: «Відкрий мене, залипни в мене!». Ефективність роботи, звісно, падає і падає. Бувало у вас таке? Але ця рутинна яма до добра не доведе, бо не за горами і вигорання.

Мій YouTube: www.youtube.com/@qaquest_HalynaZakharova

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

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

Створення зрозумілих тест-кейсів

Що складного у написанні тест-кейсу? Врахування всіх деталей і особливо такої деталі, як те, що тест-кейс має бути максимально простим і зрозумілим для людини, яка тільки прийшла на проєкт або для вас самих, коли ви півроку не будете тестувати той функціонал і щось забудете. Якщо ви пишете в тест-кейсі в передумові «Упевніться, що модуль „Іграшки“ доданий на сторінку» — це погано. Треба написати ще й те, як додати той модуль на сторінку, якщо його все ж таки немає там (підійде не для всіх проєктів, але мій, наприклад, на Salesforce, дозволяє це робити).

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

Чітко визначте очікувані результати для кожного етапу тестування.

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

Систематизація тест-кейсів

Треба систематизувати тест-кейси так, щоб їх легко було знайти. Можна їх згрупувати за версіями та за приладами, на яких відбувається тестування (Web, iPad, iPhone наприклад). Уявімо, що я тестую інстаграм, і він ще, як мала дитина, вміє мінімальний мінімум. У першій версії перевіряємо на різних пристроях створення акаунта та його налаштування. У другій версії — створення постів та сторіз. Це буде виглядати так:

Ліворуч можна побачити, як все систематизовано:

Або ж використовуйте категорії / мітки для тест-кейсів у тест-менеджері. Наприклад, «Регресія», «Сумісність», «Інтерфейс». Така систематизація полегшує пошук і фільтрацію тест-кейсів, що може бути корисним під час планування тестування.

Використовуйте інструменти для управління тестовими сценаріями

Не на всіх проєктах пишуть тест-кейси чи пишуть їх у Exel, але є інструменти значно ефективніші за таблички. Наприклад, ріднесенький український Testomat.io чи іноземні TestRail, Zephyr. Ці інструменти не лише дозволяють керувати тест-кейсами, але і створюють структуру, яка полегшує організацію та пошук тестів (дивіться структуру в попередньому пункті).

Регулярні огляди та оновлення

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

Щоб не бути таким котиком, не забувайте робити все, що описано вище та буде нижче 🙂

Воскресіть у собі креативну частину

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

Розуміння користувача

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

Інтелектуальний підхід: станьте на місце користувача та подумайте над реальними потребами, це дозволить вам ставити інтелектуальні питання, спрямовані на виявлення потенційних проблем та вдосконалення користувацького досвіду.

Сценарії тестування

Креативний підхід: можна розробляти нестандартні сценаріїв тестування, які в змозі виявити проблеми, що виникають у реальних умовах використання.

Інтелектуальний підхід: аналіз сценаріїв тестування з точки зору ризиків та пріоритетів дозволяє фокусуватися на критичних аспектах продукту.

Емпатія до користувача

Креативний підхід: спробуйте відтворити ситуації, які можуть зустрітися реальним користувачам (знову уявіть, що ви — користувач), та досліджуйте, як програма веде себе в таких умовах.

Інтелектуальний підхід: займіть позицію користувача та допоможіть розробникам у розумінні причин та контексту виявлених проблем.

Взаємодія з розробниками

Креативний підхід: беріть активну участь у спільній роботі для виявлення та обговорення можливих проблем та шляхів їхніх вирішень.

Інтелектуальний підхід: будуйте конструктивний діалог, висловлення думки та ідеї для поліпшення якості продукту.

Обмін досвідом та знаннями з командою

Наприклад, у вас є проєкт з фічами з додавання товару в корзину, за реєстрацією та за підпискою на розсилку. Тестувальник-1 постійно тестує додавання товару в корзину, Тестувальник-2 — реєстрацію, Тестувальник-3 — підписку на розсилку.

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

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

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

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

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

Відстежування та аналіз результатів

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

Визначення ключових метрик

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

Якщо з іншим усе зрозуміло, то стосовно дефектів у вас можете виникнути питання «Як воно впливає на визначення рутинності?». Наприклад, якщо програма стабільна, і кількість знайдених дефектів несуттєво змінюється протягом тривалого періоду, це може означати, що тестування переважно рутинне та звичайне (око замилилося). Тому варто переглянути підходи до тестування.

Відстежування поточних результатів

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

Створення графіків та діаграм

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

Виявлення рутинних завдань

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

Креативний підхід до оптимізації

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

Колективний аналіз та обговорення

Регулярні зустрічі команди для обговорення результатів та аналізу трендів. Це дозволяє виявляти загальні висновки та шукати креативні рішення для уникнення рутинності. Одна голова добре, а декілька — краще 🙂

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

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

Мій YouTube: www.youtube.com/@qaquest_HalynaZakharova