Техники за оценка на тестовете в софтуерното тестване
Томас Хамилтън
⚡ Умно обобщение
Техниките за оценка на софтуерните тестове приблизително определят колко време ще отнеме тестването и колко ще струва. Четириетапен процес – разделяне на задачите, определяне на отговорници, оценка на усилията и валидиране със заинтересованите страни – превръща неясните срокове в защитим план, който ръководството може да одобри.
Какво представлява оценката на софтуерния тест?
Оценка на софтуерния тест е управленска дейност, която приблизително определя колко време ще отнеме дадена тестова задача и колко ще струва. Изготвянето на надеждна оценка за теста е една от най-важните отговорности в управление на тестове защото това определя решенията относно графика, бюджета и ресурсите.
Защо оценката на тестовете е важна
Клиентите винаги задават два въпроса, преди да одобрят тестов ангажимент:
За малки проекти на тези въпроси е лесно да се отговори. За по-голям проект — например тестване на GuruУебсайт на банка 99 — необходима ви е структурирана техника, за да защитите отговора.
Какво да оценим?
- Ресурси: хора, оборудване, съоръжения, финансиране и всичко останало, необходимо за изпълнение на работата.
- Time: най-ценният ресурс във всеки проект — всяко издание има краен срок.
- Човешки умения: знанията и опита на екипа. По-силните тестери завършват по-бързо от по-малко опитния екип.
- Цена: бюджетът на проекта — колко пари са необходими за провеждане на планираното тестване.
Как да се оцени
Често срещаните техники за оценка на софтуерните тестове са:
- Структура на разбивка на работата (WBS).
- Триточкова оценка.
- Широколентов Делфи.
- Анализ на функционална точка или точка на тестване.
- Метод на точките на употреба.
- Процентно разпределение.
- Ад-хок метод.
Четиристъпковият процес по-долу комбинира няколко техники, за да се стигне до защитима оценка. Примерът използва Guru99 Казус на банката.
Стъпка 1) Разделете целия проект на подзадачи
Използвайте Work Breakdown Структура техника за разделяне на сложен проект на модули, подмодули и в крайна сметка най-малките смислени задачи. Оценките са далеч по-надеждни на ниво лист, отколкото спрямо неясни проекти с основни елементи.
Приложете техниката, за да разчупите Guru99 Банков проект на пет по-малки задачи:
След това всяка задача се разделя на подзадачи, докато всеки ред стане достатъчно подробен, за да може да се направи оценка.
| Task | Подзадача |
|---|---|
| Анализирайте спецификацията на изискванията за софтуер | Проучете спецификациите на изискванията. |
| Интервюирайте разработчици и други заинтересовани страни, за да научите повече за уебсайта. | |
| Създайте спецификацията на теста | Проектиране на тестови сценарии. |
| Създайте тестови случаи. | |
| Revпреглед и преразглеждане на тестови случаи. | |
| Изпълнете тестовите случаи | Изградете тестовата среда. |
| Изпълнете тестовите случаи. | |
| Revпреглед на резултатите от изпълнението на теста. | |
| Докладвайте дефектите | Създайте дефект доклади. |
| Докладвайте за дефектите. |
Стъпка 2) Разпределете всяка задача на член на екипа
Възложете всяка подзадача на най-подходящия собственик.
| Task | собственик |
|---|---|
| Анализирайте спецификацията на изискванията за софтуер | Всички членове на екипа |
| Създайте спецификацията на теста | Тестер / Тестов анализатор |
| Изградете тестовата среда | Тестов администратор |
| Изпълнете тестовите случаи | Тестер, администратор на тестове |
| Докладвайте дефекти | тестер |
Стъпка 3) Оценка на усилията за всяка задача
Две допълващи се техники работят добре на този етап:
- Метод на функционалните точки.
- Триточкова оценка.
Метод 1) Метод на функционалната точка
Мениджърът на тестовете оценява размера, продължителността и цената за всяка задача.
Стъпка А) Оценете размера на задачата
Вземете задачата „Създаване на тестова спецификация“. Размерът ѝ зависи от функционалния размер на тестваната система – колкото повече функции има, толкова по-сложна е системата. Функционалните точки обикновено се класифицират в три групи: Сложни, Средни и Прости.
Въз основа на сложността, мениджърът на тестовете присвоява тежест на всяка функционална точка:
| група | Тежест |
|---|---|
| Комплекс | 5 |
| Среден | 3 |
| Прост | 1 |
- GuruУебсайтът на 99 Bank е разделен на 12 функционални точки. Тяхната сложност е обобщена по-долу.
| # | Модули | Приложими роли | Descriptйон | Тежест |
|---|---|---|---|---|
| 1 | Запитване за баланс | Мениджър, Клиент | Клиент: преглеждайте само салдото по собствените си сметки. Мениджър: преглед на баланса на всеки клиент под наблюдение. |
3 |
| 2 | Прехвърляне на средства | Мениджър, Клиент | Клиент: прехвърляне на средства от собствена сметка до всяка дестинация. Мениджър: прехвърляне на средства от всеки източник до всяка дестинация. |
5 |
| 3 | Мини изявление | Мениджър, Клиент | Последните пет транзакции от сметка. Клиент: преглеждайте само собствените си акаунти. Мениджър: преглед на всеки акаунт. |
3 |
| 4 | Персонализирано изявление | Мениджър, Клиент | Филтрирани транзакции по дата или стойност. Клиент: само собствени сметки. Мениджър: всяка сметка. |
5 |
| 5 | Промяна на паролата | Мениджър, Клиент | Клиент: промяна на собствената парола. Мениджър: промяна на собствената парола (не на клиента). |
1 |
| 6 | Нов Клиент | Мениджър | Добавяне и редактиране на данни за клиенти (адрес, имейл, телефон). | 3 |
| 7 | Нов акаунт | Мениджър | Спестовни и разплащателни сметки; един клиент може да притежава няколко от всяка от тях. Мениджърът добавя нови сметки за съществуващи клиенти. | 5 |
| 8 | Редактиране на профила | Мениджър | Редактиране на данни за съществуващ акаунт. | 1 |
| 9 | Изтриване на профила | Мениджър | Изтриване на съществуващ акаунт за клиент. | 1 |
| 10 | Изтриване на клиент | Мениджър | Изтривайте клиент само когато няма активни акаунти. | 1 |
| 11 | депозит | Мениджър | Депозирайте пари в брой във всяка сметка в клона. | 3 |
| 12 | Оттегляне | Мениджър | Теглете пари в брой от всяка сметка в клона. | 3 |
Стъпка Б) Оценка на продължителността на задачата
След като сложността е зададена, преценете времето, необходимо за тестване на всяка група.
- Общо усилие: пълни усилия за тестване на всяка функция на уебсайта.
- Общо функционални точки: общия брой модули на уебсайта.
- Оценка за функционална точка: средно усилие на точка; зависи от продуктивността на екипа.
Да приемем, че оценката на екипа за функционална точка е 5 часа/точкаОбщото усилие за GuruПример за 99 Bank е:
| група | Тежест | Функционални точки | Обща сума |
|---|---|---|---|
| Комплекс | 5 | 3 | 15 |
| Среден | 3 | 5 | 15 |
| Прост | 1 | 4 | 4 |
| Функция Общо точки | 34 | ||
| Оценка на точка | 5 | ||
| Общо очаквано усилие (човекочасове) | 170 | ||
Общото усилие за завършване на „Създаване на спецификацията на теста“ е около 170 човекочасаСлед като усилията са известни, можете да разпределите ресурси, за да определите продължителността и разходите.
Стъпка В) Оценка на разходите за задачите
Тази стъпка отговаря на втория въпрос на клиента – „Колко струва?“. Да приемем средна екипна ставка от $ 5 / часГорната задача отнема 170 часа, така че цената е 170 × $5 = $850Приложете едно и също изчисление за всяка задача от WBS, за да получите бюджета на проекта.
Колкото по-точна е оценката, толкова по-добре можете да управлявате бюджета на проекта и да гарантирате, че всеки долар ще ви донесе възвръщаемост.
Метод 2) Триточкова оценка
Триточковата оценка е структурирана техника, при която мениджърът на тестовете предоставя три стойности за всяка задача - оптимистичен, най-вероятно, и песимистичен усилие — базирано на предишен опит или най-добри предположения.
За „Създаване на спецификацията на теста“ трите стойности могат да бъдат:
- Най-добрият случай: 120 човекочаса (~15 дни) със силен и опитен екип.
- Най-вероятно: 170 човекочаса (~21 дни) с типичен екип и ресурси.
- Най-лошия случай: 200 човекочаса (~25 дни) с по-малко опитен екип и допълнителна преработка.
Изчислете среднопретеглената стойност, използвайки формулата в стил PERT:
Стойността E е среднопретеглена — оценката на заглавието за „Създаване на спецификацията на теста“.
Да изразиш увереността наоколо E, изчислете стандартното отклонение:
За Guru99 Банков пример, до който се получава оценката 166.6 ± 13.33 човекочаса — диапазон от 153.33 до 179.99 човекочаса.
Стъпка 4) Валидирайте оценката
Агрегирайте всяка оценка на задачата от WBS и представете плана на управителния съвет (изпълнителен директор, ръководител на проекта, ключови заинтересовани страни) за преглед и одобрение.
Разкажете на дъската за оценката логически, така че те да разберат допусканията, избраните техники и предвидените от вас непредвидени обстоятелства.
Най-добри практики за оценка на тестове
Добавяне на буферно време
Плановете рядко оцеляват при контакт с реалността – членовете на екипа напускат, тестовете отнемат повече време от очакваното, зависимостите се провалят. Вградете разумен буфер във всяка прогноза, така че графикът да абсорбира малки изненади.
Планирайте за наличност на ресурси
Вземете предвид планираните отпуски, обученията и ротациите на дежурства. Оценките, които игнорират наличността, изглеждат страхотно на хартия, но се провалят при изпълнението.
Използвайте минал опит като ориентир
Историческите данни от подобни проекти са безценни. Ако сте тествали сравним уебсайт миналата година, поучете се от неговите действителни данни, възникналите проблеми и буфера, който е спасил положението.
Придържайте се към оценката, но я преразгледайте
Оценките не са подвеждащиtracts; това са най-добри предположения. RevОпределяйте ги на известни етапи и ги коригирайте само когато изискванията се променят съществено или нова информация променя картината. Договаряйте всяка промяна с клиента прозрачно.
Шаблон за оценка на софтуерен тест
Изтеглете Excel файла за оценка на софтуерните тестове (.xlsx)
Други техники за оценка
В допълнение към WBS, Function Point и Three-Point оценка, няколко други техники се използват широко:
- Широколентов Delphi: итеративна консенсусна оценка от експертна група.
- Метод на точките на употреба: извлича усилия от броя и сложността на случаите на употреба.
- Процентно разпределение: разпределя фиксиран процент от общите усилия по проекта за тестване.
- Метод „Ad-hoc“: експертна оценка, когато липсват исторически данни.
Оценка „отдолу нагоре“ срещу „отгоре надолу“
Практическият поглед върху оценката също се разделя на две допълващи се стратегии:
- Оценка „отдолу нагоре“: въз основа на задачи на най-ниското ниво на WBS. Множество заинтересовани страни, опитен персонал и сътрудници комбинират своите числа, за да достигнат точна сума. Идеално, когато работата е добре разбрана.
- Оценка отгоре надолу: класифицира проекта по размер и сложност и го сравнява със завършени проекти с подобен вид. Използва също средните усилия на тестов случай и се мащабира според прогнозния брой случаи. Полезно е в началото на проекта, когато детайлите са оскъдни.
Повечето екипи съчетават двете – отгоре надолу за водещите числа, отдолу нагоре за увереност – и наслагват резултата със сложни модели, когато бюджетите оправдават усилията.
