Мої правила успішного тестування програмного забезпечення

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

Всім привіт! Я Юлія, Manual QA Engineer у Kiss My Apps. У компанії ми спеціалізуємось на розробці Mobile first-продуктів. Маю понад три роки досвіду в тестуванні програмного забезпечення. У цій статті я розповім про ключові аспекти успішного тестування, які справді варті вашої уваги.

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

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

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

Повнота тестування

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

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

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

Розділення обов’язків

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

Такий розподіл можна налагодити завдяки чітким описам для кожного члена команди:

  • розробники відповідають за написання модульних тестів;
  • команда аналітиків бере участь у оцінці ризиків та пріоритетів у тестуванні;
  • QA Automation Engineer розробляє, підтримує та оптимізує автоматизовані тести;
  • Manual QA Tester створює тест-кейси, проводить функціональне, нефункціональне, регресійне, кросплатформне та адхок-тестування, документує результати.

Відокремлення тестових сценаріїв

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

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

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

Структурованість тестування

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

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

Пріоритезація тестів

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

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

Ретельне планування тестування

Тестування може здаватися складним, але правильний підхід та планування — ключ до успіху. Плануйте тестування заздалегідь, враховуючи ресурси та час релізів. Це допоможе уникнути затримок та отримати справді якісний продукт. Але з чого ж починати?

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

  1. Що саме ви хочете досягти?
  2. Які аспекти продукту потребують найбільшої уваги?

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

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

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

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

Використання різних методів тестування

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

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

Врахування користувацьких потреб

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

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

Постійне вдосконалення тестування

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

Висновок

Отже, з мого досвіду — ці правила є основними під час тестування програмного забезпечення. Вони допомагають забезпечити якість, стабільність та задоволеність користувачів, що є важливими аспектами успішного релізу та підтримки програмного забезпечення. А які принципи тестування ви вважаєте ключовими? Буду рада почитати та обговорити ваші думки з цього приводу!


Рецензент статті — Геннадій Міщевський.


👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Мої правила успішного тестування програмного забезпечення

1) Почнемо з вимог (рекваирментів). Робота тестувальника починається відразу, як тільки вимоги (епіки, таски, спека) чи будь-який інший запит на роботу отримано. Перший крок — це саме тестування вимог або постановки задачі. Якщо тестувальник сам не розуміє чи не до кінця уявляє що треба зробити — як він може написати «дефінішин оф дан» (підкажіть як це українською). Отже тестувальник повинен задавати питання аж поки йому не буде цілком зрозуміло:
— Як система працює зараз, які є вимоги на цю частину, які є тест кейси які її покривають.
— Як система має працювати після імплементації змін. Чи це десь описано на 100%.
— Чи є конфлікти між новими вимогами та існуючими — що треба виправити?
2) Естімейт тестування і тест-план. Тестування — окремий процес від девелопменту. Іноді мізерні зміни можуть потребувати пере-тестувати багато чого. А іноді великий рефакторинг у коді не потребує зайвого тестування — бо усе вже покрито існуючими авто-тестами. Тестувальник має мати свій план тестування і давати свій естімейт на кожну таску.
3) Тестові данні. В ідеалі тестувальник не повинен кожен раз набивати чи змінювати тестові данні. Під кожен тест кейс у нього має бути підготовлений набір тестових даних. Це забезпечує можливість швидко зарепродюсити дефект, перевірити коли його пофіксять, додати автоматичний тест, який кожну ніч буде перевіряти що дефект не повернувся.
Отже під нову задачу тестувальник має витрати час аби налаштувати тестові данні для різних конфігурацій.
4) Тест кейси. Будуть вони автоматизовані чи мануальні — але в будь-якому випадку їх треба спочатку описати. І не забути перевірити усі можливі варіанти і конфігурації.
5) Юнит — тести. Це тести, про які тестувальники не мають нічого знати і не мають на них розраховувати. White box тестування — це робота девелоперів, тестувальник не має дивитися у код — він тестує Black Box.
Доречи юніт-тести це окрема цікава тема і дуже часто їх пишуть неправильно. Не треба плутати юніт-тести з модульними, інтеграційними, функціональними чи взагалі будь-якими авто-тестами.
6) Автоматичні тести. Зрозуміло що у сучасному ІТ нема сенсу витрачати час на мануальні тести, хіба що їх аж ніяк не можна автоматизувати (хоча з сучасним розвитком робототехніки таких стає усе менше). Але іноді виникає непорозуміння які тести пишуть девелопери, а які — тестувальники.
— End-2- End або UI тести — це емуляція поведінки користувача. Вони ж можуть бути функціональними (або «прийомочними») тестами.
— API та модульні тести. Сучасні системи часто не є монолітами, а складаються з сервісів. Отже це дає можливість окремо тестувати (і окремо використовувати) частини системи.
— Перфоманс та стрес тести. Часто це окремий процесс тестування. Але деякі перфоманс тести можуть бути частиною щоденного тестування — аби перевіряти що перфоманс не впав.
Усе перелічене — це Black Box тести і отже частина роботи тестувальників. Але я бачив підходи де між девелоперами та авто-тестувальниками не роблять різниці. Усе одно потрібно писати код: а отже девелопери можуть написати авто-тести не гірше. Єдине АЛЕ: тестувальник усе одно потрібен аби написати тест кейси, які девелопери автоматизують.
7) Як заводити баги. Про це багато написано — бо це зазвичай майже основний видимий результат роботи тестувальника. Добре описаний баг — це вже частина швидкого вирішення проблеми. Але для цього:
— Тестувальник має забезпечити тестові данні, енвайромент, детальні кроки, навіть віртуальну машину чи контейнер аби девелопер не витрачав часу аби зарепродюсити проблему.
— Тестувальник має описати (чи краще записати на відео) яку проблему він бачить, і яким саме вимогам вона протиричіть (баги типу «я думаю що це працює неправильно» — ідуть лісом).
— У багу має обов’язково описана очікувана правильна поведінка! Якщо тестувальник сам не знає як правильно — це його робота з’ясувати, уточнити вимоги чи додати нові. Наприклад: тестувальник вимкнув сітку — вилетів «ексепшин» (червона помилка якої юзери лякаються). Але що має бути замість неї? Тут є багато варіантів, деякі з яких взагалі тягнуть на окрему розробку (зробити аби усе працювало автономно).
8) Контроль якості. Саме так називається те, що має робити тестувальник на проєкті. Не просто заводити щобільше багів — а розуміти який функціонал критичний, який використовується рідко, що треба перевіряти кожного разу, що треба пере-перевірити після конкретних змін, які баги пріоритетні, які можна відкласти і пофіксити потім, які взагалі дуже рідко трапляються і не варті витраченого часу. Отже синьор тестувальник — це не просто «манкі — тостер», а людина, яка розбирається в проєкті достатньо, аби ставити питання і продакт овнеру і менеджеру.
9) Додаткові ролі. Доволі часто досвідчений тестувальник може бути ще й трошки секьюріті — експертом (і вміти робити пенетрейшин-тестінг), трошки девопсом (розгортати тест енвайроменти), трошки кастомер — сапортом (підказати юзерам як що працює), трошки UIX та юзабіліті експертом (якщо більше нема кому), трошки аксесібіліті та глобалізейшин експертом (бо це теж треба тестувати), іноді — скрам-мастером чи навіть продак-овнером (бо єдиний знає як що працює).
P.S. Навіщо це розписав? Бо дуже часто на проєктах замість «інженерів з якості» бачив саме «тостерів». Які вважають що їх робота — це не заглиблюватись у доменну галузь чи навіть функціонал системи — а просто тупо клацати-перевіряти. Відповідно якщо тестувальники не роблять свою частину роботи з якості на проєкті — то і девелопери «кладуть на совість». Не можна зарепродюсити багу? — девелопер її поверне, а потім взагалі закриють ніби вона «сама пофіксилась». Нема тест-кейсів та тестових даних? — усі будуть перевіряти тільки happy path (я сам не повірив коли побачив якого рівня компанії роблять саме так!). Незрозумілі вимоги? — девелопер зробить як йому сподобається.
У ІТ компаній з топ-10 я працював з тестувальниками зі східних країн, які писали мені в чат: «покажи як воно працює». А коли я сам показував у себе на машині — вони ставили що тестування виконали! Не диво що деякі великі компанії взагалі після цього відмовляються від тестувальників і вважають що девелопери самі краще протестять.
Зрозуміло що я можу виконати і роботу тестувальника. Але краще коли кожен спеціаліст займається своєю справою. Особливо коли це величезний проєкт і багато-річний досвід вартує більше, ніж будь які супер-скіли бути «людиною-оркестром».

Навіщо це розписав?

Гарне питання, яке залишилося без відповіді.

У ІТ компаній з топ-10 я працював з тестувальниками зі східних країн

Топ-10 чого? В сенсі фаангомайкрософти? Тоді що таке східні країни? Україна? Японія? Австралія?

Топ-10 чого? В сенсі фаангомайкрософти?

Top 10 software companies. І це не тільки FAANG, а ще й, наприклад, Salesforce та Adobe.

Тоді що таке східні країни?

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

Не треба плутати юніт-тести з модульними

А в чому різниця?

Справді хочете почитати черговий лонг-рід? Хоча здається тема про юніт-тести на ДОУ вже була і можливо я вже там про це писав.

черговий лонг-рід

Нафіга ви їх пишете? Вчіться більш виразніше і чіткіше відповідати.
Інколи буває відчуття, що на якусь дурку попав.

А іноді великий рефакторинг у коді не потребує зайвого тестування — бо усе вже покрито існуючими авто-тестами.

І тут Бобер прокинувся і зрозумів, що труси треба прати.

Навіть у вільний час доводиться в develop team

Підкажіть будь ласка, що то за тулза з частини «Використання різних методів тестування» де автор вибирає IP Geolocation

Підписатись на коментарі