40+ popularnych pytań i odpowiedzi analityków ds. Kontroli jakości w ramach testów [LISTA 2021]

40 popular test qa analyst interview questions

Najczęściej zadawane pytania i odpowiedzi na rozmowę z analitykami ds. Testów / kontroli jakości:

Decydującym czynnikiem przy podejmowaniu decyzji o karierze, w której chcesz być, jest nie tylko ta, nad którą Twoim zdaniem może sprawiać przyjemność.

Ale bycie w tej kategorii wymaga wielu umiejętności, zrozumienia obowiązków, a także obowiązków zawodowych niezbędnych do wybranej kariery. To samo dotyczy wyboru kariery jako analityk ds. Kontroli jakości. Wymaga to nie tylko bycia dobrym testerem, szybkim uczniem, niezwykłym myślicielem, ale także umiejętnością rozwiązywania złożonych problemów.

Chociaż wyżej wymienione cechy nie są osiągane od razu, wymaga to oczywiście doświadczenia i dni wytężonej pracy.

Ten artykuł dotyczy wszystkich aspektów, których znajomość jest obowiązkowa, aby zostać analitykiem zapewniania jakości. Zawarte tutaj najczęściej zadawane pytania i odpowiedzi z analitykiem testów QA dadzą ci jasny obraz przygotowania do rozmowy kwalifikacyjnej.

Popularne pytania do wywiadów z analitykami testowymi

Pytanie 1) Jakie są obowiązki analityka ds. Kontroli jakości?

Odpowiedź: QA Analyst to osoba, która zapewnia, że ​​podjęto wszelkie możliwe środki w celu przetestowania każdej funkcji oprogramowania, zarówno pod względem funkcjonalnym, jak i technicznym.

Główne obowiązki Analityka QA można wymienić w następujący sposób:

• Wykonuj wszystkie działania i zarządzaj nimi, aby osiągnąć cele planu testów.
• Wybierz procesy o wysokiej jakości, aby opracować produkt.
• Powinien umieć analizować wymagania i dokumentować procedury.
• Dokumentuj i ponownie weryfikuj wszystkie wady. Ustaw priorytet i wagę usterek.
• Powinni umieć tworzyć, dokumentować i utrzymywać przypadki testowe.
• Analiza wyników badań.

Pytanie 2) Co rozumiesz na temat planu testów?

Odpowiedź: Kiedy masz jasne pojęcie o tym, co, kiedy, jak i kto, wtedy sprawy stają się łatwiejsze. To samo dotyczy testowania oprogramowania, gdzie plan testów jest dokumentem składającym się z zakresu, podejścia, zasobów i zarysu projektu testowego, a także działań służących do śledzenia postępu projektu.

Plan testów to zapis procesów, które obejmują:

• Zadania testowe
• Środowisko testowe
• Techniki projektowania
• Kryteria wejścia i wyjścia
• Wszelkie ryzyko itp.

P # 3) Określ priorytet zadań testowych określonych przez zespół QA w rozwoju produktu.

Odpowiedź: Priorytety zadań testowych są zdefiniowane w następujący sposób:

• Przygotowywany jest plan testów zawierający zarys i zakres projektu testowego.
• Przypadki testowe są przygotowane tak, aby obejmowały wszystkie główne i pomniejsze funkcjonalności danymi wymaganymi do testowania.
• Wykonywanie przypadków testowych zgodnie z funkcjonalnościami zaimplementowanymi w kolejnych kompilacjach projektu testowego w cyklu testowym.
• Zgłaszanie defektów z ponowną weryfikacją oraz śledzenie ich postępu.
• Przygotowanie podsumowania raportu z wykonania testu.

Pytanie 4) Wymień niektóre z kluczowych wyzwań, przed którymi stoisz podczas testowania oprogramowania.

Odpowiedź: Ponieważ mówimy, że pełne testy nigdy nie mogą zostać osiągnięte, wiąże się z tym kilka wyzwań. Niezależnie od tego, czy jest to małe, czy skomplikowane zadanie, podczas testowania oprogramowania dowolnego projektu stoją pewne wyzwania.

Poniżej wymieniono kilka kluczowych wyzwań:

• Brak wykwalifikowanego testera, który zazwyczaj boryka się z problemem świadomości przedmiotu, a także brakiem dobrej znajomości biznesu klienta.
• Czas jest również brany pod uwagę jako czynnik, ponieważ zwykle testerzy koncentrują się głównie na pokryciu zadań, a nie na pokryciu testami jakościowymi, gdy istnieje ogromna lista zadań do wykonania.
• Aby zdecydować, który przypadek testowy ma zostać wykonany jako pierwszy i z priorytetem. Osiąga się to zwykle poprzez doświadczenie zawodowe.
• Właściwe zrozumienie wymagań, które może doprowadzić do zera wszystkich wysiłków testowych, jeśli wymagania zostaną źle zrozumiane.
• Niedostępność najlepszych narzędzi wymaganych do wykonania testów w krótszym czasie i większej skuteczności.
• Obsługa relacji między testerami i programistami z dobrą komunikacją i umiejętnościami analizowania.

Pytanie 5) Zdefiniuj testowanie przypadków użycia.

Odpowiedź: Testowanie przypadków użycia można zdefiniować jako funkcjonalną technikę testowania czarnoskrzynkowego, która rejestruje serię interakcji, które miały miejsce między „aktorami” a „systemem”. Tutaj „aktorzy” są reprezentowani przez użytkowników i ich interakcje.

Charakterystykę testów przypadków użycia wymieniono poniżej:

• Uporządkowano wymagania funkcjonalne projektu.
• Rejestruje ścieżkę lub scenariusze od początku do końca.
• Może obejmować defekty integracji, tj. Defekty, które wystąpiły w wyniku interakcji między różnymi komponentami.
• Opisuje główne przepływy, a także wyjątkowy przepływ wydarzeń.
• Wszelkie warunki wstępne, które są wymagane, aby przypadek użycia działał, należy określić wcześniej.

Q # 6) Zdefiniuj strategię testowania.

Odpowiedź: Zestaw wytycznych lub podejść do testowania, które są zwykle stosowane przez kierownika projektu w celu określenia projektu testów i ogólnego podejścia do testowania, definiuje się jako strategię testów. Występuje jako niewielka część planu testów i jest używany w wielu projektach.

Stosuje się różne podejścia do testów w oparciu o takie czynniki, jak charakter i dziedzina produktu, ryzyko awarii produktu, doświadczenie w pracy z proponowanymi narzędziami itp.

Te podejścia są dalej klasyfikowane w następujący sposób:

• Proaktywne podejście , gdzie podejście do projektowania testów rozpoczyna się przed utworzeniem kompilacji. W ten sposób pomaga w znajdowaniu i naprawianiu błędów przed kompilacją.
• Podejście reaktywne , gdzie podejście do testowania rozpoczyna się po zakończeniu projektowania i kodowania testów.

P # 7) Wyjaśnij różnicę między kontrolą jakości a zapewnianiem jakości.

Odpowiedź: 'Kontrola jakości' i 'Zapewnienie jakości' to dwa główne terminy używane w odniesieniu do dowolnego projektu testowego lub produktu. Zazwyczaj testerzy, którzy są nowicjuszami w tej dziedzinie, nie rozumieją rzeczywistej różnicy między nimi.

Zrozummy różnicę za pomocą poniższej tabeli.

P # 8) Według ciebie, kiedy jest dobry moment na rozpoczęcie kontroli jakości w projekcie?

Odpowiedź: Zgodnie z cyklem życia oprogramowania (SDLC), faza testowania jest wykonywana po zakończeniu fazy „wdrażania i kodowania”. Jednak w dzisiejszym scenariuszu, aby osiągnąć najlepsze wyniki, należy rozpocząć kontrolę jakości projektu lub produktu na początku projektu.

Postępowanie zgodnie z tym podejściem doprowadzi do głównych zalet przedstawionych poniżej:

• Wczesne planowanie procesu w celu spełnienia oczekiwań jakościowych klienta.
• Dobra i zdrowa komunikacja między zespołami.
• Daje wystarczającą ilość czasu potrzebnego na skonfigurowanie środowiska testowego.
• Umożliwia wczesne przeglądanie i zatwierdzanie planów testów.

Pytanie 9) Zróżnicuj procesy weryfikacji i walidacji.

Odpowiedź: Procesy weryfikacji i walidacji są zwykle określane przez dwa znane pytania, tj. „ Czy budujemy system, prawda? ” i „Czy tworzymy właściwy system?” .

Zobaczmy inną różnicę między tymi dwoma procesami w poniższej tabeli:

P # 10) Wyjaśnij zalety testów niszczących.

Odpowiedź: Testowanie niszczące definiuje się jako formę testów przeprowadzanych przez zespół testujący w celu określenia punktu uszkodzenia produktu przy różnych obciążeniach, tj. W celu oceny wydajności strukturalnej aplikacji w celu określenia jego wytrzymałości, twardości, twardości lub, powiedzmy, odporności.

Poniżej wymieniono zalety testów niszczących:

• Określa się słabość projektu aplikacji.
• Określ żywotność aplikacji.
• Pomaga zmniejszyć koszty i awarie.

P # 11) Czym różni się ponowne testowanie od testowania regresyjnego?

Odpowiedź: Istnieje kilka różnic między ponownym testowaniem a testami regresyjnymi.

Można to łatwo zrozumieć na podstawie poniższej tabeli:

P # 12) Co wiesz o testowaniu opartym na danych?

Odpowiedź: Dla każdego testera automatyzacji jest bardzo jasne, że skrypty testów automatyzacji obejmują tylko obszar testowanej aplikacji z zarejestrowaną sekwencją działań użytkownika. Zwykle te działania nie powodują żadnego błędu, ponieważ tylko te dane wejściowe są podejmowane w warunkach, które wprowadziliśmy podczas nagrywania.

W tym miejscu pojawia się testowanie oparte na danych, w którym chcemy, aby aplikacja działała zgodnie z oczekiwaniami dla dowolnego typu wartości wejściowych. W tym celu dane wymagane do testowania opartego na danych nie są zakodowane na stałe, ale skrypty testowe pobierają dane ze źródeł danych, takich jak pliki CSV, źródła ODBC itp.

Podsumowując, testowanie oparte na danych wykonuje w pętli następujące działania:

• Pobiera wejściowe dane testowe z pamięci.
• Dane wprowadzone we wniosku w celu wykonania czynności.
• Sprawdź rzeczywiste wyniki z oczekiwanymi.
• Ponownie powtórz te same kroki z nowymi wejściowymi danymi testowymi.

P # 13) Co to jest macierz identyfikowalności? Czy jest to wymagane przy każdym projekcie?

Odpowiedź: Matryca identyfikowalności w każdym projekcie to sposób na śledzenie postępów projektu w zakresie wdrażania nowych funkcjonalności, ulepszania istniejących funkcjonalności itp. Dzięki macierzy identyfikowalności możesz zawsze mieć oko na postęp projektu, a każdy aspekt jest utrzymywany zgodnie z datę.

Macierz śledzenia wymagań składa się z poniższych parametrów, które są zgodne z dokumentem specyfikacji wymagań.

Parametry macierzy śledzenia wymagań obejmują:

• Każda sekcja dokumentu wymagań jest punktem, który należy uwzględnić w RTM (macierz śledzenia wymagań).
• Nagłówek każdego punktu jest nagłówkiem każdej sekcji w specyfikacji wymagań.
• Odpowiadając każdemu punktowi, wymienione są identyfikatory przypadków testowych, które są napisane dla tej konkretnej sekcji.
• BUG / nowy identyfikator funkcji jest również wymieniony w każdej sekcji.
• Najważniejsze jest to, że zachowane jest również śledzenie funkcji, w której zaimplementowano kompilację projektu i jego funkcję.
• Kolejny parametr dotyczy tego, czy sekcja jest w pełni przetestowana, czy nadal znajduje się w stanie testowania.

Q # 14) Opisz zalety testowania zwinnego.

Odpowiedź: Będąc testerem, skupiamy się na dostarczaniu wysokiej jakości produktu w krótszym czasie dzięki zrozumieniu wymagań użytkownika końcowego i, co najważniejsze, brakowi wad po stronie użytkownika końcowego. Tutaj pojawia się testowanie zwinne, które jest zgodne z zasadą zwinnego tworzenia oprogramowania i szybko weryfikuje wymagania klienta.

Poniżej wymieniono zalety testów Agile:

• Testowanie obejmuje wielofunkcyjny zespół zwinny, który z kolei dostarcza wyniki w częstych odstępach czasu.
• Oszczędza dużo czasu i pieniędzy.
• Obejmuje mniej dokumentacji i od czasu do czasu informacje zwrotne od użytkownika końcowego.
• Nie tylko tester, ale cały zespół, w tym menedżer, klient i programista, są zaangażowani w komunikację twarzą w twarz.
• W wyniku codziennych spotkań problemy można z wyprzedzeniem dobrze określić.
• Zwiększenie produktywności zespołu i lepsze zrozumienie technicznych aspektów projektu.

P # 15) Co to jest test negatywny?

Odpowiedź: Testowanie negatywne to metoda zapewniająca, że ​​stabilność produktu lub aplikacji zostanie zachowana lub powiedzą, że nie zawiodą, gdy podano nieoczekiwane dane wejściowe. Głównym celem tej formy testowania jest weryfikacja aplikacji pod kątem ewentualnych nieprawidłowych danych wejściowych.

Ta forma testowania jest również znana jako „Testowanie błędów” lub „testowanie ścieżki błędów” a jego głównym celem jest sprawdzenie niezawodności funkcji aplikacji w negatywnych scenariuszach. Ujawnia również słabość oprogramowania, wykrywa błędy i daje jasny obraz uszkodzenia danych.

P # 16) Jak odróżnić testy ad hoc od testów eksploracyjnych?

Odpowiedź: Istnieje kilka różnic między testowaniem ad hoc a testowaniem eksploracyjnym.

Zobaczmy różnice w poniższej tabeli:

P # 17) Dlaczego testy automatyczne są preferowane w stosunku do testów ręcznych?

Odpowiedź: Cóż, zarówno testy automatyczne, jak i testy ręczne mają swoje znaczenie i istnienie w świecie testów.

Poniżej przedstawiono kilka ważnych aspektów, z powodu których testy automatyczne są preferowane w stosunku do testów ręcznych:

implementacja algorytmu dijkstry w java

• Ten sam skrypt testowy może być używany za każdym razem do uruchomienia testu, dlatego testy automatyczne są uważane za najbardziej niezawodne i wydajne.
• Najczęściej preferowane w przypadku testów regresyjnych i wielokrotnych wykonań.
• Testowanie automatyczne jest uważane za opłacalne w przypadku długoterminowej realizacji, a tym samym zapewnia lepszą jakość oprogramowania.
• Skrypty testowe są wielokrotnego użytku, szybkie i każdy może zobaczyć wyniki.
• Narzędzia używane do automatycznego testowania są szybsze i bardziej niezawodne w porównaniu z podejściem ręcznym.

Chociaż kilka innych czynników decyduje o tym, że testowanie automatyczne jest preferowane w stosunku do testowania ręcznego. Powyższe są głównymi czynnikami.

P # 18) Co rozumiesz przez „Test efektywności” i „Test efektywności”?

Odpowiedź: Sprawdź wydajność można zdefiniować jako obliczenie liczby zasobów i kodu testowego wykorzystanych do wykonania lub powiedzmy wykonania określonej funkcji. Określa również liczbę zasobów wykorzystywanych podczas tworzenia oprogramowania.

Można to określić za pomocą wzoru:

Wydajność testu = (Liczba usuniętych usterek / całkowita liczba zgłoszonych usterek) * 100

Test efektywności można zdefiniować jako miarę oceny środowiska testowego i jego wpływu na aplikację. Tutaj ocena klienta jest oceniana, gdy spełniony jest wymóg aplikacji.

Można to określić za pomocą wzoru:

Skuteczność testu = (Liczba znalezionych defektów / Liczba wykonanych przypadków testowych)

Q # 19) Wyjaśnij proces dostosowywania projektu.

Odpowiedź: Dopasowanie projektu to spójny i ciągły proces, który zapewnia, że ​​wykonanie projektu jest prawidłowe i zgodne z wymaganiami biznesowymi. Cały proces obejmuje przeglądanie i modyfikację danych projektu zgodnie z aktualnymi potrzebami operacyjnymi organizacji.

Proces przeglądu odbywa się na poziomie organizacyjnym, ale wdrażanie planów dostosowywania odbywa się na poziomie projektu. Głównym celem i wymaganiami organizacji, a także relacjami z klientami i użytkownikami, są dwa główne czynniki, które należy wziąć pod uwagę w procesie.

Kilka aspektów związanych z celami organizacyjnymi w ramach procesu dostosowywania to:

• Podejscie projektowe
• Strategie
• Kontrole i procesy, których to dotyczy
• Role i obowiązki

P # 20) Jak rozróżniasz priorytet i wagę usterki w projekcie?

Odpowiedź: Zarówno „Priorytet”, jak i „Ważność” są przypisane do błędu w celu kategoryzowania problemów / błędów w kolejności, w jakiej mają być brane do naprawy. Są one oparte na różnych czynnikach.

Rozumiemy więcej wraz z ich różnicami w poniższej tabeli:

P # 21) Dlaczego testy wydajności są konieczne dla każdej aplikacji?

Odpowiedź: Mówiąc prostym językiem, testy wydajnościowe są wykonywane w celu określenia zachowania i odpowiedzi aplikacji w różnych sytuacjach. Pomaga to zebrać informacje dotyczące stabilności aplikacji, skalowalności, szybkości itp.

Przyczyny przeprowadzania testów wydajności można zrozumieć z poniższych punktów:

• Określa czas odpowiedzi i wydajność składnika aplikacji w ramach obciążenia.
• Obliczany jest czas reakcji użytkownika.
• Wymaga doświadczonych programistów z rozbudowanym językiem technicznym.
• Określa zachowanie aplikacji pod obciążeniem, tj. Gdy liczba użytkowników natychmiast rośnie.

P # 22) Co to jest testowanie oparte na specyfikacji?

Odpowiedź: Jak sama nazwa określa, testowanie oparte na specyfikacji odbywa się w oparciu o specyfikację wymagań aplikacji, w której specyfikacje funkcjonalne służą jako podstawa przeprowadzanych testów.

Ta forma testowania jest taka sama, jak „testowanie czarnoskrzynkowe”, gdzie użytkownik wprowadza wiele danych, a następnie obserwuje wyniki. Jest odpowiedni na wszystkich poziomach testowania wraz ze specyfikacją i planem testów.

Q # 23) Wyjaśnij CMMI.

Odpowiedź: CMMI to skrót od Capability Maturity Model Integration. Model ten został opracowany przez Software Engineering Institute (SEI). Opiera się na zasadzie, że procesy związane z zarządzaniem i rozwojem produktu lub systemu określają jakość.

Zawiera również wytyczne dotyczące doskonalenia procesów dla produktu, a nawet całej organizacji.

CMMI jest podzielona na 5 poziomów, jak wymieniono poniżej:

• Poziom 1: Inicjał
• Poziom 2: Zarządzane
• Poziom 3: Zdefiniowany
• Poziom 4: Zarządzane ilościowo
• Poziom 5: Zoptymalizowany

Q # 24) Wyjaśnij zalety wdrożenia CMMI.

Odpowiedź: Wdrażanie CMMI ma kilka zalet.

Są one wymienione w następujący sposób:

• Zapewnia szczegółowy opis i raportowanie cyklu życia produktu, a tym samym pomaga w ulepszaniu procesów.
• W ramach wdrożenia CMMI doskonalimy istniejące standardy organizacji, ich procesy i procedury.
• W wyniku wdrożenia CMMI następuje wzrost terminowości dostaw oraz satysfakcji klientów.
• Prowadzi również do efektywnego zarządzania i zwiększonych oszczędności kosztów, ponieważ występuje wczesne wykrywanie błędów.

Q # 25) Zdobądź kilka narzędzi do testowania automatyzacji.

Odpowiedź: Poniżej wymieniono niektóre z narzędzi do testowania automatyzacji:

• Selen
• woda
• Wiatrak
• MYDŁO
• Tellur

P # 26) Czy możemy przeprowadzać testy regresji w testach jednostkowych?

Odpowiedź: Zdecydowanie. Testowanie regresyjne ma na celu przetestowanie niepożądanego defektu, który mógł zostać wprowadzony do kodu jako efekt uboczny naprawy innych defektów. Testowanie jednostkowe polega na wykonaniu testu polegającego na uruchomieniu małej, niezależnej i indywidualnej części kodu.

Testowanie regresyjne można przeprowadzić na dowolnym poziomie, od testowania jednostkowego, przez testy integracyjne, aż po testy akceptacyjne. Testowanie regresyjne to testowanie oparte na perspektywie, podczas gdy testowanie jednostkowe jest podejściem poziomowym (oddolne, odgórne).

Pytanie nr 27) Jaka jest różnica między testami dymu a testami zdrowia psychicznego?

Odpowiedź:

• Testowanie dymu to testowanie starych, wyróżniających się funkcji lub istniejących funkcji kompilacji, podczas gdy testowanie Sanity polega na sprawdzaniu nowo dodanych modułów i naprawieniu usterek w kompilacji.
• Testowanie dymu odbywa się najpierw, a następnie test poczytalności.
• Testowanie dymu obejmuje testowanie krytycznych funkcji obsługiwanych przez oprogramowanie, więc obejmuje całe oprogramowanie. Z drugiej strony testowanie poczytalności jest zawężone tylko do ostatnio dodanych modułów i jest dogłębnie testowane.

Pytanie nr 28) Jakie są Twoje codzienne czynności jako tester manualny w Twoim biurze?

Podręcznik: Pierwszą rzeczą, którą sprawdzam w swoim systemie, jest odświeżenie dashboardu pod kątem stanu wymagań / ulepszeń lub błędów w bieżącej iteracji. Po nim odbywają się codzienne rozmowy i raportowanie, dyskusje i burze mózgów w celu zdefiniowania scenariuszy testowych i przypadków testowych.

Sprawy te są następnie wykonywane po przeredagowaniu zgodnie z przeglądem. Współpraca z klientami w przypadku wymagań niefunkcjonalnych jest również jednym z głównych działań na moim talerzu.

Pytanie # 29) Jakie są Twoje codzienne czynności jako członek testera automatyzacji w Twoim biurze?

Automatyzacja: Mój dzień zaczyna się od codziennego spotkania statusowego, na którym omawiane są wczorajsze wyniki automatyzacji, na wypadek, gdyby uruchomiłem partię przypadków testowych na nowej kompilacji.

Cykl wykonywania można nazwać kontrolą stanu, aby sprawdzić, jak zdrowa jest kompilacja.

Następnie następuje raportowanie defektów na podstawie błędów skryptów, zmiany projektowe w funkcjonalności; utrzymywać skrypty / biblioteki lub funkcje, automatyzować i wprowadzać nowy skrypt dla nowych wymagań oraz, jeśli jest to wymagane, nową funkcję w bibliotece funkcji.

Czasami skrypty testowe muszą być ponownie wykonywane indywidualnie, aby znaleźć defekty regresji za pomocą automatyzacji i dodać je również do zestawu testów.

P # 30) W jaki sposób odróżniasz wymaganie od defektu i ulepszenia?

Odpowiedź : DO wymaganie to historia użytkownika, która jest niezbędna do wdrożenia, przetestowania i dostarczenia.
Na wzmocnienie jest dodaną lub zaimprowizowaną funkcją do już istniejącej.
DO wada jest raczej całkowitym odstępstwem od oczekiwanych historyjek użytkowników.

Ponadto, jeśli defekt odsłania pewien obszar wymagania, który nie jest określony, chyba że w specyfikacji jest inaczej, można go również nazwać wymaganiem lub jego częścią.

Pytanie # 31) Co robisz, gdy programista zaprzecza naprawieniu zgłoszonego przez Ciebie błędu?

Odpowiedź : Ważnym czynnikiem decydującym o naprawieniu usterki jest przypisany jej „priorytet”. Jeśli wada ma wysoki priorytet, blokada pokazu, która blokuje główną funkcjonalność i jest konsekwentnie odtwarzana, należy ją naprawić w kompilacji.

To samo należy skutecznie przekazać programistom, ponieważ testerzy i programiści wspólnie przyczyniają się do jakości dostarczanego produktu.

Inne aspekty, które mogą pomóc przekonać programistę do naprawienia błędu w krótkim czasie, to jakościowe zgłaszanie błędu i sprawienie, że programiści zrozumieją, że naprawienie błędu ma pierwszorzędne znaczenie w wydaniu.

Pytanie # 32) Co robisz, gdy programista zaprzecza, że ​​to, co złożyłeś, JEST BŁĘDEM?

Odpowiedź : Najważniejszym etapem cyklu życia usterki jest „Odrzucenie”, co oznacza, że ​​zarejestrowany raport incydentu nie jest prawidłowy. Dokument wymagań biznesowych, który określa wymagania, może pomóc w zrozumieniu oprogramowania, a tym samym natury zgłoszonego incydentu.

Przeanalizuj błąd i ujawnij swoje wyniki dotyczące błędu programistom i zespołowi. Jeśli jest to usterka, nigdy nie zapominaj o niej. Czasami testerzy muszą dostarczyć analizę luk i przedstawić ją programistom. Jeśli to nie rozwiąże konfliktów, starsi ludzie w zespole powinni się do tego przyłączyć.

Pytanie # 33) Co jest najpierw ponowne testowanie lub testy regresyjne?

Odpowiedź : Ponowne testowanie jest pierwsze, ponieważ jest to ponowne uruchomienie kodu, mówiąc prościej, jest to powtórzenie wykonania wstępnie zdefiniowanych kroków. Po ustaleniu kodu nie musi to być konieczne. Ale test regresji ma na celu ocenę skutków ubocznych rozwiązanej wady.

Z pewnością usunięcie jednego błędu i dodanie kolejnego do kodu nie jest celem procesu testowania. Najlepsze znaleziska i najlepsze złapania testerów to zwykle defekty regresji. Kompilacji nigdy nie należy wydawać bez testu regresji.

Pytanie # 34) Jaka jest alternatywa dla testów beta?

Odpowiedź : Beta testy odbywają się w siedzibie klienta przy najmniejszym zaangażowaniu programistów, rejestrując awarie w rzeczywistym środowisku produkcyjnym. Jeśli taka praktyka nie jest wykonywana przez firmę, bezpieczniejszym pomysłem może być wysłanie produktu najpierw do klientów, którzy nie stoją w kolejce po najnowszą wersję.

Niektórzy konsultanci serwisowi w siedzibie klienta mogą przez kilka dni korzystać z oprogramowania, rejestrować i monitorować działania, które zapewniają stabilność wydania w ich środowisku, tak aby nawet w przypadku pominięcia poważnego błędu do naprawienia można było przetestować go wcześniej dostarczenie go do docelowego klienta. Innym podejściem jest zamiana testowania wymagań w zespole na obiektywne testowanie.

Q # 35) Jakie są wady wdrożenia / metodologii Agile, z którymi się spotkałeś?

Odpowiedź : Wady są następujące:

1. Sprinty są zwykle bardzo ograniczone terminowo.
2. Dokumentacja nie jest priorytetem
3. Przełączanie między PBI (elementami rejestru produktu) może być częste.

Pytanie # 36) Dlaczego analiza wpływu jest ważna?

Odpowiedź : Aby praktykować oparte na ryzyku, należy przeprowadzić analizę wpływu. W ten sposób przypadki testowe można zaprojektować w taki sposób, aby wszystkie poważne błędy, krytyczne z punktu widzenia klienta, mogły zostać usunięte przed upływem czasu. Należy dokładnie zbadać biznes, potrzeby klienta i sposób korzystania z oprogramowania.

Na przykład, Najważniejszym ryzykiem związanym z oprogramowaniem z domeny bankowej jest bezpieczeństwo. Każdy nowy formularz dodany do już istniejącego oprogramowania może być podatny na ataki. Zaleca się przeprowadzenie dużej ilości testów bezpieczeństwa poprzez dodanie odpowiednich linków, przekierowań i nawigacji do odpowiedniej strony, aw razie potrzeby zainstalowanie serwera proxy.

Pytanie nr 37) Na przykładzie każdego testu wydajności, testu obciążenia i testu obciążenia?

Odpowiedź : Najlepszym przypadkiem, jaki można zastosować, jest działająca witryna internetowa.

Test wydajności odbywa się w celu zweryfikowania usterek w systemie, gdy przechodzi on stan podobny do scenariusza w czasie rzeczywistym. Nie ma potrzeby wykonywania go w warunkach skrajnych. Wyniki testów wydajności pomagają ustalić, czy system jest gotowy do produkcji.

W przypadku prostego procesu rezerwacji biletów problem z wydajnością mógł spowodować spowolnienie. Na przykład niektóre zapytania używające złączeń są nieco wolniejsze, ponieważ zaimplementowano niepotrzebną klauzulę lub niewłaściwe przechowywanie danych w bazie danych.

Test naprężeń to rodzaj testów wydajnościowych, które są wykonywane przez umieszczanie oprogramowania w ekstremalnych warunkach (duże i nierozdzielone obciążenia, ograniczone zasoby obliczeniowe, wysoka współbieżność).

Jeśli system wykazuje określone zachowanie, takie jak utrata lub uszkodzenie danych, wykorzystanie zasobów nawet po usunięciu stresu, brak reakcji lub nieobsłużone wyjątki, oznacza to, że nie przeszedł testów warunków skrajnych. Czasami wynikiem może być również awaria dysku, niepotrzebny wzrost liczby GDI.

Na przykład, Jeśli witryna hostowana na komputerze, który już zużywa ogromną pamięć lub bombarduje ją powtarzającymi się żądaniami, nie powinna się zawieszać ani wylogowywać.

Testowanie obciążenia obserwuje zachowanie systemu, stale zwiększając obciążenie systemu, aż do osiągnięcia progu. Modele obciążenia, metryki i poziomy obciążenia są zwykle danymi wejściowymi do testowania obciążenia.

Na przykład, czas na uzyskanie wolnych miejsc w pociągu stopniowo wydłuża się wraz ze zbliżaniem się terminu rezerwacji limitu Tatkal, ponieważ liczba użytkowników zalogowanych do systemu rośnie wraz z czasem rezerwacji Tatkal zbliżającym się do 10 rano lub 11 rano.

Pytanie nr 38) Co było jednym z największych wyzwań podczas wykonywania testów regresji?

Odpowiedź : Podczas wykonywania testów regresji mogą wystąpić różne wyzwania.

• Wielokrotne wykonywanie testów może nie być tak ekscytujące dla testerów.
• Czasochłonne, ponieważ czasami takie testy wymagają nieszablonowego myślenia.
• Naruszona wartość biznesowa.
• Nieprawidłowy dobór przypadków testowych regresji może spowodować pominięcie poważnego defektu regresji, który można znaleźć.
• Powielanie defektu w produkcji staje się zatem niespójne.
• Duży apartament do wykonania.

Q # 39) Jeśli zostaniesz poproszony o udokumentowanie scenariuszy testowych, przypadków testowych, planów testów, strategii testów, od czego zaczniesz i w jakiej kolejności nastąpi reszta?

Odpowiedź : Sekwencja będzie składać się z strategii testów, planu testów, scenariuszy testowych i wreszcie przypadków testowych.

Pytanie nr 40) A jeśli brakuje mi udokumentowania któregokolwiek z powyższych? Powiedz, że brakuje mi dokumentowania planu testów, jakie będą konsekwencje?

Odpowiedź : Jeśli pominiemy udokumentowanie planu testów, powstanie luka w zakresie testowania jego obiektywnego podejścia i nacisku na testowanie. Trudno będzie wówczas określić funkcje do przetestowania, techniki testowania, kryteria zaliczenia lub odrzucenia, a ostatecznie główne ryzyko związane z testowaniem.

Pytanie # 41) Jak zacząłbyś testować wersję, którą niedawno otrzymałeś: czy jest jakieś podejście, które stosujesz, np. najpierw rozpocząć testy dymu, potem testy poczytalności?

Odpowiedź : Testy dymu> Testy normalności> Testy eksploracyjne> Testowanie funkcjonalności> Testy regresyjne i walidacja produktu końcowego.

Pytanie nr 42) Wyjaśnij format raportu o błędzie, który zastosowałeś?

Odpowiedź :

Zgłoszenie błędu powinno zawierać następujące informacje:

• Identyfikator błędu
• Mapowanie do wymagania / rozszerzenia / istniejącego błędu
• Podsumowanie / tytuł błędu
• Wersja produktu
• Priorytet
• Konfiguracja (specyfikacja systemu)
• Wymagania wstępne
• Kroki
• Spodziewany rezultat
• Rzeczywisty wynik
• Dzienniki. Migawki, klipy wideo
• Status
• Inne uwagi

Pytanie # 43) Jak wybrać przypadki testowe regresji lub utworzyć zestaw testów regresji?

Odpowiedź : Tak. Jest to wynik analizy wpływu. Jest to proste mapowanie funkcji używanych lub do których uzyskiwany jest dostęp w różnych obszarach, które testujesz, integracja z innymi funkcjami oraz w ramach całego systemu lub testowania przepływu.

Możesz także pobrać usterki zgłoszone wcześniej dla tej samej funkcji w poprzednich kompilacjach. W idealnym przypadku jeden defekt powinien zostać przetestowany regresyjnie przy użyciu co najmniej pięciu różnych przypadków testowych korzystających z tej funkcji.

Pytanie # 44) Czy możesz podać przykład następujących usterek

• Usterka o niskim priorytecie o wysokim stopniu ważności
• Wada o wysokim priorytecie i małej wadze

Odpowiedź : Defekt powodujący awarię aplikacji, gdy jest odtwarzany tylko w określonym sygnaturze czasowej w określonym systemie operacyjnym, może być defektem o wysokim poziomie istotności i niskim priorytecie.

Wada zgłoszona wobec widoku, który nie otwiera się po dwukrotnym kliknięciu, ale otwiera się po kliknięciu prawym przyciskiem myszy, może być defektem o wysokim priorytecie i niskim poziomie ważności.

Q # 45) Napisz jeden skuteczny przypadek testowy, aby sprawdzić, czy dany artykuł jest białym papierem?

Odpowiedź: Jeśli kolor tuszu źródłowego, którym piszesz na białym papierze, pozostaje taki sam, to papier jest biały. Na przykład, jeśli piszesz na białym papierze czerwonym tuszem, kolor tuszu pozostaje czerwony w piórze i wydaje się czerwony również na papierze.

Uwaga: Istnieje wiele innych odpowiedzi na to pytanie. Możesz zacząć myśleć o każdej takiej ważnej odpowiedzi, opierając się na logice.

Pytanie # 46) Co to jest testowanie karty?

Odpowiedź: Testowanie sesji wykonywane w oparciu o cele i programy wymienione w karcie przed rozpoczęciem testów nosi nazwę testowania karty.

Testowanie tutaj odbywa się w ustalonym przedziale czasowym, z mniejszym naciskiem na dokumentację, a bardziej z samym testowaniem. Jest to inny wariant testowania eksploracyjnego, w którym inżynierowie testów weryfikują oprogramowanie w ramach czasowych ( Na przykład, zaledwie 2 godziny) na podstawie opracowanych heurystyk.

Pytanie nr 47) Jakie jest Twoje podejście, gdy masz wydanie o wysokim priorytecie, które ma zostać dostarczone w bardzo krótkim czasie?

Odpowiedź: W takich przypadkach dobrze przemyślany plan może być korzystny.

Aby wspomóc testowanie w scenariuszu braku czasu, można wykonać następujące czynności: -

• Korzystanie z istniejących zaktualizowanych skryptów automatyzacji do wykonywania testów regresji.
• Testowanie scenariuszy opartych na przepływie od końca do końca.
• Wykonywanie przypadków testowych o wysokim priorytecie i jeśli pozwoli na to czas, przełącz się na przypadki o niższym priorytecie.
• Ponowne przetestowanie błędów o wysokim priorytecie zgłoszonych w poprzednich wersjach.
• Szybkie testowanie oprogramowania
• Deweloperzy mogą zostać poproszeni o uruchomienie testów jednostkowych, aby uzyskać więcej pokrycia w testowaniu.

Pytanie # 48) Napisz przypadki testowe na dowolnym urządzeniu / obiekcie obecnym w pobliżu (przykład: krzesło)?

Odpowiedź: Oto rada: Zawsze zaczynaj od zebrania wymagań. Pokazuje dojrzałość do cyklu życia oprogramowania. Zapraszam do zadawania pytań po wybraniu obiektu.

W tym przypadku:-

• Jaki to rodzaj krzesła? Krzesło biurowe, stół do nauki, sofa, stół do jadalni, wygodne krzesło?
• Z jakiego materiału jest wykonane krzesło - drewno, stal, plastik, tapicerka?
• Zapytaj o wymiary (wysokość, waga w zależności od typu krzesła).
• Zapytaj o dostępność. I na tej podstawie zacznij przygotowywać swoje sprawy.

Przypadki testowe będą się różnić dla każdego rodzaju krzesła, co lepiej pozostawić dla zdolności myślenia ( Na przykład, przeznaczenie krzesła, wymiary w zależności od typu krzesła, przenośne-niezdatne do picia, lekkie, możliwość zakupu).

Dla każdego krzesła: a przypadek testu wydajności może być: w celu określenia wytrzymałości na rozciąganie lub maksymalnej nośności.

Q # 49) Czy wszystko można zautomatyzować?

Odpowiedź: - Do pewnego stopnia tak. Ale narzędzia automatyzacji, podobnie jak inne oprogramowanie, mają swoje ograniczenia. Ponadto testowane oprogramowanie lub testowana aplikacja będzie nadal aktualizowana.

Nie ma więc gwarancji, że testowanie oprogramowania można przeprowadzić bez ręcznej interwencji. W końcu narzędzie jest równie sprytne, jak tester. To tylko testowanie innego oprogramowania. To kod / skrypty / biblioteki muszą być wystarczająco inteligentne, aby testować i znajdować usterki.

Wniosek

Mam nadzieję, że to ćwiczenie pomoże ci się rozgrzać, zadając kilka pytań i da ci świetny start do rozmów kwalifikacyjnych i zwiększy pewność siebie podczas odpowiadania na pytania. Mogą również pojawić się inne pytania oparte na scenariuszach, które mogą wynikać z Twojego CV / profilu.

Dlatego zawsze dobrze jest przećwiczyć próbną rozmowę kwalifikacyjną z własnym wyprzedzeniem, tak aby rozmowa kwalifikacyjna okazała się korzystna zarówno dla osoby przeprowadzającej rozmowę, jak i kandydata. Pamiętaj, że analityk ds. Jakości to coś więcej niż inżynier testów, którego opinie są ważne nie tylko dla jakości produktu, ale także dla procesu testowania oprogramowania.

Dziękuję i życzę powodzenia w udzielaniu wywiadów!

rekomendowane lektury

• Pytania i odpowiedzi do wywiadu
• Ponad 25 najpopularniejszych pytań i odpowiedzi do wywiadów ADO.NET
• 25 najlepszych pytań i odpowiedzi na rozmowę z testami zwinnymi
• Pytania do wywiadu Spocka z odpowiedziami (najpopularniejsze)
• ETL Pytania i odpowiedzi podczas rozmowy kwalifikacyjnej testującej
• 20 najpopularniejszych pytań i odpowiedzi do wywiadów TestNG
• Top 30+ popularnych pytań i odpowiedzi do wywiadów z ogórkami
• 50 najpopularniejszych pytań i odpowiedzi do wywiadów CCNA