40+ Популярни тестови QA анализатори Интервю Въпроси и отговори (2021 СПИСЪК)

40 popular test qa analyst interview questions

Най-често задавани въпроси и отговори на интервю за анализатор за тестване / осигуряване на качеството:

Докато решавате кариерата, в която искате да бъдете, решаващият фактор не е само този, който смятате, че може да ви хареса да работите.

Но да бъдеш в тази категория изисква много умения, разбиране на отговорностите, както и необходимите работни задължения за избраната от теб кариера. Същото важи и при избора на кариера като QA Analyst. Това не само изисква от вас да бъдете добър тестер, бързо обучаващ се, необикновен мислител, но също така изисква да бъдете и сложен решаващ проблем.

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

Тази статия ще обхване всеки аспект, чиито познания са задължителни, за да бъдете QA анализатор. Най-често задаваните тук въпроси и отговори за интервю за QA Test Analyst ще ви дадат ясна представа за подготовката на интервюто.

Популярни въпроси за интервю за QA Test Analyst

В # 1) Какви са отговорностите на QA анализатора?

Отговор: QA Analyst е този, който гарантира, че са взети всички възможни мерки за тестване на всяка характеристика на софтуерно решение както функционално, така и технически.

Основните отговорности на QA Analyst могат да бъдат изброени, както следва:

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

В # 2) Какво е вашето разбиране по отношение на плана за тестване?

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

Тестовият план е запис на процеси, които включват:

• Тестови задачи
• Тестова среда
• Техники за проектиране
• Критерии за влизане и излизане
• Всички рискове и т.н.

Въпрос # 3) Включете приоритета на тестовите задачи, определени от екипа за осигуряване на качеството при разработването на продукта.

Отговор: Приоритетът на тестовите задачи се определя, както следва:

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

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

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

По-долу са изброени няколко ключови предизвикателства:

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

В # 5) Определете тестване на случаи на употреба.

Отговор: Тестване на случай на употреба може да се определи като функционална техника за тестване на черна кутия, която улавя поредицата от взаимодействия, възникнали между „актьори“ и „система“. Тук „Актьори“ са представени от потребителите и техните взаимодействия.

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

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

В # 6) Определете тестова стратегия.

Отговор: Набор от насоки или подходи за тестване, които обикновено се извършват от ръководителя на проекта за определяне на тестовия дизайн и общия подход за тестване, се определят като Тестова стратегия. Той се намира като малък раздел от плана за тестване и се използва от множество проекти.

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

Тези подходи са допълнително категоризирани, както следва:

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

Q # 7) Обяснете разликата между контрол на качеството и осигуряване на качеството.

Отговор: 'Контрол на качеството' и „Осигуряване на качеството“ са двата основни термина, използвани по отношение на всеки проект за изпитване или продукт. Обикновено тестерите, които са нови в тази област, не разбират действителната разлика между двете.

Нека разберем разликата с помощта на таблицата по-долу.

В # 8) Според вас кога е подходящият момент да започнете QA в проект?

Отговор: Според жизнения цикъл на разработката на софтуер (SDLC), фазата на тестване се изпълнява след приключване на фазата „Внедряване и кодиране“. Но в днешния сценарий, за да постигнете най-добри резултати, е необходимо да започнете QA на проекта или продукта в началото на проекта.

Следването на този подход ще доведе до основните предимства, дадени по-долу:

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

Въпрос # 9) Разграничаване на процесите на проверка и валидиране.

Отговор: Процесите за проверка и валидиране обикновено се определят от два известни въпроса, т.е. ' Правилно ли изграждаме системата? “ и „Изграждаме ли правилната система?“ .

Нека видим другата разлика между тези два процеса в таблицата по-долу:

Въпрос # 10) Обяснете предимствата на разрушителното изпитване.

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

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

• Определя се слабостта на дизайна на приложението.
• Определете експлоатационния живот на приложението.
• Помага за намаляване на разходите и неуспеха.

В # 11) По какво се различава тестването от регресионното тестване?

Отговор: Има няколко разлики между повторно тестване и тестване на регресия.

Това може лесно да се разбере от таблицата по-долу:

В # 12) Какво знаете за тестването, управлявано от данни?

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

Изследването, управлявано от данни, се появява тук, където искаме приложението да работи според очакванията за всеки тип входни стойности. За тази цел данните, необходими за тестване на данни, не са кодирани твърдо, но тестовите скриптове вземат данните си от източници на данни като CSV файлове, ODBC източници и т.н.

За да обобщим, тестовете, управлявани от данни, изпълняват следните действия в цикъла:

най-добрият безплатен софтуер за бази данни за Windows

• Взема входни данни от теста от хранилището.
• Данни, въведени в приложението за извършване на действия.
• Проверете действителните резултати с очакваните.
• Отново повторете същите стъпки с нови входни тестови данни.

В # 13) Какво представлява матрицата на проследимостта? Изисква ли се за всеки проект?

Отговор: Матрицата на проследимостта във всеки проект е средство за проследяване на напредъка на проекта по отношение на внедряването на нови функционалности, подобряване на съществуващите функционалности и др. Чрез матрицата на проследимостта винаги можете да следите напредъка на проекта с всеки аспект, поддържан според датата.

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

Параметрите на матрицата за проследяване на изискванията включват:

• Всеки раздел от документа за изискванията е точка, която трябва да се обхване в RTM (матрица за проследяване на изискванията).
• Заглавието на всяка точка е заглавието на всеки раздел в спецификацията на изискванията.
• Съответно на всяка точка се споменават идентификатори на тестови случаи, които са написани за конкретния раздел.
• BUG / New Feature ID също се споменава във всеки раздел.
• Най-важният момент е, че се поддържа и проследяване на характеристиката, в която е реализирана компилацията на проекта и неговата характеристика.
• Друг параметър включва дали секцията е напълно тествана или все още е в състояние на тестване.

Въпрос # 14) Опишете предимствата на Agile Testing.

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

Посочените по-долу са предимствата на Agile тестването:

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

Въпрос # 15) Какво е отрицателно тестване?

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

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

В # 16) Разграничаване на ad-hoc тестване и изследователско тестване?

Отговор: Има няколко разлики между Ad-hoc тестване и изследователско тестване.

Нека видим разликите в таблицата по-долу:

Въпрос # 17) Защо автоматичното тестване е предпочитано пред ръчното?

Отговор: Е, както автоматизираното тестване, така и ръчното тестване имат своето значение и съществуване в света на тестването.

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

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

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

В # 18) Какво разбирате под „ефективност на теста“ и „ефективност на теста“?

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

Това може да се определи по формулата:

Ефективност на теста = (Брой разрешени дефекти / общ брой подадени дефекти) * 100

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

Това може да се определи по формулата:

Ефективност на теста = (Брой открити дефекти / Брой изпълнени тестови случаи)

Въпрос # 19) Обяснете процеса на шиене на проекти.

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

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

Малко аспекти според организационните цели в процеса на шиене са:

• Проектен подход
• Стратегии
• Включени контроли и процеси
• Роли и отговорности

В # 20) Как правите разлика между Приоритет и Тежест на дефекта в рамките на проекта?

Отговор: Както „Приоритет“, така и „Тежест“ са присвоени на грешката за категоризиране на проблемите / грешките в реда, в който трябва да бъдат взети за поправяне. Те се основават на различни фактори.

Нека разберем повече заедно с техните разлики в таблицата по-долу:

В # 21) Защо е необходимо да се прави тестване на производителността за всяко приложение?

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

Причините за извършване на тестване на производителността могат да бъдат разбрани от точките по-долу:

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

В # 22) Какво представлява тестването, управлявано от спецификация?

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

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

В # 23) Обяснете CMMI.

Отговор: CMMI означава интеграция на модел на зрелост на способността. Този модел е разработен от Института за софтуерно инженерство (SEI). Тя се основава на принципа, че процесите, свързани с управлението и разработването на продукт или система, определят качеството.

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

CMMI е разделен на 5 нива, както е посочено по-долу:

• Ниво 1: Първоначално
• Ниво 2: Управлявана
• Ниво 3: Определено
• Ниво 4: Количествено управляван
• Ниво 5: Оптимизиран

Въпрос # 24) Обяснете предимствата на внедряването на CMMI.

Отговор: Има няколко предимства при внедряването на CMMI.

Те са изброени, както следва:

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

В # 25) Запишете някои инструменти за тестване на автоматизацията.

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

• Селен
• вода
• Вятърна мелница
• САПУН
• Телур

В # 26) Можем ли да направим регресионно тестване в Unit Testing?

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

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

Q # 27) Каква е разликата между тестовете за дим и тестовете за здравословно състояние?

Отговор:

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

Q # 28) Какви са ежедневните ви дейности като ръчен тестер във вашия офис?

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

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

Q # 29) Какви са ежедневните ви дейности като член на тестера за автоматизация във вашия офис?

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

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

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

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

В # 30) Как правите разлика между изискване и дефект и подобрение?

Отговор : ДА СЕ изискване е потребителска история, която е от съществено значение за внедряването, тестването и доставянето.
An подобрение е добавена или импровизирана функция към съществуващата.
ДА СЕ дефект е по-скоро пълно отклонение от очакваните потребителски истории.

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

Q # 31) Какво правите, когато разработчикът ви отрича да поправи грешка, която сте подали?

Отговор : Важен фактор, който решава отстраняването на дефект, е „Приоритетът“, присвоен на него. Ако дефектът е с висок приоритет, шоу запушалка, която блокира основна функционалност и се възпроизвежда последователно, тогава е необходимо да бъде фиксирана в компилацията.

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

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

Q # 32) Какво правите, когато разработчикът ви отрича, че това, което сте подали, е грешка?

Отговор : Най-важната фаза от жизнения цикъл на дефекта е „Отхвърлено“, което означава, че регистрираният доклад за инцидент не е валиден. Документът за бизнес изискванията, в който се посочват изискванията, може да помогне за разбирането на софтуера и следователно естеството на докладвания инцидент.

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

Q # 33) Какво предстои първо Повторно тестване или Регресионно тестване?

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

Със сигурност решаването на един дефект и добавянето на друг в кода не е целта на процеса на тестване. Най-добрите находки и най-добрият улов на тестери обикновено са регресивни дефекти. Компилация никога не трябва да бъде пусната, без да е тествана за регресия.

Q # 34) Каква е алтернативата на бета тестването?

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

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

Q # 35) Какви са недостатъците на Agile изпълнението / методологията, с които сте се сблъсквали?

Отговор : Недостатъците са както следва:

1. Спринтовете обикновено са ограничени в много краен срок.
2. Документацията не е приоритет
3. Превключването между PBI (Product Backlog Items) може да бъде често.

Q # 36) Защо анализът на въздействието е важен?

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

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

Q # 37) С помощта на пример всяко тестване на производителността, стрес тестване и тестване на натоварване?

Отговор : Най-добрият случай тук, който може да се вземе, е уебсайт на живо.

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

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

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

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

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

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

Например, времето за извличане на свободни места за влак постепенно се увеличава, когато времето за резервация на квотата Tatkal се приближава, тъй като броят на потребителите, влезли в системата, се увеличава с времето за резервация Tatkal близо до 10 ч. сутринта или 11 ч. сутринта.

Q # 38) Какво е едно от най-големите ви предизвикателства, докато правите регресионно тестване?

Отговор : При извършване на регресионно тестване може да има различни предизвикателства.

• Повторното извършване на тестове може да стане не толкова вълнуващо за тестерите.
• Отнема много време, тъй като понякога подобно тестване се нуждае от нестандартно мислене.
• Компрометирана бизнес стойност.
• Неправилният избор на регресионни тестови случаи може да пропусне откриването на основен дефект на регресия.
• Възпроизвеждането на дефекта в производството следователно става противоречиво.
• Голям апартамент за изпълнение.

Q # 39) Ако бъдете помолени да документирате тестови сценарии, тестови случаи, тестови планове, тестова стратегия, с какво ще започнете и в каква последователност ще следват останалите?

Отговор : Последователността ще бъде Тестова стратегия, Тестов план, Тестови сценарии и накрая Тестови случаи.

Q # 40) Ами ако пропусна да документирам някое от горните? Кажете, че пропускам документирането на плана за тестване какви ще бъдат последиците?

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

Q # 41) Как бихте започнали да тествате компилацията, която наскоро получихте: Има ли някакъв подход, който следвате напр. първо да започнем тестване на дим, след това тестване на здравословното състояние?

Отговор : Тестване на дим> Тестване на здравословността> Тестове за изследване> Тестване на функционалността> Регресионно тестване и валидиране на крайния продукт.

Q # 42) Обяснете формата на отчета за грешките, който сте следвали?

Отговор :

Отчет за грешка трябва да съдържа следната информация:

• Идент. № на грешка
• Съпоставяне с изискване / подобрение / съществуваща грешка
• Резюме на грешка / заглавие
• Версия на продукта
• Приоритет
• Конфигурация (спецификации на системата)
• Предварителни условия
• Стъпки
• Очакван резултат
• Действителен резултат
• Дневници. Моментни снимки, видеоклипове
• Състояние
• Други забележки

Q # 43) Как избирате регресионни тестови случаи или формирате регресионния тестов пакет?

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

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

Q # 44) Можете ли да дойдете с пример за следните дефекти

• Дефект с нисък приоритет с висока тежест
• Дефект с висок приоритет и ниска тежест

Отговор : Дефект, който срива приложението, когато се възпроизвежда само в даден времеви печат на определена операционна система, може да бъде дефект с висока степен на сериозност и нисък приоритет.

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

Q # 45) Напишете един ефективен тестов случай, за да проверите дали дадена хартия е бяла хартия?

Отговор: Ако цветът на мастилото, с което пишете на бяла хартия, остане същият, тогава хартията е бяла. Например, ако пишете на бяла хартия с червено мастило, цветът на мастилото остава червен в писалката и изглежда червен и на хартията.

Забележка: Има много други отговори на този въпрос. Можете да се сетите за всеки такъв валиден отговор с основната логика.

Q # 46) Какво е тестване на харта?

Отговор: Тестване на сесия, извършено въз основа на целите и програмите, изброени в харта преди началото на тестването, е известно като тестване на харта.

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

Q # 47) Какъв е вашият подход, когато имате издание с висок приоритет, което трябва да бъде доставено за много кратко време?

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

Следното може да се направи, за да се подпомогне тестването при сценарий с недостиг на време: -

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

Q # 48) Напишете тестови случаи на всяко устройство / обект, намиращо се наоколо (Пример: стол)?

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

В такъв случай:-

• Какъв тип стол е? Офис стол, работна маса-стол, диван стол, маса-трапезария, комфортен стол?
• От какъв материал се прави столът - дърво, стомана, пластмаса, тапицерия?
• Попитайте за размерите (височина, тегло според вида на стола).
• Попитайте за наличност. И въз основа на това започнете да изготвяте своите дела.

Тестовите случаи биха се различавали за всеки тип стол, което е по-добре да оставите за способността си за мислене ( Например, предназначение на стола, размери според вида на стола, преносим, ​​непитейлен, лек, опции за покупка).

За всеки стол, a тестовият случай може да бъде: за получаване на якост на опън или максимална носеща способност.

Q # 49) Може ли всичко да се автоматизира?

Отговор: - До известна степен да. Но инструментите за автоматизация, както и другият софтуер, има своите ограничения. Също така тестваният софтуер или тестваното приложение ще продължат да се надстройват.

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

Заключение

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

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

Благодаря и успех с интервютата!

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

• Интервюирайте въпроси и отговори
• 25+ Най-популярни въпроси и отговори за интервю за ADO.NET
• 25 най-добри пъргави тестови интервюта Въпроси и отговори
• Спок интервю въпроси с отговори (най-популярни)
• Въпроси и отговори за интервю за ETL тестване
• 20 Най-популярни въпроси и отговори за интервю за TestNG
• Топ 30+ популярни въпроси и отговори за интервю за краставици
• Топ 50 на най-популярните въпроси и отговори за интервю за CCNA