Для забезпечення ефективного тестування слід дотрумуватися основних принципів тестування. Є сім загальних принципів тестування.
Принципи тестування:
Раннє тестування
Тестування показує наявність дефектів
Вичерпне тестування неможливе
Кластеризація дефектів
Парадокс пестицидів
Тестування залежить від контексту
Відсутність помилок є хибою
Раннє тестування
Тестування має починатися якомога раніше в життєвому циклі розробки програмного забезпечення. Таким чином, будь-які дефекти на етапі вимог або проєктування виявляються на ранніх стадіях. Набагато дешевше виправити дефект на ранніх етапах тестування. Рекомендується починати пошук помилок в момент визначення вимог.
Тестування показує наявність дефектів
Тестування програмного забезпечення зменшує ймовірність того, що в програмному забезпеченні залишаться невиявлені дефекти, але навіть якщо дефектів не буде виявлено, це не є доказом відсутності дефектів.
Вичерпне тестування неможливе
Вичерпне тестування неможливе. Неможливо з точки зору часу і фінансових можливостей протестувати всі можливі комбінації вхідних даних, сценарії тощо. Тому потрібно визначити оптимальний обсяг тестування на основі оцінки ризику програми.
Кластеризація дефектів
Кластеризація дефектів стверджує, що невелика кількість модулів містить більшість виявлених дефектів. Це застосування принципу Парето до тестування програмного забезпечення: приблизно 80% проблем виявляються в 20% модулів.
Парадокс пестицидів
Повторне використання тієї самої суміші пестицидів для знищення комах під час ведення сільського господарства з часом призведе до того, що комахи вироблять стійкість до пестициду, отже, пестициди стануть неефективними. Те саме стосується тестування програмного забезпечення. Якщо проводити один і той же набір повторюваних тестів, метод з часом стане нефективним для виявлення нових дефектів.
Щоб подолати це, тестові випадки потрібно регулярно переглядати, додаючи нові та оновлюючі існуючі тестові випадки, щоб допомогти знайти більше дефектів.
Тестувальники не можуть просто покладатися на існуючі методи тестування. Потрібно постійно вдосконалювати існуючі методи, щоб зробити тестування ефективнішим.
Тестування залежить від контексту
Тестування залежить від контексту, що в основному означає, що спосіб тестування сайту електронної комерції відрізнятиметься від способу тестування програми з ведення фінансового та податкового обліку. Усе розроблене програмне забезпечення не є ідентичним. Ви можете використовувати різні підходи, методології, техніки та типи тестування залежно від типу програми.
Відсутність помилки є хибою
Цілком можливо, що програмне забезпечення, яке на 99% вільне від помилок, все ще непридатне для використання. Це може статися, якщо система ретельно перевіряється на відповідність неправильним вимогам. Тестування програмного забезпечення — це не просто виявлення дефектів, а й перевірка відповідності програмного забезпечення потребам бізнесу. Відсутність помилки є хибою, тобто пошук і виправлення дефектів не допомагає, якщо збірка системи непридатна для використання та не відповідає потребам і вимогам користувача.
Модель Великого вибуху – це модель SDLC, де ми не дотримуємося жодного чіткого процесу. Розробка лише починається з вкладення необхідних фінансів і зусиль як вхідних умов, а результатом є розроблене програмне забезпечення, яке може відповідати чи не відповідати вимогам клієнта. Ця модель Великого вибуху не дотримується процесу/процедури, і потребує дуже мало планування. Навіть клієнт не впевнений, чого саме він хоче, і вимоги впроваджуються на ходу без особливого аналізу. Зазвичай ця модель використовується для невеликих проєктів, де команда розробників дуже маленька.
Модель великого вибуху – застосування
Модель великого вибуху передбачає зосередження всіх можливих ресурсів на розробці програмного забезпечення та кодуванні з дуже незначним плануванням або без нього. Вимоги розуміються та впроваджуються по мірі надходження. Будь-які необхідні зміни можуть вимагати або не потребувати оновлення всього програмного забезпечення.
Ця модель добре підходить для невеликих проєктів з одним або двома розробниками, які працюють разом, а також корисна для академічних або практичних проєктів. Ця модель – хороший варіант вибору для продукту, вимоги якого недостатньо зрозумілі та остаточна дата випуску не вказана.
Модель великого вибуху – переваги
Перевага моделі Великого Вибуху полягає в тому, що вона дуже проста і не потребує ретельного планування. Проста в управлінні та не вимагає офіційних процедур.
Переваги моделі Великого вибуху такі:
Це дуже проста модель
Планування не потрібне або мало потрібно
Легко керувати
Потрібно дуже мало ресурсів
Надає гнучкість розробникам
Це хороший варіант вибору для новачків або студентів.
Модель великого вибуху – недоліки
Модель великого вибуху є моделлю дуже високого ризику, і зміни у вимогах або неправильно зрозумілі вимоги можуть навіть призвести до повного скасування проєкту.
Недоліки моделі Великого вибуху такі:
Дуже високий ризик і невизначеність.
Не дуже хороша модель для складних і об’єктно-орієнтованих проєктів.
Погана модель для тривалих проєктів.
У разі нечіткого формулювання вимог, можуть бути суттєві перевитрати.
Прототипування програмного забезпечення
Прототипування програмного забезпечення стосується створення прототипів програмного забезпечення, яке відображає функціональність продукту, що розробляється, але насправді може не зберігати точну логіку оригінального програмного забезпечення.
Прототипування програмного забезпечення стало дуже популярним як модель розробки програмного забезпечення, оскільки воно дозволяє зрозуміти вимоги клієнтів на ранній стадії розробки. Це допомагає отримати цінні відгуки від клієнтів і допомагає дизайнерам і розробникам програмного забезпечення зрозуміти, що саме очікується від продукту, який розробляється.
Що таке прототипування програмного забезпечення?
Прототип – це робоча модель програмного забезпечення з обмеженою функціональністю. Прототип не завжди підтримує точну логіку, яка використовується в фактичному програмному додатку.
Прототипування використовується, щоб користувачі могли оцінити пропозиції розробників і випробувати їх перед впровадженням. Це також допомагає зрозуміти вимоги, які стосуються користувача і, можливо, не були враховані розробником під час розробки продукту.
Нижче наведено поетапний підхід до розробки прототипу програмного забезпечення.
Ідентифікація базової вимоги
Цей крок передбачає розуміння основних вимог до продукту, особливо щодо інтерфейсу користувача. Більш складні деталі внутрішнього дизайну та зовнішні аспекти, такі як продуктивність і безпека, можна ігнорувати на цьому етапі.
Розробка початкового прототипу
На цьому етапі розробляється початковий прототип, де демонструються основні вимоги та надаються інтерфейси користувача. Ці функції можуть не працювати однаково всередині фактично розробленого програмного забезпечення. Хоча обхідні шляхи використовуються, щоб надати клієнту той самий вигляд і відчуття в розробленому прототипі.
Огляд прототипу
Потім розроблений прототип представляється замовнику та іншим важливим учасникам проєкту. Зворотній зв’язок збирається в організований спосіб і використовується для подальшого вдосконалення продукту, що розробляється.
Перегляд та вдосконалення прототипу
На цьому етапі обговорюються відгуки та коментарі, а також проводяться деякі переговори з клієнтом на основі таких факторів, як часові та бюджетні обмеження та технічна можливість фактичного впровадження. Прийняті зміни знову включаються в новий розроблений прототип, і цикл повторюється, доки не виправдаються очікування клієнта.
Горизонтальні та вертикальні прототипи
Прототипи можуть мати горизонтальні або вертикальні. Горизонтальний прототип відображає інтерфейс користувача для продукту та дає ширший огляд усієї системи, не зосереджуючись на внутрішніх функціях. З іншого боку, вертикальний прототип – це детальна розробка конкретної функції або підсистеми продукту.
Призначення як горизонтального, так і вертикального прототипу різне. Горизонтальні прототипи використовуються для отримання додаткової інформації про рівень інтерфейсу користувача та бізнес-вимог. Його можна навіть представити в демонстраційних роликах, щоб отримати бізнес на ринку. Вертикальні прототипи мають технічний характер і використовуються для отримання деталей точного функціонування підсистем. Наприклад, вимоги до бази даних, взаємодія та навантаження обробки даних у даній підсистемі.
Прототипування програмного забезпечення – типи
Використовуються різні типи прототипів програмного забезпечення. Нижче наведено основні типи прототипів програмного забезпечення, які широко використовуються:
Одноразове/швидке створення прототипів
Одноразове прототипування також називається швидким або закритим прототипуванням. Цей тип прототипування використовує дуже мало зусиль з мінімальним аналізом вимог для створення прототипу. Після розуміння фактичних вимог прототип відкидається, а фактична система розробляється з чітким розумінням вимог користувача.
Еволюційне прототипування
Еволюційне прототипування, яке також називають макетним прототипуванням, засноване на створенні фактичних функціональних прототипів із мінімальною функціональністю на початку. Розроблений прототип є основою майбутніх прототипів, на основі яких будується вся система. Використовуючи еволюційне прототипування, добре зрозумілі вимоги включаються в прототип, а вимоги додаються, коли вони зрозумілі.
Інкрементне прототипування
Інкрементне прототипування означає створення кількох функціональних прототипів різних підсистем і подальшу інтеграцію всіх доступних прототипів для формування повної системи.
Екстремальне прототипування
Екстремальне прототипування використовується в області веб-розробки. Він складається з трьох послідовних фаз. По-перше, базовий прототип з усіма існуючими сторінками представлений у форматі HTML. Потім додається обробка даних. Нарешті, сервіси впроваджуються та інтегруються в кінцевий прототип. Цей процес називається екстремальним прототипуванням, який використовується для привернення уваги до другої фази процесу, на якій розробляється повністю функціональний інтерфейс користувача.
Прототипування програмного забезпечення – застосування
Прототипування програмного забезпечення є найбільш корисним у розробці систем із високим рівнем взаємодії з користувачем, таких як онлайн -системи. Системи, які вимагають від користувачів заповнення форм або перегляду різних екранів перед обробкою даних, можуть дуже ефективно використовувати прототипування, щоб надати точний вигляд і відчуття ще до того, як буде розроблено фактичне програмне забезпечення.
Програмне забезпечення, яке потребує занадто багато обробки даних і більшість функціональних можливостей є внутрішніми із дуже слабким інтерфейсом користувача, зазвичай не отримує переваги від прототипування. Розробка прототипу може бути додатковими витратами в таких проєктах і потребуватиме багато додаткових зусиль.
Прототипування програмного забезпечення – переваги
Прототипування програмного забезпечення використовується в типових випадках, і рішення слід приймати дуже обережно, щоб зусилля, витрачені на створення прототипу, додали значну цінність кінцевому розробленому програмному забезпеченню.
Переваги моделі створення прототипів такі:
Збільшення залучення користувачів до продукту ще до його впровадження.
Оскільки відображається робоча модель системи, користувачі краще розуміють систему, що розробляється.
Зменшує час і витрати, оскільки дефекти можна виявити набагато раніше.
Доступні швидші відгуки користувачів, що веде до кращих рішень.
Відсутню функціональність можна легко визначити.
Можна визначити незрозумілі або складні функції.
Прототипування програмного забезпечення – недоліки
Недоліки моделі прототипування такі:
Ризик недостатнього аналізу вимог через занадто велику залежність від прототипу.
Користувачі можуть заплутатися в прототипах і реальних системах.
На практиці ця методологія може збільшити складність системи, оскільки обсяг системи може вийти за межі початкових планів.
Розробники можуть спробувати повторно використати існуючі прототипи для створення фактичної системи, навіть якщо це технічно неможливо.
Зусилля, витрачені на створення прототипів, можуть бути занадто великими, якщо вони не контролюються належним чином.
Модель RAD
Модель RAD (швидка розробка додатків) базується на створенні прототипів та ітераційній розробці без спеціального планування. Сам процес написання програмного забезпечення передбачає планування, необхідне для розробки продукту.
Швидка розробка додатків зосереджена на зборі вимог замовника за допомогою семінарів або фокус-груп, ранньому тестуванні прототипів замовником із застосуванням ітераційної концепції, повторному використанні існуючих прототипів (компонентів), безперервній інтеграції та швидкій доставці.
Що таке RAD?
Швидка розробка програм – це методологія розробки програмного забезпечення, яка використовує мінімальне планування на користь швидкого прототипування. Прототип – це робоча модель, функціонально еквівалентна компоненту продукту.
У моделі RAD функціональні модулі розробляються паралельно як прототипи та інтегруються, щоб створити повний продукт для швидшої доставки продукту. Оскільки немає детального попереднього планування, це полегшує включення змін у процес розробки.
Проєкти RAD використовують ітераційну та інкрементальну модель і мають невеликі команди, що складаються з розробників, експертів у галузі, представників клієнтів та інших ІТ-ресурсів, які поступово працюють над своїм компонентом або прототипом.
Найважливішим аспектом успіху цієї моделі є переконатися, що розроблені прототипи придатні для повторного використання.
Дизайн моделі RAD
Модель RAD включає фази бізнес-моделювання, моделювання даних, моделювання процесів, генерація додатків, тестування та оборот.
Бізнес-моделювання
Бізнес-модель продукту розроблена з точки зору потоку інформації та розподілу інформації між різними бізнес-каналами. Проводиться повний бізнес-аналіз, щоб знайти життєво важливу для бізнесу інформацію, як її можна отримати, як і коли інформація обробляється та які фактори сприяють успішному потоку інформації.
Моделювання даних
Інформація, зібрана на етапі бізнес-моделювання, переглядається та аналізується для формування наборів об’єктів даних, життєво важливих для бізнесу. Атрибути всіх наборів даних ідентифіковані та визначені. Відносини між цими об’єктами даних встановлюються та детально визначаються відповідно до бізнес-моделі.
Моделювання процесів
Набори об’єктів даних, визначені на етапі моделювання даних, перетворюються для встановлення потоку бізнес-інформації, необхідного для досягнення конкретних бізнес-цілей відповідно до бізнес-моделі. На цьому етапі визначається модель процесу для будь-яких змін або вдосконалень наборів об’єктів даних. Подається опис процесу для додавання, видалення, отримання або зміни об’єкта даних.
Генерація додатків
Фактична система будується, а кодування виконується за допомогою засобів автоматизації для перетворення моделей процесів і даних у фактичні прототипи.
Тестування
Загальний час тестування зменшено в моделі RAD, оскільки прототипи тестуються незалежно під час кожної ітерації. Однак потік даних та інтерфейси між усіма компонентами потребують ретельного тестування з повним тестовим покриттям. Оскільки більшість компонентів програмування вже протестовано, це зменшує ризик будь-яких серйозних проблем.
Модель RAD проти традиційного SDLC
Традиційний SDLC дотримується жорстких моделей процесу з великим наголосом на аналізі вимог і збиранні даних перед початком кодування. Це створює тиск на клієнта, щоб він підписав вимоги перед початком проєкту, і клієнт не може оглянути продукт, оскільки протягом тривалого часу немає робочої збірки.
Клієнту можуть знадобитися деякі зміни після того, як він побачить програмне забезпечення. Проте процес змін є досить жорстким, тому внести серйозні зміни в продукт у традиційний SDLC може бути неможливим.
Модель RAD зосереджена на ітераційній та поетапній доставці робочих моделей клієнту. Це призводить до швидкої доставки замовнику певної демо версії продукту та участі замовника протягом повного циклу розробки, що зменшує ризик невідповідності фактичним вимогам користувача.
Модель RAD – застосування
Модель RAD може бути успішно застосована для проєктів, в яких можлива чітка модульність. Якщо проєкт не можна розбити на модулі, RAD може вийти з ладу.
Наступні вказівки описують типові сценарії, коли RAD можна використовувати:
RAD слід використовувати лише тоді, коли систему можна модулювати, щоб розробляти її поступово.
RAD слід використовувати, якщо існує велика кількість архітекторів для моделювання.
RAD слід використовувати, лише якщо бюджет дозволяє використання інструментів автоматичного створення коду.
Модель RAD SDLC слід обирати лише за наявності експертів із відповідних бізнес-знань.
Слід використовувати там, де вимоги змінюються під час проєкту, а робочі прототипи повинні бути представлені замовнику невеликими ітераціями по 2-3 місяці.
Модель RAD – переваги
Модель RAD забезпечує швидку доставку, оскільки скорочує загальний час розробки завдяки повторному використанню компонентів і паралельній розробці.
Переваги моделі RAD наступні:
Зміни у вимогах можуть бути прийняті.
Прогрес можна виміряти.
Час ітерації може бути коротким за допомогою потужних інструментів RAD.
Продуктивність з меншою кількістю людей за короткий час.
Скорочений час розробки.
Збільшує можливість повторного використання компонентів.
Відбуваються швидкі первинні огляди.
Заохочує відгуки клієнтів.
Застосування інтеграції з самого початку.
Модель RAD – недоліки
RAD працює добре, лише якщо доступні висококваліфіковані інженери, а замовник також зобов’язаний створити цільовий прототип у встановлені терміни. Якщо обох сторін бракує зобов’язань, модель може зазнати невдачі.
Недоліки моделі RAD такі:
Залежність від технічно сильних членів команди для визначення бізнес-вимог.
Лише систему, яка може бути модульною, можна створити за допомогою RAD.
Гнучка модель SDLC – це комбінація ітераційних і інкрементальних моделей процесів з акцентом на адаптивність процесів і задоволеність клієнтів шляхом швидкої доставки робочого програмного продукту. Гнучкі методи розбивають продукт на невеликі поетапні збірки. Ці збірки надаються в ітераціях. Кожна ітерація зазвичай триває від одного до трьох тижнів. Кожна ітерація включає міжфункціональні команди, які працюють одночасно над різними сферами, такими як:
Планування
Аналіз вимог
Дизайн
Кодування
Тестування
Наприкінці ітерації робочий продукт демонструється клієнту та іншим зацікавленим сторонам.
Що таке Agile?
Гнучка модель вважає, що кожен проєкт потрібно виконувати по-різному, а існуючі методи мають бути адаптовані відповідно до вимог проєкту. У Agile завдання розділені на часові рамки (ітерації), щоб забезпечити впровадження певної функції чи частини продукту. Використовується ітераційний підхід, і робоча збірка програмного забезпечення випускається після кожної ітерації. Кожна збірка є інкрементальною з точки зору функцій; остаточна збірка містить усі функції, необхідні замовнику.
Процес Agile почав впроваджуватися в середині 90-х років та з часом став дуже популярним завдяки своїй гнучкості та адаптивності.
До найпопулярніших гнучких методологій належать Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development та Dynamic Systems Development Method (DSDM) (1995).
Після того, як у 2001 році був опублікований Agile Manifesto, вони разом називаються гнучкими методологіями .
Ключові ідеї (постулати) Agile Manifesto:
Люди та співпраця важливіші за процеси та інструменти – у Agile-розробці важливі самоорганізація та мотивація.
Працюючий продукт важливіший за вичерпну документацію – Робоча демо версія програмного забезпечення вважається найкращим способом спілкування з клієнтами для розуміння їхніх вимог, замість того, щоб просто залежати від документації.
Співпраця із замовником важливіша за обговорення умов контракту – Оскільки вимоги не можуть бути повністю зібрані на початку проекту через різні фактори, постійна взаємодія з клієнтом дуже важлива для отримання відповідних вимог до продукту.
Готовність до змін важливіша за дотримання плану – Agile Development зосереджується на швидкому реагуванні на зміни та постійному розвитку.
Agile та традиційні моделі SDLC
Agile базується на адаптивних методах розробки програмного забезпечення , тоді як традиційні моделі SDLC, такі як модель водоспаду, базуються на лінійному підході. Лінійний підхід в традиційних моделях SDLC зазвичай передбачає з детальне планування і повний прогноз щодо точних завдань і функцій, які будуть повинні бути виконані протягом життєвого циклу продукту.
Методи прогнозування повністю залежать від аналізу потреб і планування, зробленого на початку циклу. Будь-які зміни, які необхідно внести, проходять суворий контроль за змінами та встановлення пріоритетів.
Agile використовує адаптивний підхід , де немає детального планування та є ясність щодо майбутніх завдань лише стосовно того, які функції потрібно розробити. Існує розробка, керована функціями, і команда динамічно адаптується до мінливих вимог до продукту. Продукт тестується дуже часто через ітерації випуску, що мінімізує ризик будь-яких серйозних збоїв у майбутньому.
Взаємодія з клієнтами є основою цієї Agile-методології, а відкрите спілкування з мінімальною документацією є типовою рисою Agile-середовища розробки.
Гнучка модель – переваги та недоліки
Гнучкі методи останнім часом широко поширені у світі програмного забезпечення. Однак цей метод не завжди підходить для всіх продуктів.
Переваги гнучкої моделі такі:
Сприяє командній роботі та навчанню.
Функціональність можна швидко розвинути та продемонструвати.
Вимоги до ресурсів мінімальні.
Підходить для часто змінюваних вимог
Надає ранні часткові робочі рішення.
Хороша модель для середовища, яке постійно змінюється.
Мінімум правил, документацію легко використовувати.
Забезпечує одночасну розробку та доставку в загальному запланованому контексті.
Легко керувати.
Надає гнучкість розробникам.
Недоліки гнучкої моделі такі:
Вищі ризики стосовно сталості, ремонтопридатності та розширюваності продукту.
Значною мірою залежить від взаємодії з клієнтом, тому, якщо клієнт не може чітко сформулювати свої потреби, то існує ризики спрямування команди у хибному напрямку.
Існує дуже висока індивідуальна залежність, оскільки створюється мінімум документації.
Введення в курс технології нових членів команди може бути досить ускладненим через відсутність документації.