Меню

Какво да правим, когато няма достатъчно време за тестване?

what do when there isn t enough time test

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

Част от тестовия цикъл често ли осъзнавате, че нямате достатъчно време за тестване? Всичко беше под контрол, за начало, но скоро стигате до плана за непредвидени ситуации „Какво да правя, когато няма достатъчно време за тестване?“ раздел.

Аз също бях там и не е забавно. :)

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

=> Щракнете тук за пълна серия уроци за план за тестване

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

Къде отиде времето ми за тестване?

Няма достатъчно време за тестване

как мога да стана изпитател на продукти

Първо, защо се случва това?Много причини - някои от които са:

# 1) Неправилна оценка :

Ако сте започнали с неточно очакване, нещата непременно ще се провалят. Добрата оценка на теста трябва да вземе предвид следното:

  • Време за подготвителни задачи - Говорим за задачи като:
    • Идентифициране и съставяне на пакет за регресия
    • Създаване на тестови данни
    • Време за определяне на готовността за изпитване (напр.: Тест за дим / здрав разум) и др.
  • Поддръжка на тестови случаи : Тестовите случаи са активи за дългосрочно използване. Те със сигурност ще бъдат подложени на незначителни актуализации по време на изпълнение. Препоръчително е за нови продукти до 30% от времето за изпълнение на теста ви да бъде разпределено за тези незначителни задачи по поддръжката. Всички екипи и проекти може да не се нуждаят от 30%, но отделят малко време и усилия за тази задача.
  • До това / Изследователски тестове - Броят на скриптовите тестове е основен знаменател за числата за оценка на теста. Никой тестващ екип на този свят обаче няма да отрече да проучи софтуера ви, дори ако моделът е доминиран по сценарий.
  • Докладване / Комуникация - Това включва срещи за триаж / изправяне, актуализиране на инструментите за управление на работата и т.н.
  • Коефициент на непредвидени обстоятелства: Стандартите препоръчват 25-30% буфер към първоначалните Ви оценки. Но екипите рядко могат да си го позволят. Дори и тогава, оставете малко място за дишане, когато е възможно.
  • Екип и неговите възможности: Ако имате нов екип или ако те използват инструмент за първи път, може да се наложи да отделите малко време за обучение. Съобразете вашите прогнози въз основа на вашия екип, с който работите.

Препоръчително четиво=> Проверете това за повече информация относно успеха и методите за оценка на теста

# 2) Нестабилни компилации и други технически проблеми:

  • Неуспех на теста за дим / здрав разум : Когато основните тестове на AUT не успеят след внедряване в QA среда, почти нищо не може да направи екипът на QA за изпълнението на теста. Вярно е, че можем да работим по други задачи, докато това се случи, но все още няма да запълни тестов цикъл време. И така, това допринася значително за загубата на време.
  • Данни от теста недостъпно : Данните, подобни на производството, са задължителни за всеки проект за тестване. Невлизането навреме в QA средата също е друг блокиращ фактор. Понякога тестерите могат да заобиколят това чрез създаване и управление на собствени тестови данни , но отнема много време и може да не е винаги на място.
  • Проблеми с околната среда - Неуспешното внедряване на компилацията, сървърът продължава да изтича, много повече такива проблеми изяждат вашия тестов цикъл. Това вероятно произтича от факта, че някои компании (не всички) подкопават важността на добрата среда, подобна на живо, за ефективно QA. Те често се опитват да избягат от сървъри с нисък капацитет и настройки за грим. Това наистина е кратка корекция и не прави никакви услуги. Всъщност това може да им струва качеството на тестване и загуба на ценно време за тестване.

# 3) Липса на съгласие между всички участващи страни:

Това може да е рядък проблем с екипи, следващи Agile или БЕЗОПАСНО поради близките кръгове, в които работят, но много отбори все още страдат от несъгласие или неразбиране относно това кога Dev, Ops и QA трябва да получават продукти един от друг. Следователно, закъснения.

За да разберете тънкостите на комуникацията, проверете това => Как бизнесът, развитието и QA могат да работят заедно, за да завършат проекта

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

Как тестерите могат да получат достатъчно време за тестване?

# 1) Оценете точно. Когато се съмнявате, надценявайте с разумна разлика, но не подценявайте. Не забравяйте да направите корекции на прогнозата въз основа на вашия екип, инструменти и процеси. Когато приключите, потърсете официален знак, за да са наясно и да бъдат в течение.

# две) Вземете предвид историческите данни - Инструментът за управление на тестове е вашият най-добър приятел .

  • Колко време отне по-ранните тестови цикли?
  • Какви проблеми са причинили прекъсвания на предишния цикъл на изпитване?
  • Колко пробега взеха повечето тестови случаи, преди да преминат?
  • Какви дефекти бяха съобщени?
  • Какви дефекти доведоха до прекъсване на тестването?

# 3) Задайте тези въпроси и планирайте съответно по време на криза:

  • Разберете Важна функционалност е вашият проект?
  • Разберете високорисков модул на проекта?
  • Коя функционалност е най-видима за потребителя?
  • Коя функционалност има най-голямо въздействие върху безопасността?
  • Коя функционалност има най-голямо финансово въздействие върху потребителите?
  • Кои аспекти на приложението са най-важни за клиента?
  • Кои части от кода са най-сложни и следователно най-обект на грешки?
  • Кои части на приложението са разработени в режим бързане или паника?
  • Кои според разработчиците са най-рисковите аспекти на приложението?
  • Какви проблеми биха довели до най-лоша реклама?
  • Какви проблеми биха причинили най-много оплаквания от обслужване на клиенти?
  • Какви видове тестове могат лесно да обхващат множество функционалности?

Имайки предвид тези точки, можете значително да намалите риска от издаване на проект при по-малко времеви ограничения.

# 4) Използвайте инструмент за управление на тестове. Това значително ще намали времето и усилията за подготовка, докладване и поддръжка.

=> За списъка с най-популярния избор на инструмент за управление на тестове , вижте тук :

# 5) Не можем да направим много за неправилни компилации / технически проблеми, но единственото нещо, което може да помогне, е да разгледаме резултатите от теста на модула. Това ще ни даде представа дали компилацията е била успешна или не и какви тестове са се провалили - така че не преоткриваме колелото.

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

# 6) Измервайте често своята производителност и напредък . Не позволявайте отчетите за състоянието да бъдат постигнати само в полза на външните екипи. Уверете се, че следите отблизо ежедневните си цели и способността си да ги постигнете.

Също така, не забравяйте да не влезете в класическата загадка на „Скорост срещу качество“. Защото, когато докладвате, да речем, 50 грешки на ден, може да изглежда, че сте супер продуктивни. Но ако повечето от тях се върнат като невалидни, вие си имате проблем.

Така че наблюдавайте, наблюдавайте и наблюдавайте малко повече :)

най-добрият почистващ препарат за Windows 10

Заключение:

И накрая, въпреки всички предпазни мерки и мерки, ако все още се окажете смачкани от времето, помолете за помощ .

Повечето отбори са готови да участват в сесия на военната стая, за да върнат нещата в релси.

За автора: Тези полезни съвети за тестване са предоставени от члена на екипа на STH Swati S.

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

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

=> Посетете тук за пълна серия уроци за план за тестване

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

^