how improve test release process
Давайте подивимось типовий процес доставки програмного забезпечення від «фази розробки» до «фази тестування» для успішний випуск програмного забезпечення без помилок для виробництва / клієнта .
Ці процеси або пропускаються, або пропускаються програмними компаніями, що призводить до поганого управління тестами і, отже, ' баггі ”Випускає програмне забезпечення для клієнта, що призводить до“ незадоволених клієнтів '.
Незважаючи на багато часу та великих зусиль приділяється командою випробувачів для кожного випуску , коли випущене програмне забезпечення не має якості, визначеної або встановленої, або не відповідає очікуваним критеріям, це не тільки вплине на репутацію компанії серед споживачів, але також демотивує та деморалізує команду проекту, головне, команду тестування в цілому .
Якщо ви є учасником групи тестування за цим сценарієм, ви можете продовжувати думати самі, 'як покращити мої можливості тестування та чи є кращий спосіб подолання цієї ситуації'.
Я хочу дати декілька порад та пропозицій, базуючись на моєму досвіді роботи з різними групами тестувань, які беруть участь у програмних додатках та випусках корпоративних продуктів з кількома доменами та платформами та з багатьма тестовими рамками, на як покращити процеси випуску тесту - , що спростить ваше професійне життя в якості інженера-випробувача або менеджера випробувань для постачання програмного забезпечення світового класу.
Що ви дізнаєтесь:
- Процес випуску тесту
- Удосконалення процесу випуску тесту:
- Управління та контроль вмісту тестового випуску
- Зразок шаблону звіту про випуск:
- Висновок:
- Рекомендована література
Процес випуску тесту
У таблиці нижче наведено огляд тестового процесу випуску з трьома універсальними фазами, такими як введення, процес та вихід.
безкоштовне програмне забезпечення для віртуалізації для Windows 10
| ВХІД | ПРОЦЕС | ВИХІД |
|---|---|---|
| 7 | Контрольний список для перегляду коду оновлений та доступний у VSS? | |
| Попередній процес Розвиток | Процес починається з • Встановлення випущеного програмного забезпечення на сервер тестування | Потреби наступного процесу • Програмне забезпечення, яке пройшло тестування на дим / осудність |
| Посилання на інформацію / документ • Документ про вимоги користувача • Технічні характеристики вимог до програмного забезпечення • План одиничних випробувань • Стандарти кодування • Контрольний список перегляду коду • План розвитку • План забезпечення якості • Розподіл завдань • Робочий пакет • Графік проекту • План проекту • План управління конфігурацією • План управління ризиками. | Підпроцеси • Підготовка тестових кейсів для всіх блоків • Розробка та модульне тестування • Опрацювання процедур невідповідності • Впровадження плану управління конфігурацією. • Впровадження плану управління ризиками • Моніторинг прогресу проекту • Виправлення помилок та огляди | Внутрішні потреби клієнта • Збірка програмного забезпечення з номером версії • Звіт про випуск • Тестові справи / Документ набору тестів • Планування виконання тестів • Матриця простежуваності • Тестові дані |
| Перевірка вхідного вводу • Проектні документи переглядаються та затверджуються? • Стандарти кодування, контрольний список для перегляду коду доступні для довідки? • Розподілене завдання та оновлений робочий пакет? • Функціональні специфікації, план розвитку та план якості переглядаються та затверджуються? • План управління ризиками передбачає пом’якшення наслідків та непередбачені ситуації для управління ризиками? • Ефективність графіку проекту для доставки товару вчасно? | Специфікація процесу • Складові модульних випробувань повинні складатися з усіх критеріїв входу та виходу • Дотримання коду стандартами кодування • NCP слід обробляти відповідно до Керівних принципів • Крок управління конфігурацією повинен відповідати Плану управління конфігурацією • Управління ризиками має відповідати Плану управління ризиками • Тестування диму проходить всі основні характеристики та функціональні можливості | Потреби зовнішніх клієнтів • Безкоштовне програмне забезпечення |
| Супровідні процеси • Людина / Обладнання / Програмне забезпечення / Розподіл ресурсів • Технічне обслуговування апаратного забезпечення • Тренінг для членів команди | Процес закінчується • Виконання перевірки диму / осудності на звільненій будівлі | Параметри ефективності • Кожна одиниця повинна пройти перший раунд тестування • Завдання, які слід виконати відповідно до Розкладу проекту • Перед випуском слід пройти тест на дим • Тестування командної пристрасті для тестування програмного забезпечення |
Кожна команда тестування повинна створити a унікальний контрольний список для випуску програмного забезпечення, відповідно до домену та платформи програмного забезпечення та методології управління проектами (наприклад, Agile Scrum тощо), а також згідно з ручним / автоматизованим тестуванням, прийняти випущену збірку перед початком виконання тесту, щоб заощадити час та зусилля.
Це один з найважливіших параметрів ефективності на фазі випробування.
Удосконалення процесу випуску тесту:
1) Перегляньте звіт про випуск для нової функціональності, налаштування / модифікації існуючої функціональності, виправлення помилок з попередньої збірки, яка вирішить почати виконувати тестування диму або тесту на розумність або їх комбінацію.
два) Перегляньте оновлення Тестування документів згідно з новою функціональністю та виправленнями помилок, якщо вони вже не оновлені. Зазвичай, протягом життєвого циклу розробки програмного забезпечення, ці документи оновлюються тестувальниками на основі регулярних щотижневих зустрічей з перегляду проектів.
3) Перегляньте Збірку програмного забезпечення у сховищі конфігурацій оновлюється для номера збірки, номера версії, маркується або коментується з назвою випуску відповідно до стандартів, визначених у проектному плані. Також переконайтеся, що збірка успішно скомпільована та встановлена на сервері тестування.
4) Заплануйте зустріч з короткого огляду проекту після випуску обговорити плюси і мінуси випущеної збірки, відомі помилки та критичну функціональність тощо, щоб уникнути будь-яких помилок та переглянути важливі вимоги клієнта. Категорично уникайте усного спілкування між командами розробників та тестувань, оскільки це сильно впливає на якість випуску програмного забезпечення.
5) Переконайтеся, що інструмент відстеження помилок налаштовано належним чином , для виділеної команди тестувальників та команди розробників проекту, номери збірки та випуску програмного забезпечення, а також модулі / функціональність програмного забезпечення, що допоможе ефективно реєструвати помилки. Якщо ні, його слід передавати керівнику проекту або керівнику випробувань з високим пріоритетом.
6) Поверніть збірку до команди розробників без будь-яких компромісів, якщо збірка не вдається виконати перевірку диму чи розумності. Строго кажучи, тестування не слід продовжувати, коли система не працює під час тестування диму. Це заощадить багато часу та сил та покращить якість програмного забезпечення, випущеного в наступних випусках.
7) Заплануйте випуск проекту на 1вулДень тижня що допоможе менеджеру тестів спланувати майбутній цикл тестування на основі стабільності збірки, а також надіслати менеджеру проекту швидкий звіт про тестування, який заздалегідь підвищить якість програмного забезпечення. Якщо команда розробників планує випуск проекту на п’ятницю, вихідні можна використовувати для будь-яких проскакувань, а також будь-яких проблем зі збіркою в ручному або автоматизованому середовищі збірки.
8) Переконайтесь, що тестувальники належним чином навчені домену що допоможе тестувальній групі дотримуватися графіка тестування та збирати час для наступного раунду тестування. Крім того, команда тестування повинна бути навчена та мати доступ до необхідних технологій, таких як сценарії та SQL, якщо проект вимагає білого боксу.
9) Уникайте розподілу тестувальників у кількох проектах оскільки це сильно впливає на якість виконання тесту в режимі реального часу. На практиці навіть досвідчені тестери не помічають особливостей та функціональних можливостей, а також пропускають тестові кейси, припускаючи, що деякі тестові кейси ніколи не дають збою, коли вони перевантажені роботою або призначені для кількох проектів із термінами.
10) Цінуйте тестувальну команду за пристрасть оскільки тестери не повинні працювати на “День” або коментувати “Називай це Днем”. Коли програмне забезпечення має декілька модулів, а функціоналіст повністю або частково інтегрований або взаємопов’язаний, тестери повинні захоплюватися написанням / виконанням тестових кейсів з великим покриттям та матрицею відстеження, орієнтуючись на якість кінцевого програмного забезпечення / продукту. Тому що навіть косметичне питання - це “помилка” і зараховується як “1 помилка”.
одинадцять) Переконайтеся, що встановлення програмного забезпечення є простим і зрозумілим оскільки це допомагає команді тестувальників перевстановити програмне забезпечення, коли це потрібно, замість того, щоб чекати, поки менеджер розробки або менеджер встановлення виконають ту саму роботу, що зайво втратить доступний час тестування. Наприклад, навіть незважаючи на те, що інсталяція на базі Windows проста, але коли вона включає кілька веб-серверів та широкосмугових мереж у багаторівневому середовищі тестування, тестерам може знадобитися кілька годин, щоб встановити програмне забезпечення. Якщо тестування програмного забезпечення та встановлення, видалення , виправлення або оновлення програмного забезпечення, швидше за все, буде детально обговорено процес виконання тестових випадків із командою тестувальників.
12) Переконайтеся, що автоматизовані інструменти доступні з ліцензією для система тестування автоматизації . Виконання тестових випадків в автоматизованій структурі легко у порівнянні зі сценарієм ручного тестування за умови, якщо автоматизовані засоби правильно налаштовані та ліцензовані для кількох користувачів. Особливо, коли план тестування включає тестування продуктивності та навантаження, крім звичайного виконання тестування та тестування регресії, тестери повинні охоплювати виконання тестових випадків у багатьох середовищах, таких як кілька серверів, декілька браузерів, декілька користувачів тощо.
13) Переконайтеся, що привидні машини налаштовані на тестування перед початком виконання тесту. Привидні машини - це машини з різним середовищем тестування. Наприклад, програмне забезпечення веб-додатків може плануватися для тестування в різних середовищах, таких як Windows 7 & Access DB або Windows 2008 & SQL Server або Windows 8 & Oracle або Mainframe & DB2 тощо, з усіма браузерами, такими як Chrome, Firefox, Internet Explorer , Safari тощо, Деякі “Тестування системи” навіть потрібно повністю відформатувати жорсткий диск і встановити нове програмне забезпечення або оновити існуюче програмне забезпечення виправленнями та оновленнями тощо.
14) Уникайте впровадження нових функцій / запиту на зміну зупинивши виконання тесту та повторно випустивши програмне забезпечення для повторної заяви про фазу тестування. Це дуже погана практика у багатьох організаціях, що займаються програмним забезпеченням, відповідно до бізнес-вимог, щоб задовольнити зовнішніх клієнтів або, принаймні, задовольнити вимоги керівного комітету управління або інколи команд продажів / маркетингу. Незважаючи на те, що запити на зміни від клієнтів завжди заохочуються в середовищі проекту «Agile», його слід належним чином спланувати та впровадити до випуску програмного забезпечення до групи тестувань.
Управління та контроль вмісту тестового випуску
Управління та контроль вмісту тестового випуску є найважливішим для будь-якого ІТ-програмного забезпечення або навіть для будь-якого програмного середовища, не пов’язаного з ІТ, що буде зображено на малюнку нижче.
- Керівники проектів та / або керівний комітет проекту залежать від повноважень організаційної матриці, відповідають за вибір вмісту для кожного випуску.
- Як тільки помилки та / або нові функції та запит на зміну від клієнтів будуть визначені та схвалені, це буде реалізоване командою розробників, яка повинна бути інформувана зацікавленими сторонами проекту до початку розробки / впровадження.
- На основі впровадженого остаточного випуску команда тестування оновить відповідні документи та відповідно підготується до тестування.
- Тестувальна група розпочне тестування на дим / розум відповідно до визначених вимог у звіті про випуск.
- Як тільки Sanity пройде, команда тестування розпочне виконання тесту відповідно до розкладу та розподілених завдань, а саме: Функціональне тестування, Нефункціональне тестування, Тестування безпеки, Тестування системи, Тестування продуктивності, Тестування навантаження, Тестування прийняття користувача тощо.
- Після завершення першого циклу тестування звіти про тестування будуть надіслані всім зацікавленим сторонам та керівнику команди розробників для планування наступної ітерації виконання тесту.
- Залежно від статусу звітів про випробування та серйозності та складності помилок, буде запланований повний цикл другого раунду тестування або регресійного тестування разом із прийнятним тестуванням користувача.
- Після завершення запланованих циклів виконання тестів звіти про тести будуть надіслані всім зацікавленим сторонам проекту щодо переданих / невдалих / пропущених функцій, функціональних можливостей та виправлень помилок.
Зразок шаблону звіту про випуск:
Примітка : Зразок шаблону MS Word для звіту про випуск також доступний для завантаження нижче.
Знайдіть нижче “ Зразок звіту про випуск ', Який охоплює основні аспекти процесу випуску, що робить професійне життя всієї команди проекту набагато щасливішим, ніж будь-коли раніше.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Сфера дії
GPS-навігація для компанії XYZ Company Limited випускається для внутрішнього тестування. Випущена версія 1.0.7, номер випуску 14.0 та номер збірки 105.25.03. Цей випуск програмного забезпечення включає нові функції та основні виправлення помилок попереднього випуску. Тестування на дим проходить з фази розробки, але перед тим, як пройти тестування на регресію, потрібен дим і осуд.
# 2) Посилання
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Опис випуску
Цей випуск є контрольованим випуском GPS-навігації і містить наступні функції та функціональність.
Функції, позначені *, є новими у цьому випуску.
Наведені нижче функції не реалізовані у цьому випуску.
1. Модуль 1
1.1 Функція 1
1.1.1 Функціональність 1
# 4) Управління конфігурацією
Ми використовуємо Visual Source Safe як інструмент управління конфігурацією. Збірка доступна за таким шляхом.
Внутрішнє посилання: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Зовнішнє посилання: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Інструкції та кроки щодо встановлення
Надайте детальну інформацію щодо встановлення збірки команді з контролю якості / тестуванню.
# 6) Виправлено помилки / помилки
Статус помилок оновлюється в системі відстеження дефектів.
# 7) Проблеми / помилки, які слід виправити
# 8) Результати
# 9) Відомі помилки / проблеми
# 10) Контрольний список випуску
| Так ні / | Опис | Так / Ні |
|---|---|---|
| 1 | Чи всі файли перевірено у Visual Source Safe? | |
| два | Чи розміщено ярлик у відповідній папці у VSS відповідно до внутрішніх стандартів? | |
| 3 | Чи можна визначити випуск як 'зовнішній' / 'внутрішній' випуск у VSS? | |
| 4 | У коментарях чи згадувалася версія у VSS? | |
| 5 | У коментарях чи згадувався короткий опис у VSS? | |
| 6 | Код переглянуто, а проблеми з переглядом коду реєструються в Clear Quest? | |
| 8 | Документ модульного тестування підготовлений та переглянутий? | |
| 9 | Виконання модульних тестових справ та оновлення результатів щодо статусу? | |
| 10 | Оновлений документ про тестовий приклад доступний у VSS? | |
| одинадцять | Усі проблеми Clear Quest для цього випуску вирішено / закрито? | |
| 12 | Усі завдання робочого пакету виконані та оновлені у VSS? | |
| 13 | Чи проведено та пройшло тестування на дим? |
=> Завантажити: Клацніть тут, щоб завантажити зразок звіту про шаблон звіту у форматі MS Word.
Висновок:
Як постійно вдосконалювати процес випуску тестів
Порада No1) Створіть інженерну команду випусків, яка подбає про найважливіші фактори підтримання випусків та збірки програмного забезпечення та відповідатиме за централізовані системи управління конфігурацією програмного забезпечення.
Порада No2) Мотивуйте та оцінюйте команди проектів за відстеження процесу, задіяного у життєвому циклі розробки програмного забезпечення, життєвому циклі розробки продуктів та життєвому циклі тестування програмного забезпечення. Ми можемо визначити процес, але до тих пір, поки його не дотримуватимуться залучені люди, немає сенсу визначати процес.
Порада No3) Оцініть зусилля на тестуванні на основі досвіду та попередньої історії. Написання тестових кейсів абсолютно відрізняється від виконання тих самих. Тестери повинні розуміти, що тестувати, як тестувати і коли тестувати, інакше зусилля, спрямовані на цикл тестування, марно витрачаються, навіть незважаючи на те, що відбулося кілька раундів тестового циклу.
Порада No4) Нарешті, якщо це можливо і можливо, автоматизуйте фазу тестування, використовуючи деякі загальновизнані засоби тестування. Використання автоматизованих інструментів побудови та засобів автоматизованого тестування зменшує зусилля на тестування більш ніж на 50%, покращуючи якість програмного забезпечення та забезпечуючи 100% якість, якщо структура автоматизації правильно розроблена.
Порада No5) І останнє, але не менш важливе: тестовий випуск - це не просто робота, це мистецтво полегшити життя всіх зацікавлених сторін у проекті легше та комфортніше.
Про автора: Балу А. - досвідчений техно-функціональний ІТ-фахівець, який має понад два десятиліття досвіду роботи з ІТ-програмним забезпеченням та десять років досвіду управління проектами та тестами, надаючи корпоративні додатки та рішення для мобільності в різних доменах за допомогою технологій Microsoft, Oracle, Java та Mobile. В основному він є лідером, який прагне сприяти тому, щоб люди ставали лідерами з правильним ставленням, любить працювати в середовищі, орієнтованому на процес, і вважає, що процес покращує ефективність, якість та продуктивність праці співробітників.
Внаступний підручник, ми дізнаємось - Як Підвищити ефективність тестових кейсів.
Повідомте нам про свої думки / запитання в коментарях нижче.
Запустіть випуск програмного забезпечення відповідно до процесу!
Повне тестування за розкладом з великою продуктивністю та зусиллями !!
Спробуйте досягти доставки програмного забезпечення із гарантованою якістю без помилок !!!
Якщо вам сподобалась ця стаття, розгляньте можливість поділитися нею з друзями!
Рекомендована література
- Курс тестування програмного забезпечення: до якого інституту тестування програмного забезпечення слід приєднатися?
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
- Тестування програмного забезпечення QA Assistant Job
- Що таке тестування мавп при тестуванні програмного забезпечення?
- Вибір тестування програмного забезпечення як вашу кар’єру
- Тестування програмного забезпечення Технічний вміст Письменник Робота фрілансера
- Зразок звіту про помилки
- Практичне тестування програмного забезпечення для контролю якості (вимоги до випуску)