20 selective qa interview questions clear interview 2021
Най-често задаваните въпроси и отговори на QA за осигуряване на качество, за да ви помогнат да се подготвите за интервюто:
Ето някои от въпросите, които бих задал, ако интервюирам инженер по осигуряване на качеството.
Въпросите ще наблегнат повече на процесите по качеството и стратегията и тези въпроси няма да бъдат задавани за тестване.
Инженерите за QA са предимно хора, които са прекарали известно време в тестовата индустрия, защото когато създавате пътни карти и стратегия, винаги е полезно да имате някаква експозиция в индустрията.
Да започваме!!
Често задавани въпроси за QA интервю
Да започваме!!
В # 1) Каква е разликата между осигуряване на качеството, контрол на качеството и тестване?
Отговор: Осигуряването на качеството е процесът на планиране и определяне на начина за наблюдение и изпълнение на процесите на качество (тест) в екип и организация. Този метод определя и определя стандартите за качество на проектите.
Контролът на качеството е процес на откриване на дефекти и предоставяне на предложения за подобряване на качеството на софтуера. Методите, използвани от контрола на качеството, обикновено се установяват чрез осигуряване на качеството. Основната отговорност на екипа за тестване е да внедри контрол на качеството.
Тестването е процес на намиране на дефекти / грешки. Той проверява дали софтуерът, създаден от екипа за разработки, отговаря на изискванията, зададени от потребителя и стандартите, определени от организацията.
Тук основният фокус е върху намирането на грешки и екипите за тестване работят като качествен вратар.
Въпрос # 2) Кога според вас трябва да започнат дейностите по осигуряване на качеството?
Отговор: QA дейността трябва да започне в началото на проекта. Колкото по-рано започва, толкова по-полезно е да се определят стандартите за постигане на качеството.
Разходите, времето и усилията са много предизвикателни, в случай че дейностите по осигуряване на качеството се забавят.
В # 3) Какво е разлика между тестовия план и тестовата стратегия ?
Отговор: Тестовата стратегия е на по-високо ниво, създадена най-вече от мениджъра на проекта, който демонстрира цялостния подход на тестването за целия проект, докато планът за тестване показва как трябва да се извърши тестването за конкретно приложение, попадащо в даден проект.
В # 4) Можете ли да обясните жизнения цикъл на софтуерното тестване?
Отговор: Тестване на жизнения цикъл на софтуера се отнася до процес на тестване, който има специфични стъпки, които трябва да бъдат изпълнени в определена последователност, за да се гарантира, че целите за качество са изпълнени.
В # 5) Как определяте a формат на писане на добър тест ?
каква е целта на регресионното тестване
Отговор: Форматът на тестовия случай включва:
- Идентификационен номер на тест
- Описание на тестовия случай
- Тежест
- Приоритет
- Заобикаляща среда
- Версия на компилация
- Стъпки за изпълнение
- Очаквани резултати
- Актуални резултати
В # 6) Какво е добър тест?
Отговор: С прости думи, добър тест е този, който открие дефект. Но всички тестови случаи няма да открият дефекти, така че добър тест може да бъде и такъв, който има всички предписани подробности и покритие.
В # 7) Какво бихте направили, ако имате голям пакет за изпълнение за много по-малко време?
Отговор: В случай че разполагаме с по-малко време и трябва да изпълним по-големия обем тестови случаи, трябва да приоритизираме тестовия случай и първо да изпълним тестовите случаи с висок приоритет и след това да преминем към тези с по-нисък приоритет.
По този начин можем да се уверим, че важните аспекти на софтуера са тествани.
най-добрият уау частен сървър за pvp
Като алтернатива, ние също може да търсим предпочитанията на клиентите, която е най-важната функция на софтуера според тях, и ние трябва да започнем тестване от тези области и след това постепенно да преминем към тези области, които са с по-малко значение.
В # 8) Смятате ли, че QA's също може да участва за разрешаване на производствени проблеми?
Отговор: Определено!! Би било добра крива на обучение за QA's да участват в решаването на производствени проблеми. Много проблеми с производството могат да бъдат разрешени чрез изчистване на регистрационните файлове или извършване на някои настройки на системния регистър или чрез рестартиране на услугите.
Този вид екологични проблеми могат да бъдат много добре решени от екипа за осигуряване на качеството.
Също така, ако QA има представа за разрешаването на производствените проблеми, те могат да ги включат, докато пишат тестовите случаи, и по този начин те могат да допринесат за подобряване на качеството и да се опитат да минимизират производствените дефекти.
В # 9) Да предположим, че намерите грешка в производството, как бихте могли да се уверите, че същата грешка не е въведена отново?
Отговор: Най-добрият начин е незабавно да напишете тест за производствен дефект и да го включите в регресионния пакет. По този начин гарантираме, че грешката не се въвежда отново.
Също така, можем да мислим за алтернативни тестови случаи или подобни видове тестови случаи и да ги включим в нашето планирано изпълнение.
В # 10) Каква е разликата между функционално и нефункционално тестване?
Отговор:
Функционално тестване се занимава с функционалния аспект на приложението. Тази техника проверява дали системата се държи според изискванията и спецификацията. Те са пряко свързани с изискванията на клиента. Ние проверяваме тестовите случаи спрямо определеното изискване и правим резултатите от теста съответно успешни или неуспешни.
Примери включват регресия, интеграция, система, дим и т.н.
Нефункционално тестване , от друга страна, тества нефункционалния аспект на приложението. Той не се фокусира върху изискването, а върху фактори на околната среда като производителност, натоварване и стрес. Те не са изрично посочени в изискването, но са предписани в стандартите за качество. Така че, като QA, трябва да се уверим, че на тези тестове също е дадено достатъчно време и приоритет.
В # 11) Какво е отрицателно тестване? По какво се различава от положителното тестване?
Отговор: Отрицателното тестване е техника, която потвърждава, че системата се държи грациозно в случай на невалидни входове. Например, в случай че потребителят въведе някакви невалидни данни в текстово поле, системата трябва да покаже правилно съобщение вместо техническото съобщение, което потребителят не разбира.
Отрицателно тестване се различава от положителното тестване по начин, при който положителното тестване потвърждава, че нашата система работи според очакванията и сравнява резултатите от теста с очакваните резултати.
Повечето времеви сценарии за отрицателно тестване не са споменати в документите за функционални изисквания. Като QA трябва да идентифицираме негативните сценарии и трябва да имаме разпоредби за тяхното тестване.
В # 12) Как бихте се уверили, че тестването ви е завършено и има добро покритие?
Отговор: Матрицата за проследяване на изискванията и матриците за покритие на теста ще ни помогнат да установим, че нашите тестови случаи имат добро покритие.
Матрицата за проследяване на изискванията ще ни помогне да определим, че условията на теста са достатъчни, за да бъдат покрити всички изисквания. Матриците за покритие ще ни помогнат да определим, че тестовите случаи са достатъчни, за да задоволят всички идентифицирани условия на тестване в RTM.
An RTM ще изглежда нещо като:
По същия начин, Тестовите матрици на покритие ще изглеждат така:
В # 13) Кои са различните артефакти, на които се позовавате, когато пишете тестовите случаи?
Отговор: Основните използвани артефакти са:
- Спецификация на функционалните изисквания
- Документ за разбиране на изискванията
- Случаи на употреба
- Тел рамки
- Потребителски истории
- Критерии за приемане
- Много пъти тестове за UAT
Въпрос # 14) Успявали ли сте някога да пишете тестовите случаи, без да имате документи?
Отговор: Да, има случаи, когато имаме ситуация, в която трябва да пишем тестови случаи, без да имаме конкретни документи.
В този случай, най-добрият начин е:
- Сътрудничи с BA и екипа за разработка.
- Ровете в имейли, които имат известна информация.
- Потърсете в по-стари тестови случаи / регресионен пакет
- Ако функцията е нова, опитайте се да прочетете wiki страниците или помощта на приложението, за да имате идея
- Седнете с разработчика и се опитайте да разберете направените промени.
- Въз основа на вашето разбиране идентифицирайте състоянието на теста и го изпратете на BA или заинтересовани страни, за да ги прегледа.
В # 15) Какво се разбира под Проверка и валидиране ?
Отговор:
Проверка е процесът на оценка на крайния продукт, за да се провери дали софтуерът отговаря на бизнес нуждите. Изпълнението на теста, което правим в ежедневния си живот, е дейността по валидиране, която включва тестване на дим, функционално тестване, регресивно тестване, тестване на системи и др.
Проверка е процес на оценка на междинните работни продукти на жизнения цикъл на разработка на софтуер, за да се провери дали сме в правилната следа от създаването на крайния продукт.
В # 16) Кои са различните техники за проверка, които познавате?
Отговор: Техниките за проверка са статични. Има 3 техники за проверка.
Те се обясняват по следния начин:
(i) Преглед - Това е метод, при който кодовете / тестовите случаи се разглеждат от лицето, различно от автора, който го е създал. Това е един от най-лесните и най-добрите начини за осигуряване на покритие и качество.
(ii) Инспекция - Това е технически и дисциплиниран начин за изследване и коригиране на дефектите в тестовия артефакт или код. Тъй като е дисциплиниран, той има различни роли:
- Модератор - Улеснява цялата инспекционна среща.
- Рекордер - Записва протокола от срещата, възникнали дефекти и други обсъдени точки.
- Четец - Прочетете документа / кода. Лидерът води и до цялата инспекционна среща.
- Продуцент - Автора. В крайна сметка те са отговорни да актуализират своя документ / код според коментарите.
- Рецензент - Всички членове на екипа могат да се считат за рецензенти. Тази роля може да се играе и от някаква група експерти е изискванията на проекта.
(iii) Упътване - Това е процес, при който авторът на документа / кода чете съдържанието и получава обратната връзка. Това е предимно вид FYI сесия (за ваша информация), а не търсене на корекции.
В # 17) Каква е разликата между Тестване на натоварване и стрес ?
Отговор:
Стресиране е техника, която потвърждава поведението на системата, когато тя работи под стрес. За да обясним, намаляваме ресурсите и проверяваме поведението на системата. Първо разбираме горната граница на системата и постепенно намаляваме ресурсите и проверяваме поведението на системата.
В Тестване на товара, проверяваме поведението на системата при очакваното натоварване. Товарът може да бъде на едновременен потребител или ресурси, които имат достъп до системата едновременно.
В # 18) В случай че имате някакви съмнения относно вашия проект, как подхождате?
Отговор: В случай на някакви съмнения, първо се опитайте да го изчистите, като прочетете наличните артефакти / помощ за приложението. В случай на продължаващи съмнения, попитайте непосредствен ръководител или старши член на вашия екип.
Бизнес анализаторите също могат да бъдат добър избор да задават съмнения. Също така можем да предадем нашите запитвания на екипа за разработка в случай на други съмнения. Последният вариант би бил да се свържете с мениджъра и накрая със заинтересованите страни.
В # 19) Използвали ли сте някакви инструменти за автоматизация?
Отговор: Отговорът на този въпрос е изключително изключително за индивида. Отговорете на всички инструменти и стратегии за автоматизация, които сте използвали във вашия проект.
Въпрос # 20) Как определяте кой софтуер изисква колко тестване?
Отговор: Можем да познаем този фактор, като открием Цикломатична сложност .
т Техниката помага да се идентифицират по-долу 3 въпроса за програмите / функциите
- Проверява ли се функцията / програмата?
- Разбира ли се функцията / програмата от всички?
- Достатъчно надеждна ли е функцията / програмата?
Като QA можем да използваме тази техника, за да определим „нивото“ на нашето тестване.
направете временен фалшив имейл адрес
Практика е, че ако резултатът от цикломатичната сложност е повече или по-голям брой, ние считаме, че тази функционалност е от сложен характер и следователно заключаваме като тестер; че парчето код / функционалност изисква задълбочено тестване.
От друга страна, ако резултатът от цикломатичната сложност е по-малък, ние заключаваме като QA, че функционалността е с по-малка сложност и съответно решаваме обхвата.
Много е важно да разберете целия жизнен цикъл на тестване и трябва да можете да предлагате промени в нашия процес, ако е необходимо. Целта е да се достави висококачествен софтуер и по този начин QA трябва да предприеме всички необходими мерки за подобряване на процеса и начина, по който тестващият екип изпълнява тестовете.
Надявам се, че тези въпроси и отговори за QA интервю ще ви помогнат да подготвите интервю за осигуряване на качеството.
Препоръчително четене
- Въпроси и отговори за интервюта
- Някои интересни въпроси за интервю за тестване на софтуер
- Въпроси и отговори за интервю за ETL тестване
- Топ 20 най-важни въпроси и отговори за интервю за API тестване
- Как да се подготвим за интервю за тестване на софтуер
- Софтуерно ръководство Тестване Интервю въпроси за опитни професионалисти
- 25 най-добри пъргави тестови интервюта Въпроси и отговори
- Топ 200 въпроса за интервю за тестване на софтуер (трябва да се прочете, за да се изчисти ВСЯКО интервю за тестване)