Меню

Практичне тестування програмного забезпечення для контролю якості потоку (вимоги до випуску)

practical software testing qa process flow

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

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

Примітка. Ми повторно публікуємо цей корисний допис із оновленим вмістом.

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

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

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

Вимоги до звільнення

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

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

Вимога до випуску - повний огляд

Життєвий цикл тестування програмного забезпечення

Прямо від вимоги до звільнення кожен етап пояснюється чітко. Давайте розглянемо їх детально.

# 1) Вимога

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

як запустити торрентований файл -

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

Виклики

Не можна уявити всі вимоги, щоб зібратися за одне засідання. Наберіться терпіння.

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

На малюнку нижче висвітлено найважливіші кроки, пов'язані зі збором вимог:

Вимоги LifeCycle

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

Кращі практики

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

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

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

# 2) Тестова стратегія

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

Тестова стратегія

Виклики

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

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

Кращі практики

  • Ось декілька найкращих практик, які в подальшому можуть забезпечити вам велике полегшення та забезпечити плавне тестування.
  • Ще раз перегляньте документ вимог. Виділіть точки імпорту щодо середовища цільового програмного забезпечення.
  • Складіть список середовищ, де програмне забезпечення буде фактично розгорнуто.
  • Середовища можна розуміти як тип операційних систем або мобільних пристроїв.
  • Якщо операційною системою є Windows, перелічіть усі версії вікна, де ви будете тестувати своє програмне забезпечення. Якщо версії віз. Windows 7, Windows 10 або Windows Server (s) досі не визначені в документі вимог, тоді саме час їх обговорити.
  • Аналогічно, отримайте цільові браузери з обговореними та задокументованими версіями, якщо AUT - це веб-система.
  • Складіть список усього стороннього програмного забезпечення, яке знадобиться додатку (якщо потрібно / підтримується). Сюди можуть входити Adobe Acrobat, Microsoft Office, будь-які доповнення тощо.

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

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

Стратегія тестування

# 3) Планування випробувань

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

Як і стратегія тестування, планування тестів також є вирішальним етапом.

План випробувань

Виклики

Оскільки успіх (або невдача) AUT багато в чому залежить від того, як проводились тести, цей етап стає важливим аспектом усього життєвого циклу тесту. Чому? Тому що на цьому етапі визначена частина тестування.

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

Кращі практики

  • Завжди майте на увазі, щоб не залишати каміння на камені, коли справа доходить до тестування вашої заявки.
  • Пора сформулювати тестову стратегію.
  • Створіть матрицю середовища, щоб програмне забезпечення тестувалось на всіх платформах.
  • Наприклад, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Як і браузер Chrome 4.2.2+.
  • Якщо ваш додаток працює з кількома базами даних (якщо це задокументовано), зберігайте бази даних (MySQL, Oracle, SQLServer) у тестовій матриці таким чином, щоб вони були занадто інтегровані з деякими тестами.
  • Відповідно налаштуйте тестові машини та назвіть їх SetUp1, SetUp2 тощо.
  • SetUp1 матиме Windows 7+ IE 10+ Office 2007+.
  • SetUp2 може мати Windows 10+ IE Edge + Office 2013+.
  • На SetUp3 може бути телефон Android з інстальованим файлом .apk.
  • Вітаємо! Ваше тестове налаштування готове, і ви також включили всі можливі комбінації платформ, на яких буде працювати ваша програма.

# 4) Тестування

Пошук помилок

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

Нижче на схемі зображена класифікація різних типів тестування:

Види тестування

Виклики

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

Кращі практики

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

  • Завжди доцільно дивитись на заявку зі свіжим виглядом, БЕЗ ПЕРЕВІРКИ ВИПРОБУВАНЬ.
  • Дотримуйтесь навігаційного шляху вашого програмного забезпечення (AUT).
  • Ознайомтесь з AUT.
  • Тепер прочитайте тестові приклади (Усі) будь-якого конкретного модуля (можливо, на ваш вибір).
  • Тепер перейдіть до AUT і порівняйте висновки з тими, що згадані в очікуваному розділі тестових випадків.
  • Ідея цього полягає в тестуванні кожної згаданої функції на кожній підтримуваній платформі.
  • Запишіть кожне відхилення, наскільки б воно не було тривіальним.
  • Запишіть кроки того, як досягти будь-якого відхилення, зробіть знімки екрана, зафіксуйте журнали помилок, журнали сервера та будь-яку іншу допоміжну документацію, яка може довести наявність дефектів.
  • Не соромтеся запитувати. Хоча у вас є документ з вимогами, бувають випадки, коли ви будете сумніватися.
  • Зверніться до розробників (якщо вони сидять поруч з вами або їх можна досягти) з сумнівом, перш ніж звернутися до власника продукту. Зрозумійте думку розробника щодо роботи програмного забезпечення. Зрозумійте їх. Якщо ви вважаєте, що ця реалізація не відповідає вимогам, повідомте про це менеджеру тесту.

# 5) Перед звільненням

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

Виклики

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

Параметри можуть бути не обмежені:

  • Функціональність / Поведінка.
  • Продуктивність.
  • Масштабованість.
  • Сумісний із зазначеними платформами.

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

Кращі практики

  • Переконайтеся, що всі функції на всіх платформах перевірені.
  • Виділіть ті області, які не тестуються, або ту, яка потребує більших зусиль для тестування.
  • Зберігайте матрицю всіх результатів тесту перед випуском. Тестова матриця дасть загальну картину стабільності продукту. Це також допоможе керівництву зателефонувати за датами випуску.
  • Надайте команді свої вказівки / пропозиції щодо вашого досвіду під час тестування продукту.
  • Ваш внесок, який вважає вас кінцевим користувачем, у цілому виграє від програмного забезпечення.
  • Через обмеження часу або будь-яку іншу подібну ситуацію ми або пропускаємо тестування, або не заглиблюємось у це. Не соромтеся повідомити про стан тестування своєму менеджеру.
  • Представити зацікавленим сторонам медичну карту заявки. Картки охорони здоров'я повинні мати ряд усіх зареєстрованих, відкритих, закритих, періодичних дефектів з їх тяжкістю та пріоритетністю.
  • Складіть документ про випуск і поділіться цим з усією командою.
  • Підготовлена ​​робота над документом про випуск.
  • Поліпшити напрямки, запропоновані керівництвом / командою.

На малюнку нижче показано карту життєвого циклу випуску програмного забезпечення:

Перед звільненням

# 6) Випуск

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

Виклики

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

Кращі практики

  • Завжди пам’ятайте, ви не працюєте над документом про випуск на дату АКТУАЛЬНОГО ВИПУСКУ.
  • Завжди плануйте діяльність із випуску до фактичної дати випуску.
  • Стандартизуйте документ відповідно до політики компанії.
  • Ваш документ про випуск повинен намагатися встановити позитивні очікування від програмного забезпечення.
  • У документі чітко згадайте всі вимоги до програмного та апаратного забезпечення, що стосуються їх версій.
  • Включіть усі відкриті дефекти та їх тяжкість.
  • Не ховайте значні зони ураження через відкриті дефекти. Дайте їм місце в документі про звільнення.
  • Перегляньте документ і підпишіть його цифровим підписом (може відрізнятися відповідно до політики компанії).
  • Будьте впевнені в собі і надішліть документ про випуск разом із програмним забезпеченням.

Процес перевірки якості на реальному проекті - метод водоспаду

Я отримав цікаве запитання від читача, Як проводиться тестування в компанії, тобто в практичному середовищі?

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

Тут я зупинився на фактичному робочому процесі Тестування програмного забезпечення в компаніях .

Фактичний процес тестування в компаніях

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

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

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

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

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

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

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

Кроки у вимогах до звільнення

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

# 1) Огляд ЄСВ : Огляд специфікацій вимог до програмного забезпечення.

# 2) Цілі встановлені для основних випусків.

# 3) Цільова дата заплановано на випуски.

# 4) Детальний план проекту будується. Сюди входить рішення щодо проектних специфікацій.

# 5) Розробіть план тестування базується на технічних специфікаціях.

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

# 7) Тестові характеристики: Цей документ включає технічні деталі (вимоги до програмного забезпечення), необхідні перед тестуванням.

# 8) Написання тестових кейсів

# 9) Розробка: Модулі розробляються один за одним.

# 10) Прив'язка установників: Інсталятори будуються навколо окремого продукту.

як відкрити файл .dat

# одинадцять) Процедура побудови : Збірка включає установників доступних продуктів - кілька платформ.

# 12) Тестування: Тест на дим (BVT): Основний тест на застосування для прийняття рішення щодо подальшого тестування.

  • Тестування нових функцій
  • Крос-браузер та міжплатформене тестування
  • Стрес-тестування та тестування витоків пам'яті.

# 13) Підсумковий звіт про випробування

# 14) Заморожування коду

  • На даний момент більше не додаються нові функції.

# 15) Тестування: Тестування складання та регресії.

# 16) Рішення про випуск продукту.

# 17) Сценарій після випуску для подальших цілей.

Це було підсумок фактичного процесу тестування в середовищі компанії.

Висновок

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

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

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

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

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

^