Содержание
У сучасному швидкоплинному та постійно мінливому середовищі розробки програмного забезпечення методологія Agile набула широкого поширення завдяки своїй гнучкості та ітераційному підходу. Хоча Agile пропонує численні переваги, такі як швидка доставка та співпраця з клієнтами, забезпечення високої якості залишається надзвичайно важливим завданням. Ось тут і вступає в дію концепція підвищення якості. Зосередившись на якості на початку життєвого циклу Agile, організації можуть запобігти дефектам, скоротити кількість повторних робіт і підвищити загальну задоволеність клієнтів. У цій статті ми дослідимо важливість підвищення якості, його вплив на Agile-проекти та стратегії ефективної інтеграції практики якості на початкових етапах розробки програмного забезпечення.
Завдяки дійсно коротким циклам випусків у світі Agile-розробників у команди з контролю якості завжди вистачає часу, щоб вчасно завершити тестування. У цій статті ми спробуємо висвітлити деякі ключові моменти, які, якщо їх успішно реалізувати, допоможуть команді з контролю якості підтягнути обличчя не лише через вчасне тестування продукту, але й завдяки тому, що вони допомогли просунути якість на вищий рівень і впровадити акцент на якість серед інших дисциплін, таких як як розробки, управління програмами, команди управління продуктами.
Впровадження тестової розробки
Застосування Test Driven Development зростає з кожним днем, враховуючи цінність, яку вона приносить, особливо в умовах стислих термінів. Однак реалізувати це нелегко, оскільки для цього потрібна потужна підтримка всієї команди, включаючи підтримку керівництва. Теоретично в TDD розробники створюватимуть автоматизовані тести, але команда тестування, безперечно, може співпрацювати з ними, щоб зрозуміти вимоги клієнтів/технічні характеристики для створення тестів, які потім стануть основою для кодування. Така співпраця є ключовою у світі Agile, який повторює основну мантру: «Якість — це відповідальність усієї команди». У ситуаціях, коли TDD неможливо реалізувати через відсутність підтримки, спільнота тестувальників повинна принаймні наполягати на наступному пункті, який звучить як «Покращити якість збірки, доступної для тестування».
Покращте якість збірки, доступної для тестування
Якість збірки, доступної для тестування, значною мірою залежить від якості вихідного коду, однак як тестувальник ви можете зробити щось, щоб покращити якість заздалегідь. Співпрацюйте з розробниками, щоб надати їм набір основних тестів (скажімо, тести перевірки збірки), які вони можуть запустити до випуску збірки для тестування. Це допоможе вам заощадити багато часу, зосередившись на тестуванні продукту на стабільних збірках. Однак спростіть цей процес для розробників:
- автоматизація набору тестів, які вони повинні виконати;
- тестування такого коду автоматизації, щоб переконатися у відсутності тестових проблем;
- кілька разів продемонструвати їм виконання тесту та бути доступним, якщо їм потрібна допомога.
Хоча ця практика покращить якість ваших тестових зусиль, якщо ви не співпрацюєте з розробниками, вони можуть сприймати це як накладні витрати. Завоюйте їхню довіру, навчаючи їх про те, що це заощадить час як для розробників, так і для тестувальників. Якщо у вас виникли труднощі з реалізацією цього, не поспішайте працювати з розробниками над ітераціями. Тим часом принаймні переконайтеся, що ви разом з ними перевіряєте тестові приклади, щоб переконатися, що їхній відгук було враховано. Це також має додаткову перевагу, оскільки розробники мають доступ до вашого набору тестів і можуть принаймні мимовільно перевірити свій код на розумність для деяких сценаріїв.
Обережно вибирайте автономні та незалежні завдання Sprint
Як ми всі знаємо, однією з основних характеристик Agile-розробки є надання демонстрованого коду в кінці кожного спринту. Щоб досягти цього, як тестова команда, будьте уважні на зустрічах з планування спринту. Приклади тестових завдань, які можуть поширюватися на Sprints, включають тестування продуктивності, тестування безпеки, тестування сумісності, щоб назвати декілька. Почніть із цими тестовими завданнями заздалегідь і розподіліть їх між Спринтами, щоб вони охопили належне тестове покриття та водночас стали доступними для команд розробників і тестувальників. Відкладати їх на наступний етап гри буде ризиковано як з точки зору термінів випуску продукту, так і з точки зору якості, що вплине на загальні витрати на ваш проект.
Створюйте фреймворки та утиліти
Подивіться на можливості створення інфраструктур продуктивності та утиліт поза вашими основними зусиллями з автоматизації тестування. Наприклад, подивіться на утиліти для створення тестових даних, такі як створення облікового запису користувача, сканер для визначення непрацюючих посилань на веб-сторінках, автоматичне встановлення продукту тощо. Такі інфраструктури та утиліти заощадять вам багато часу та допоможуть зосередитися на областях, які найкраще перевіряти вручну . Продемонструйте таку тестову IP для решти команди продукту, щоб допомогти їм зрозуміти сценарії, коли вони також можуть отримати від них користь, допомагаючи покращити загальне прийняття тестових зусиль.
Потенційно може бути ще кілька подібних речей, які команда тестувальників може взяти на себе, щоб допомогти просунути якість і залучити всіх до своїх зусиль тестування, однак вищезазначені сфери є областями, до яких команда тестувальників може заглибитися відразу, щоб почати змінювати ситуацію. Спробуйте це, якщо ваша команда вибрала шлях Agile.