3 strategies dealing with blocker defect
Дефектите на блокерите добавят много драматизъм към иначе редовните тестови дни.
В тази статия искам да разгледам някои стъпки, които тестерът може да предприеме, когато се занимава с тях.
Предполагам, че нашите скъпи читатели вече дълбоко разбират сериозността и приоритета на дефектите. Нуждаете се от кратко обобщение? Виж това.
Винаги ли означава ли, че трябва напълно да спрем тестването, ако попаднем на проблем с блокиране?
В някои случаи „да“, но може би не винаги. Възможно е да има случаи, при които е възможна някаква тестова дейност.
изображение източник
По-долу са дадени някои ситуации, които съм преживял в кариерата си като тестер. Силно вярвам, че стъпките, описани по-долу (по-късно консолидирани в блок-схема), трябва да се следват, за да се опрости този процес.
Нека скочим направо.
Стъпки, които трябва да предприемете, когато попаднете на дефект на блокер
Етап 1: Когато попаднете на проблем, инвестирайте време, за да откриете основната причина.
Силно вярвам, че като тестер работата ни просто не свършва отчитане на дефекти . Ако времето позволява, трябва да проучим какво е могло да причини проблема. Може да не винаги можем да посочим точната проблемна област, но се опитайте да отстраните възможно най-много. Същите подробности могат да бъдат актуализирани в дефекта като допълнителни коментари.
Направих много това в моите проекти и това доведе до бързо решение. Ползите от анализа на първопричината са:
- Като добавена стойност, това определено може да осигури по-добра насока на разработчика за отстраняване на грешки.
- Също така, QA тестерът може да разпознае дали този проблем е създаден самостоятелно (въвеждане на данни или проблеми с човешката употреба) и ако е така, може да бъде решен от самия тестер. Когато такива грешки се докладват на разработчиците, без да проверяваме от края на QA, те са счита за не-издание и може да създаде отрицателна репутация на тестера.
Така че, предлагам винаги да проверяваме двойно в края си, преди да регистрираме дефект.
Ето няколко примера в реално време от моите проекти, които ще затвърдят горните точки:
Работих по проект, при който при нашето тестване ще трябва да пуснем файл на определено място. Преименувайте го, за да съответства на името в конфигурацията. Планирано задание ще вземе файла с данни и ще зареди данните в системата. След това щяхме да проверим данните в базата данни и предния край.
sql изпитни въпроси и отговори pdf
По-рано срещахме проблеми, при които работата ще се изпълнява, но данните не се зареждат, а при разследването това беше така, защото тестерът не е променил името, докато е изпуснал файла на мястото
Това беше блокер за нас, но не нещо, което изискваше внимание от страна на разработчика. Трябваше да обърнем внимание на детайлите и да избягваме такива малки грешки.
как да отворя swf файл
Следват някои често срещани категории, първопричини и средства за отстраняване:
# 1) Файл на хостовете Проблем - Да кажем, че вашият файл с хостове има параметри, които са неправилни и причиняват проблема. В този случай можете сами да актуализирате хост файла или да потърсите помощ от някой, който има достъп, за да актуализира и да продължи изпълнението на теста.
Трябва да се установи дефект за същото, така че разработчиците да разследват, но с решението функционалното тестване все още може да продължи.
Забележка: Проверете при екипите си за проекти дали е добре екипът за QA да направи тези промени, преди да го направи.
# 2) Конфигурация - Често сме отбелязвали проблеми с конфигурацията, като например да не сочим към правилната среда или други проблеми с настройката, които блокират проблеми. И в такива случаи тестерите могат да правят промени и да продължат с тестването.
Забележка: Още веднъж потърсете разрешение, преди да направите това.
# 3) Издаване на код - Ако смятате, че проблемът се дължи на код, тестерите не могат да направят нищо особено. Регистрирайте дефект на блокер и изчакайте поправката да продължи с тестването.
# 4) Проблем с внедряването - Лошото внедряване е друга често срещана причина за проблеми с блокирането и те могат да бъдат засечени по време на теста за здравословно състояние. И тук тестването трябва да бъде спряно незабавно, докато се получи нова компилация.
# 5) Намаляване на околната среда - Ако средата не работи, кажете, че базата данни не се свързва със сървъра или URL адресът не работи в случай на уебсайтове; тестерите не могат да направят много в тези случаи, освен да съобщят за дефект и да изчакат системата да работи и да работи.
Следователно, ако съществува решение, използвайте го, за да продължите да тествате. Единственият начин да се установи дали това решение е налице е чрез разследване на основната причина. По-често може да има алтернатива.
Стъпка 2: Много е лесно да попаднете в безкраен цикъл, когато разследвате основната причина. Така че, уверете се, че не отнема цял ден и всички усилия.
Ето някои указатели:
- Намерете баланс и разпознайте точката на спиране, когато стигнете там.
- Опитът и опитът на тестера са от решаващо значение за успешния RCA. Добре е обаче да включите екипа и ръководството на екипа, когато е необходимо.
- Когато почувствате, че RCA отнема много време, първо докладвайте за проблема незабавно и предоставете колкото се може повече информация. Екранна снимка винаги е полезна.
- Ако е необходимо, проследете. Изпратете имейл до мениджъра или разработчика, за да обърнете внимание на критичния проблем.
- Продължете с отстраняването на неизправности, след като предупредите необходимите страни.
Причина, поради която дефектите на блокерите трябва да бъдат докладвани незабавно:
- Ръководството трябва да бъде информирано за всички престои, ако проблемът е дефект на showstopper. Тази информация трябва да бъде предадена на клиента и може също така да изисква актуализации на плана на проекта (срокове за осигуряване на качеството), промяна в резултатите и т.н.
- Всяко забавяне на резултатите от осигуряването на качеството трябва да бъде подкрепено с доказателства. Така че винаги е по-добре да общувате възможно най-скоро, вместо да чакате до края на деня.
Стъпка # 3: Сега, преминавайки към последната стъпка, след като приключихме с анализа на проблема и съобщаването му, какво следва?
- Ако проблемът блокира достъпа до една функционална област, проверете дали това оказва влияние върху други области
- Ако приложението отпред не работи, проверете дали тестването на бекенда / междинния софтуер / базата данни може да продължи.
- Ако не може да се осъществи дейност за изпълнение на теста, опитайте да работа по някаква документация свързани с вашия проект.
- Можете също да опитате да идентифициране на области за автоматизация ако повтаряте ръчно много работа. Не винаги автоматизацията трябва да използва инструмент. Да кажем, генерирането на отчети е монотонна задача за вас, това е една област, която може да бъде автоматизирана чрез прости макроси на Excel и подобни.
- Прекарайте време, знаейки за инструменти с отворен код, които могат да бъдат внедрени във вашия проект
- Не на последно място , работят за иновации, мантрата, която управлява света в момента!
Накрая , блок-схемата, която обобщава цялата дискусия!
Блок-схема: Стъпки за справяне с дефект на блокер
Автор : Тази страхотна статия е написана от член на екипа на STH Прия Р.
Какви стъпки предприемате, когато попаднете на някакъв дефект на блокера?
Препоръчително четене
- Какво е техника за изпитване на базата на дефекти?
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Процес на управление на дефекти: Как да управляваме ефективно дефекта
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Примерни отчети за грешки за уеб и продуктови приложения
- Как да възпроизведете невъзпроизводим дефект и да си заслужите усилията за тестване
- Софтуерното тестване е всичко за идеите (и как да ги генерирам)
- 7 принципа на софтуерното тестване: Клъстериране на дефекти и принцип на Парето