Меню

Як провести тестування програмного продукту - детальний процес та методи з прикладами

how perform software product testing detailed process

Спробуйте Наш Інструмент Для Усунення Проблем

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

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

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

Як тестувати товар

Що ви дізнаєтесь:

Проблеми розробки програмного продукту:

Ось деякі проблеми, з якими стикаються команди розробників програмних продуктів:

# 1)Відсутність контролю над демографічними показниками користувачів, пристроями, середовищами, платформами тощо. : Програмні продукти, на відміну від програмного забезпечення, розробленого для конкретних зацікавлених сторін, не використовуються в контрольованих та передбачуваних ситуаціях. Існує багато занадто багатьох факторів, щоб взяти їх до уваги.

# два)Туманне бачення продукту : Поведінка та особливості товару назавжди змінюються, і шлях до зрілості не видно чітко. Або продукт росте занадто швидко, що виходить з-під контролю, і команди не знають, що відбувається.

# 3)Агресивні терміни : Через сильну конкуренцію на ринку програмних продуктів речі повинні рухатися з шаленою швидкістю, і команди повинні бути на крок попереду своїх однолітків. В іншому випадку вони напевно програють конкурентам.

# 4)Страх невдачі : Програмні продукти, як правило, інноваційні. Отже, їхній успіх не завжди є даним. Це є причиною того, що компанії не можуть вийти з точки зору бюджету, технологій, інфраструктури тощо. Їм часто доводиться стримуватись, щоб отримати певний імунітет від невдач або навіть беззбитковості.

# 5)Відсутність активних відгуків: Оскільки немає зацікавлених сторін, бізнес-користувачів чи клієнтів, так би мовити, важко зрозуміти, що може сподобатися кінцевому користувачеві, а що не. Компанії постійно грають у відгадування і часто мають труднощі з подоланням розриву між тим, що вони хочуть для програмного забезпечення, і тим, що хоче замовник.

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

Щоб просунутися в грі, цей тип тестування повинен враховувати п’ять ключових моментів:

  • Швидкість розробки та випусків
  • Короткострокові та довгострокові цілі продукту
  • Обсяг і характер конкуренції
  • Цільові аудиторії та їх середовища
  • Вимоги - Функціональність, продуктивність, безпека, зручність використання, конфігурація тощо.

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

життєвий цикл товару

Хороша стратегія / підхід до тестування продукту повинна враховувати поточну стадію продукту в його життєвому циклі.

Також читайте => Як написати хороший документ про стратегію тестування

Приклад: Продукт компанії XYZ - це програмне забезпечення для відстеження дефектів під назвою „TrackFast“. Це новий продукт, і перша версія має бути запущена як хмарне та локальне рішення. TrackFast працює як будь-яка інша система управління дефектами і створена як для мобільного, так і для веб-доступу. В даний час існує 2 - 4-тижневі спринти, на яких продукт створюється частинами. Ви берете участь у тестовій групі, яка тестує «TrackFast», перш ніж вона зустріне своїх клієнтів. Тестування передбачає перевірку функціональності, продуктивності та безпеки.

java передає масив методу за значенням

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

параметри

Давайте подивимось, як тестувати на кожному етапі. Це є тест продукту процес, метод або життєвий цикл на кожному етапі.

Етап №1) Введення продукту

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

Хороша стратегія тестування на цей момент повинна включати наступне:

  • Тести, що підтверджують короткострокові цілі TrackFast. “Що потрібно для правильної доставки” повинно бути на першому плані тестування. Створити Наскрізні тести (інтерфейс, проміжне програмне забезпечення та серверне середовище) для ретельного тестування кожної функції
  • Тести, які порівнюють TrackFast із конкурентами (в ідеалі це робота власників продуктів, але як тестер ми можемо додати наші два центи. Крім того, цей крок простіший, якщо програмне забезпечення вже має кілька однолітків. Наприклад: Порівняти TrackFast легко з Bugzilla або JIRA або інші застарілі системи . Але скажімо, я створюю додаток, який робить щось незвичне, наприклад, можливість передбачити, коли дитина голодна або вередує :), можливо, важко знайти програму, яку можна використовувати як базову лінію)
  • Платформа, браузер та пристрій тести сумісності
  • Тести на простоту установки , налаштування та налагодження швидкості
  • Тести на продуктивність, безпеку та зручність використання
  • Інтеграційні тести якщо він взаємодіє з іншими системами. Простим прикладом інтеграції є те, що системи відстеження дефектів часто взаємодіють із поштовими клієнтами для надсилання сповіщень
  • План регресії - Це гарна ідея позначити або позначити критичні тести, які, на вашу думку, будуть частиною майбутніх циклів регресії, і подумати про автоматизацію їх для майбутніх випусків
  • План відомих проблем (Ви збираєтеся додавати їх до відставання або обробляти їх як CR тощо)
  • Гнучкість для зміни, коли продукт переходить до наступного етапу життєвого циклу.

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

На цьому етапі, хоча є частина продукту, готова після закінчення 2-4 тижневих спринтів, найчастіше кожен спринт не призводить до отримання коду. Тому ніколи не вважайте останнє тестування спринтом 'готовим і доставленим'. Повторюйте критичні тести з кожним спринтом до випуску. З кожним спринтом перевіряйте весь товар, який у вас є, до цього моменту.

Етап №2) Зростання продукту

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

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

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

Вони можуть допомогти:

  • Майте на увазі довгострокові цілі проекту. Йдеться не про те, щоб зараз закінчити. Йдеться про життя з особливостями та процвітання з ними.
  • Тест достроково Розглянемо TDD або BDD замість того, щоб відкласти тестування до кінця новими вимогами
  • Автоматизуйте регресію та зміцніть її - Створіть автоматичний набір регресій на місці, щоб у вашій системі не залишилися неперевірені наземні міни
  • Якщо власники вашого бізнесу / продукту хочуть взяти участь у тестуванні, розгляньте інструмент автоматизації на основі ділової мови, такий як Огірок.
  • Зберігайте зручність використання і дизайн веб-сайту, який є центральним для вашого тестування. Оскільки чим більше функцій ми додаємо, тим чистішим повинен бути сайт
  • Виконуйте тестування продуктивності та безпеки, коли відбувся великий випуск або коли в архітектурі відбулися суттєві зміни. (Запроваджено новий сервер тощо). Більшість програмних систем цього не потребують з кожним випуском.
  • Підтримуйте зв’язок з конкурентами та знайте бачення продукту
  • Адаптуйте тестування пар , для негайного зворотного зв’язку та виправлення. Включіть власника продукту, коли це можливо
  • План змін та відомих проблем
  • Спробуйте отримати відгуки клієнтів і перевірити, чи можна їх відстежувати як пропозицію щодо вдосконалення, щоб зберегти ріст постійним. (ще раз, це не головна відповідальність команди контролю якості, але всі враховують)

Етап No 3) Зрілість товару

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

Отже, команда тестування може:

  • Попрацюйте над дозріванням вашої стратегії тестування. До цього моменту ваші регресійні набори, методи проектування тестів та практики управління тестами повинні працювати як добре змащені машини.
  • Зосередьтеся на більш дрібних деталях. Оскільки в цілому продукт працює і працює добре, але, як кажуть - Бог у подробицях ' - знайти навіть найменшу з проблем, які можуть покращити якість системи
  • Розгляньте відгуки клієнтів
  • Періодично перевіряйте продуктивність та безпеку
  • Візьміть до уваги нові пристрої, платформи та браузери, які могли з’являтися на ринку з моменту останнього тестування
  • Перевірте посібник користувача та сторінки поширених запитань, оскільки зараз у вас є час і ви можете собі це дозволити.
  • Експериментуйте з новими інструментами, послугами чи процесом тестування продуктів, адже тепер ви можете.
  • Перевірте процес встановлення з кожним, хоч і невеликим, і отримайте статистичні дані про те, наскільки це просто або складно для кінцевого користувача.

Що б ви не робили, не заспокоюйтесь.

Етап №4) Зниження продукту / повернення до зростання продукту

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

код сортування міхурів c ++

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

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

Колесо зробило повний поворот, і ви ставитесь до системи як до абсолютно нової та дотримуєтесь стратегії, яку ми обговорювали у розділі Введення продукту. Тільки зараз ви більш досвідчені та знайомі з дрилем. Але пам’ятайте, що з кожним новим поворотом виникає новий виклик. Тож будьте гострими :)

Що робить вас успішним тестувальником продукції?

  • Тестери продуктів повинен мати гострий діловий сенс, розуміння моделей розвитку швидкої доставки і повинен бути тестером тузу які не бояться експериментувати з інструментами і самі стають трохи програмістами, якщо це потрібно. Ці речі можуть мати позитивний вплив на будь-який тип тестування, але вони є крайньою необхідністю у цьому типі тестування.
  • Інша важлива якість полягає в тому, що a тестувальник продукту повинен вірити у товар і щиро хочу, щоб це вдалося. Коли я, як випробувач, думаю, що програмне забезпечення - це загальне сміття, мало сподіваюся, що я щось зроблю, щоб покращити його.
  • Поділіться баченням власника товару / бізнесу . Якщо ви не знаєте, куди рухається продукт і як він буде розвиватися, тестування буде надзвичайно обмеженим.
  • Крос-функціональні навички корисні - Знати, як протестувати БД, як визначити показники продуктивності, як увімкнути сертифікати безпеки, як розгорнути тощо. Будьте цікаві та досліджуйте .
  • Не встановлюйте меж - не думайте, що оцінка посібника користувача або перевірка поширених запитань - це не ваша робота, і технічний автор повинен подбати про це. Ну, вони повинні і будуть. Але коли ви дивитесь на нього як на інсайдера, як на того, хто знає товар навиворіт, ваші відгуки надзвичайно корисні.
  • Шукати відгук кінцевого користувача. Наступний великий набір людей, які проводять тестування після вас, є користувачами реального часу. Знати і розуміти, з якими проблемами вони стикаються. Це допоможе вам вдосконалити дизайн тесту, тому наступного разу ви будете знати, що робити, щоб уникнути цих проблем.
  • Працюйте швидко і приймайте рішення
  • Уникайте технічної заборгованості . У ситуації швидкого розробки та тестування легко протестувати виключно в дослідницькому режимі та втратити систему відліку для майбутніх випусків. Не дозволяйте цьому траплятися. Ведіть скелетну документацію, щоб ви могли відстежувати, відстежувати та вимірювати

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

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

Про автора: Ця стаття опублікована членом команди STH Swati S.

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

Рекомендована література

^