Меню

Урок за управление на тестове: Крайно ръководство за управление на тестове

  • Основен
  • Други
  • Урок за управление на тестове: Крайно ръководство за управление на тестове

test management tutorial

Опитайте Нашия Инструмент За Премахване На Проблемите

Това е урок за управление на тестове за тестване на софтуер. Той включва фази за управление на тестове, инструменти и управление на тестове срещу организационната структура:

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

Смятате ли, че организационната структура влияе върху управлението на тестове?

Ако отговорът ви е отрицателен, ще видим защо? Ако отговорът е да, нека видим как влияе. За да намерим връзката между тези две, трябва да разберем ясно тези теми и след това да проучим връзката между тестовото управление и организационната структура.

Тестово управление

Какво ще научите:

Въведение в управлението на тестове

Управление на тестове означава управление на целия процес на софтуерно тестване за определен проект. Процесът на управление на теста се прилага за целия жизнен цикъл на разработка на софтуер. Следователно, в идеалния случай, веднага щом процесът на разработване на софтуер стартира, процесът на управление на теста също трябва да започне.

Тест мениджърът имаше следните отговорности -

  • Ръководителят на тестове трябва да осигури последователност и качество на тези работни продукти.
  • Работете с Test Analyst и Technical Test Analyst, за да изберете и персонализирате подходящия шаблон.
  • Работете с Test Analyst и Technical Test Analyst, за да установите стандарти за тези продукти, като нива на подробна степен.
  • Прегледайте работните продукти, като използвате подходящи техники.

Компоненти за управление на тестове

Тестовото управление е разделено на 5 части за по-добро разбиране:

  1. Тестова документация
  2. Тестова оценка
  3. Тестови показатели
  4. Измерване на напредъка на теста
  5. Показатели за наблюдение на жизнения цикъл на тестване

# 1) Тестова документация

Има три вида тестова документация, които са изброени по-долу:

  • Политика за тестване
  • Тестова стратегия
  • План за главен тест

# 1) Политика за тестване:

  • Обобщава стойността, която организацията извлича от тестването.
  • Определя политики за тестване.
  • Описва как да се оцени ефективността на тестването.
  • Очертава тестовия процес.
  • Посочете как организацията ще подобри тестовия процес?

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

  • Описва общите методологии за тестване, които се използват за управление на проектни и продуктови рискове.
  • Аналитични стратегии: Като тестване на базата на риск.
  • Моделна стратегия: Подобно на оперативен профил, където тестовият екип разработва модел, базиран на реални и приети ситуации на околната среда, входа и условията.
  • Методологична стратегия: Качествени характеристики, при които тестовият екип използва набор от условия за изпитване, контролен списък или колекция от обобщени логически тестове.
  • Техники, отговарящи на процеса или на стандарти: Следва набор от процеси като SCRUM / Agile.
  • Реактивни стратегии: Използване на базирани на дефекти АТАКИ, КАТО ИЗСЛЕДВАТЕЛНО ИЗПИТВАНЕ.
  • Консултативна стратегия: Подобно на насоченото от потребителя тестване, където тестовият екип разчита на приноса на една или повече заинтересовани страни, за да определи условията за изпитване като Изнесено тестване за съвместимост.
  • Също така описва:
    • Процедури за интеграция
    • Техники за спецификация на теста
    • Независимост на тестването
    • Задължителни и незадължителни стандарти
    • Тестова среда
    • Инструменти
    • Многократна употреба на софтуерни продукти
    • Повторно тестване и регресия.

# 3) План за главен тест:

  • Той обхваща всички задачи за тестване, които трябва да бъдат изпълнени.
  • Той обсъжда как тестването ще приложи Тестова стратегия и политика.
  • Ако нещо не е описано, тогава планът за изпитване трябва да опише защо и планът за смекчаване за това.
  • Съдържанието на тестовия план е:
    • Елементи за тестване
    • Качествени характеристики, които трябва да бъдат тествани.
    • График
    • Цикъл на изпълнение
    • Дефектни променливи
    • Тествайте елементи в обхвата
    • Критерии за изход
    • Проектни рискове
    • Цялостно управление на усилията за тестване,
    • Роли и отговорности
    • Вход и изход

# 2) Оценка на теста

Общи точки:

  • Е управленска дейност
  • Тя се основава на опит.
  • Той предоставя специфичен и подробен каталог на разходите, ресурсите, задачите и хората.
  • Веднъж изготвена оценка, трябва да бъде предоставена на ръководството заедно с обосновката.
  • Окончателната оценка представлява възможно най-добрия баланс между целите на организацията и проекта.
  • Оценката се основава на наличната към момента информация, тя беше изготвена.
  • За да останат точни, оценките трябва да бъдат актуализирани, за да отразяват нова и променена информация.

Фактори, влияещи върху оценката на теста:

  • Необходимо ниво на качество
  • Размер на системата
  • Исторически данни
  • Фактори на процеса като стратегия, развитие и жизнен цикъл
  • Материални фактори като тестова среда, автоматизация, инструменти и данни
  • Хора фактор
  • Сложност на процеса
  • Обучение и KT (трансфер на знания)
  • Усвояване и разработване на нови инструменти и технологии, процеси или техники.
  • Изискването за по-висока степен на подробната спецификация на теста.
  • Време на пристигане на компонента
  • Данни от теста.

Предположения:

  • Структура на разбивка на работата
  • Сесия за оценка на екипа
  • Тестер - Съотношение на разработчиците
  • История на организацията
  • Анализ на функционална точка, LOC.

Оценката на теста е обяснена по-нататък в урока.

# 3) Тестови показатели

  • Това, което се измерва, се счита за направено?
  • Това, което не измерва, е лесно да се игнорира?
  • Трябва да се определи ограничен набор от полезни показатели.
  • Трябва да се определят само тези показатели, чието тълкуване е договорено от всички.
  • Отчитането и обединяването на показатели трябва да бъдат автоматизирани.
  • Мениджърът трябва да провери информацията в метрични стойности.

Показател на проекта: % от преминаване, неуспешно изпълнение и т.н.

Показател на продукта:

  • Атрибути на продукта
  • Плътност на дефектите

Показател на процеса: Измерва способността за тестване като% от дефекта.

Хора: Способност на индивида.

Показател за напредъка на теста:

  • Броят на тестовите условия / случаи, планирани спрямо изпълнени.
  • Общ дефект, категоризиран по тежест, приоритет, текущо състояние и подсистема ефект.
  • Броят на промените, необходими, приети, изградени и тествани.
  • Планирани спрямо действителни разходи.
  • Планирано спрямо действително времетраене
  • Планиран спрямо действителен етап на изпитване.
  • Състояние на риска за качеството на продукта
  • % загуба на тестови усилия, разходи или време.

# 4) Измерване на напредъка на теста

Продуктови рискове:

  • % от покрития риск.
  • % от риска за тест за неуспех
  • % Риск, идентифициран от индивида.

Дефекти:

безплатен частен сървър
  • Броят на откритите дефекти спрямо броя на подадените дефекти.
  • Средно време на пристигане на неизправност
  • Дефекти в конкретните тестови елементи.
  • Откриване на RCA (анализ на основната причина)
  • Дефектът е Тестови версии.
  • Дефект във фаза
  • Приоритет и сериозност
  • Отчитане на отхвърляния срещу дублиране
  • Отнема време за разрешаване
  • Броят на новите дефекти, въведени поради отстраняване на стари дефекти.

Тест:

  • Общ брой на тест проход, неуспех, бегач, блокиран
  • Общият брой на тестовете за регресия.

Покритие:

  • Изисквания и покритие на дизайна
  • Покритие на риска
  • Покритие на конфигурацията на околната среда
  • Покритие на кода

# 5) Показатели за наблюдение на жизнения цикъл на тестване

Наблюдавайте тестовия план

  • Брой на риска и изискване
  • Откриване на дефекти
  • План срещу действителни усилия.

Дизайн на тестовия монитор

  • Броят на дефектите, открити по време на проектирането.

Анализ на тестовия монитор

  • Брой условия
  • Брой дефекти в анализа

Наблюдавайте изпълнението на теста

  • % от конфигурацията на средата
  • % от тестовите случаи са автоматизирани.

Изпълнение на монитора

  • % от преминали, неуспешни, без изпълнение, блокирани тестови случаи
  • % Обхванати тестови случаи
  • Планирани спрямо реални дефекти разрешени
  • % от плана спрямо действителното покритие

Затваряне на монитора

  • % от тестовите случаи преминават, болест
  • % от тестовите случаи, проверени в категорията за многократна употреба
  • % от тестовите случаи са автоматизирани.
  • Броят на разрешените / неразрешени дефекти.
  • % от тестовия работен продукт

Обсъдената по-долу фаза на мониторинг и контрол на тестовете допълнително обяснява тази тема.

Фази за управление на тестове

По време на процеса на управление на теста трябва да се вземат предвид следните точки. С други думи, по-долу са различните фази на процеса на управление на теста:

  1. Анализ на риска
  2. Тестова оценка
  3. Планиране на тестове
  4. Тестова организация
  5. Тестово наблюдение и контрол
  6. Управление на проблемите
  7. Протокол от теста

Можете да забележите, че първите четири фази са по-скоро за планиране, а останалите три за изпълнение. Следователно можем да разделим целия процес на управление на теста на две части, т.е. планиране и изпълнение.

Нека разгледаме подробно различните фази на тестовото управление.

# 1) Анализ на риска

Тази фаза включва откриване на рисковите фактори и възможни решения. Ако анализът на риска се направи задълбочено, можем да избегнем бъдещи грешки или поне да има някакво решение.

Рискът е нещо, което може или не може да се случи. Но ако това се случи, какво ще бъде неговото въздействие? Това може да повлияе зле на качеството на софтуера, репутацията на компанията и много други.

Трябва да се открият рискови фактори, за да се избегне това лошо въздействие. Трябва да се направи анализ на риска за установяване на рисковите фактори. Съществуват два вида рискове, т.е. рискове по проекта и рискове за продуктите. Проектните рискове са рисковете, които са свързани с работния процес, а Продуктовият риск са рискове, които са свързани с разработения продукт.

# 2) Оценка на теста

Оценката на теста е свързана с прогнозирането на времето, необходимо за всяка тестова дейност / фаза. Тъй като това е приблизителна оценка, не може да бъде точна. За по-добра оценка на теста можем да изучим миналите проекти на нашата компания или да се консултираме с членовете на екипа, които ще отговарят за тази работа или фаза на теста.

# 3) Планиране на теста

Самото планиране на теста е дълъг процес. Той включва дефиниране на тестови цели, обхват на теста, тестова стратегия, времево планиране, ресурси, комуникационен подход и др. Изискванията трябва да са много ясни за определяне на тестовите цели и обхват. Планът за тестване е за тестери, потребители и членове на проектния екип.

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

# 4) Тестова организация

По време на фазата на планиране на теста сме планирали всички възможни неща за тестването.

шпионски софтуер за поставяне на мобилен телефон

Следователно имаме нужда от квалифицирани членове на екипа, които да изпълнят този план или да го направят успешен. Организацията на тестовете е свързана с изграждането на перфектния екип за тестване за успешен проект.

# 5) Тестово наблюдение и контрол

Докато работата по тестване е в ход или докато тестерите изпълняват плана за тестване, всички тези процеси трябва да бъдат наблюдавани. Човек трябва да следи цялата тази тестова работа. Ако се извърши мониторинг на теста, тогава тестовият екип и ръководителят на теста ще получат обратна връзка за това как е напредъкът в теста?

Използвайки тази обратна връзка, ръководителят на теста може да насочи членовете на екипа да подобрят качеството на по-нататъшната работа по тестване. С помощта на тестово наблюдение екипът на проекта ще получи видимост на резултатите от теста. Също така помага да се знае за тестовото покритие.

За големи проекти тестовото наблюдение се извършва с помощта на автоматизиран инструмент, тъй като събирането на данни ще бъде по-лесно. За малки проекти един човек ще събере всички данни или документи, свързани с напредъка на теста. За събиране на информация за напредъка на теста можем да се възползваме от шаблона на дневника на теста IEEE 829. Всичко беше свързано с тестовото наблюдение.

Нека да видим какво е тест контрол? Работата по проектите не винаги ще протича както сме планирали. Може да има някои разлики между плана и действителната работа. За да намалим или премахнем тези разлики, трябва да направим някои промени и по този начин контролираме тестовата работа.

# 6) Управление на проблемите

Проблемите могат да бъдат всеки проблем, който възниква по време на процеса на разработване и тестване на софтуера. Това може да е най-малката причина, поради която не сме в състояние да разработим / доставим качествен продукт. Някои проблеми са ограничител на шоуто, т.е. без да разрешим този проблем, няма да можем да продължим с по-нататъшния процес.

Управлението на проблеми е свързано с това как се справяме с тези проблеми / проблеми. Можем да го наречем и управление на инциденти. Управлението на проблеми изисква по-добро планиране на процеса на решаване на проблеми. По-доброто управление на изданията зависи от уменията и опита на ръководителя на тестването.

Как възникват тези проблеми?

Може да има няколко причини да възникне проблем. Някои въпроси са свързани със стратегията, а други са с дефиницията, HR, график и т.н.

Проблеми със стратегията :

Примери:

  • Проектът изчерпва средства.
  • Лоша комуникация по проекта.
  • Процесът на управление на проекти не е в съответствие с посочените стандарти.

Проблеми с дефиницията : Проблеми, свързани с изискванията.

Примери: Неясни изисквания. Много проблеми могат да бъдат въведени поради неясни изисквания.

Проблеми с планирането: Това е най-често срещаният тип издание. Служителите трябва да се борят, за да спазят крайния срок.

HR въпроси:

Примери:

  • Липсва умение в отбора.
  • Грешно картографиране на служителите за работа.

Може да има много повече видове въпроси и не можем да споменем всички тук. По този начин управлението на проблемите е свързано с регистриране, проследяване и разрешаване на проблеми.

# 7) Протокол от теста

Протоколът от теста помага да се идентифицира покритието на теста, качеството на разработения продукт и необходимите подобрения на процеса. Можем да решим „колко тестове са необходими?“

Ако е направено достатъчно тестване, тогава можем да представим този доклад за теста на заинтересованите страни или клиентите. За да могат те също така да опознаят качеството на продукта и да имат представа колко тестове се извършват върху продукта.

Инструменти за управление на тестове

Управлението на тестовете се усложнява, докато продължаваме в процеса на разработка на софтуер и това е една от основните причини, поради които в днешно време се предлагат толкова много инструменти за управление на тестове.

Тези инструменти ще помогнат в последните четири фази на процеса на управление на теста (Организация на теста, Мониторинг и контрол на тестове, Управление на проблеми и Отчет за теста). Тъй като тези инструменти помагат за важните фази на управлението на тестове, те трябва да бъдат разгледани първо в проекта.

По-долу са изброени най-популярните инструменти за управление на тестове:

  1. qТест
  2. PractiTest
  3. Зефир
  4. Тест Collab
  5. TestFLO за JIRA
  6. XQual
  7. Xray - Ръководен тест за управление
  8. TestRail
  9. QACoverage
  10. Изисквания и управление на тестове за Jira (RTM)
  11. SPIRATEST от Inflectra
  12. Kualitee
  13. аква
  14. Тестпад
  15. JunoOne

=> Щракнете тук за подробни рецензии на ТОП инструменти за управление на тестове

Организационни структури

Нека да видим различните организационни структури.

Може да има определени правила за организационни структури или да има някои идеални структури, но независимо от това всяка организация може да има своята структура. Има толкова много организационни структури и всяка от тях има своите предимства и недостатъци.

Тук ще обсъдим някои от тях.

Първо ще видим най-простата организационна структура, която се използва за малки проекти.

организационна структура

В тази структура както тестерите, така и програмистите докладват на Мениджъра за развитие.

играйте уау за безплатен частен сървър
  1. Мениджърът по развитие има добър контрол върху дейностите по проекта.
  2. Ще има по-малка възможност за комуникационна пропаст между екипите за тестване и разработка.
  3. Също така на срещи е добре да се определят крайните срокове за ръководителя на разработката, тъй като той / тя има пълни познания за работата по тестване и разработка.
  4. Работата в екип ще бъде ефективна поради минималните слоеве.

Недостатъците на тази структура включват:

  1. Тъй като няма мениджър на тестване, има вероятност тестването да се обмисли късно в проекта.
  2. Има и друга възможност тестването да има по-малко значение за проекта. Може да се разглежда късно в проекта.

Обикновено в малките организации за малки проекти се случва екипът за разработка да отнема повече време от споменатото и екипът за тестване трябва да пострада, т.е. екипът за тестване ще трябва да тества продукта до крайния срок, така че екипът за тестване да получи по-малко време за тестване продуктът.

В тази структура, за да завърши успешно проект, ръководителят на разработката трябва да има предвид, че целта му не е просто да завърши проекта, а да разработи качествен софтуер.

Втората най-често използвана организационна структура:

2-ра организационна структура

Това е най-често срещаният тип организационна структура. В тази структура тестерите докладват на мениджърите на тестове, а разработчиците се отчитат пред мениджъра на разработките. И мениджърът на тестовете, и мениджърът по разработка докладват на мениджъра на проекта.

Тест мениджърът ще отговаря за всички дейности, свързани с теста, и отговорността на мениджъра за разработка е да накара софтуера да се разработи. Ръководителят на проекта ще контролира както тестването, така и дейностите по разработка.

Предимства:

  • За разлика от предишната структура, тук в тази структура има различни мениджъри за тестване и разработка, поради което и двамата могат да се съсредоточат върху работата си. Те ще останат отдадени на работата си и ще имат по-малко разсейване за тях.
  • В тази структура тестовите дейности не могат да бъдат пренебрегвани или не могат да бъдат разглеждани късно в проекта. Това означава, че както тестването, така и разработването ще придобият еднакво значение.
  • Когато става въпрос за вземане на критични решения, изгодно е, че екипът за тестване има независимост.

Недостатъци:

  • Съществува възможност за пропуск в комуникацията поради множество нива.

Управление на тестове срещу организационни структури

Организационните структури влияят пряко върху управлението на тестове. Различните организационни структури оказват различно въздействие върху управлението на теста, поради което управлението на теста варира в зависимост от уменията и опита на ръководителя на тестване, както и в зависимост от позицията на ръководителя на тестване в организационната структура.

Тук видяхме две организационни структури. В първата структура мениджърът на разработките и мениджърът на тестване е едно и също лице, поради което влияе върху управлението на тестове. Ръководителят на разработката има за цел да разработи софтуер и докато прави това, той / тя трябва да разгледа и тестовата работа.

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

Заключение

Видяхме както темите, т.е. управлението на тестовете и организационните структури поотделно, както и връзката между тези две. Можем да заключим, че организационните структури влияят върху управлението на тестове.

Докато сравняваме двете структури, споменати по-горе, във втората структура управлението на тестове ще се обработва по-добре от първата. Причината за това може да е специален мениджър на тестове.

Организационните структури се различават при различните организации. Въпреки че има някакъв дефиниран процес за управление на тестове (или екипите може да използват инструменти за управление на тестове), управлението на тестове ще се различава поради различните организационни структури, мениджъри на тестове, умения и опит на мениджъра на теста.

Препоръчително четене

^