Zamówienie / obsługa tysięcy usterek tuż przed wydaniem
To pytanie zostało mi zadane w rozmowie z naprawdę dobrą firmą, poniżej podam je w formie naszej interakcji (M: ja i ja: ankieter), choć nie ma ostatecznych odpowiedzi, ale muszę wiedzieć, co pomysł / odpowiedź, której ankieter naprawdę chciał :
I: Scenariusz jest taki, że ty i 2 inne osoby składacie się z zespołu testującego. Ty, lider, jesteś jedyną osobą, która może wykonywać automatyzację, inni mogą wykonywać tylko testy ręczne. Masz prawie 10 000 zgłoszonych błędów i masz 4-5 tygodni lub mniej, zanim ten produkt zostanie dostarczony. Co zrobisz, aby produkt dotarł na czas?
M: Przefiltruj priorytetowo błędy i przetestuj je ponownie. W międzyczasie prowadź dziennik o tym, jakie funkcje są bardziej regresowane i zacznij je automatyzować. Podobne lub powiązane błędy zostaną przekazane innym do dalszych testów.
I: Załóżmy, że żaden z błędów nie został oznaczony z żadnym priorytetem. Co zrobisz?
M: Będę filtrować według dat. W każdym rodzaju SDLC, nawet zwinnym, najpierw opracowywane są podstawowe komponenty, jeśli są podstawowe błędy, należy je najpierw naprawić.
I: (z dezaprobatą) A co, jeśli bardzo ważna funkcja zostanie dodana w późniejszym sprincie? Również w jaki sposób wykorzystasz swoich kolegów z zespołu i swoją zdolność do automatyzacji.
M: Wraz z datą, jako tester będę musiał znać podstawowe i ważne funkcje produktu do daty, więc mając to na uwadze, znajdę główne obszary każdego sprintu do pracy (o współpracownikach odpowiedział to samo jak wcześniej).
I: Powiedzmy, że błędy nie zostały zaznaczone na osi czasu każdego sprintu. Co zrobisz?
M: Przeszukam listę błędów za pomocą słów kluczowych, które reprezentują ważne funkcje, bez których produkt nie może zostać wydany. Stamtąd wybiorę błędy.
I: (znowu z dezaprobatą) Dzięki słowu kluczowemu uzyskasz tak wiele wyników, czy przejrzysz je jeden po drugim?
M: (powoli tracąc nadzieję) Przejdę tylko przez tytuł i zdecyduję.
I: Ogólnie tytuły nie są tak objaśniające, jak sobie z tym poradzisz?
M: Sam zacznę testować produkt i szukać podobnych błędów, z którymi się spotykam, zamiast próbować przeglądać błędy, ponieważ muszę podjąć decyzję o dostawie produktu.
I: Więc zignorujesz te wiele błędów? Zainteresowane strony mogą się nie zgodzić. (Po tym całkowicie zgubiłem to i po prostu dalej gadałem i nie pamiętam, o co jeszcze pytano, również wszędzie pytano o zarządzanie / pracę 2 innych testerów manualnych)
To był wywiad dla Sr SDET.
Odpowiedzi
Oprócz tego, co powiedziały inne odpowiedzi, powiedziałbym, że ankieter szuka sposobu, w jaki Ty, jako nowy członek zespołu, poradzisz sobie z sytuacją, w której nie ma wygranej. Szczerze mówiąc, podejrzewam, że - przynajmniej - firma znalazła się w tego rodzaju sytuacji w przeszłości. W najgorszym przypadku (przyznaję, że jestem cyniczny) coś podobnego stanie przed kimkolwiek, kto zajmie stanowisko.
Jako ankieter chciałbym czegoś takiego od osoby, z którą rozmawiałem:
Po pierwsze, chciałbym wiedzieć, w jaki sposób są zorganizowane te błędy, w szczególności ich priorytet, powaga i ryzyko. Zakładam, że wchodzę w tę sytuację, a nie że jestem w nią zaangażowany od samego początku, ponieważ tego rodzaju sytuacja sugeruje, że gdzieś źle się stało.
Jeśli błędy nie są zorganizowane w sposób, który obejmuje priorytet, wagę i ryzyko, chciałbym porozmawiać z innymi testerami, zarządzaniem projektem i programistami, aby ustalić, jakie problemy znają, a które stanowią największe ryzyko dla planowanego wdrożenia data.
Jeśli istnieje taka organizacja, chciałbym porozmawiać z testerami, zarządzaniem projektami i programistami, aby potwierdzić błędy najwyższego ryzyka. Idealnie, szukałbym sposobu na utworzenie listy błędów, które należy naprawić, zanim produkt będzie mógł zostać wydany. W przypadku 10000 błędów utworzenie tej listy zajmie trochę czasu, przy założeniu, że nie ma błędów, których testerzy nie byliby w stanie znaleźć, ponieważ zgłaszane błędy ukrywają je lub blokują.
Gdy już zorientuję się, jak zła jest sytuacja, mogę zdecydować, czy - moim zdaniem - można zwolnić aplikację zgodnie z planem. Jeśli większość błędów wiąże się ze stosunkowo niskim ryzykiem, a błędy wysokiego ryzyka wydają się być w miarę łatwe do naprawienia, skupiłbym swój zespół na błędach wysokiego ryzyka i współpracowałbym z kierownikiem projektu i każdym innym zespołem, aby uzyskać najwyższe ryzyko (duża waga, najczęściej występująca w terenie i / lub blokowanie obszarów aplikacji) naprawione i przetestowane błędy.
Jeśli nie widzę sposobu na wydanie produktu na czas, zaczynam rozmawiać z kierownikiem projektu i szefem, aby sprawdzić, czy jest sposób na wykonanie ograniczonej wersji beta solidnej funkcjonalności lub na opóźnienie wydania. Ponieważ jestem nowy na tym stanowisku, nie wiem, czy są jakieś wymagania kontraktowe lub inne czynniki, na które nie mam wpływu, które mogłyby spowodować, że data zwolnienia byłaby nieruchoma.
Upewniłbym się również, że po wydaniu umówiłem się z liderami wszystkich zaangażowanych zespołów, aby ustalić, jak doszło do takiej sytuacji i jakie działania możemy podjąć, aby temu zapobiec, a także jak możemy razem pracować obniżyć listę błędów.
Zauważ, że nic z tego nie ma nic wspólnego z rolą SDET. Z pytania jasno wynika, że ankieter oczekuje, że SDET będzie również pełnił rolę lidera testowego - nie sądzę, aby to było szczególnie dobre i szczerze mówiąc, chciałbym wiedzieć, czy jest to coś, czego firma oczekuje od swojego SDET.
Warto pamiętać, że chociaż wywiady są sytuacjami silnie stresującymi, staraj się myśleć w ukryciu i przyjrzeć się implikacjom zadawanych pytań, zamiast nurkować. Jest to trudne, ponieważ jesteś zestresowany i starasz się dać z siebie wszystko, ale jeśli możesz poświęcić trochę czasu, aby w myślach zadać sobie pytanie, czego poszukuje osoba przeprowadzająca rozmowę z pytaniem, zazwyczaj możesz udzielić lepszej odpowiedzi.
Pierwsza rzecz, która przychodzi na myśl, to - czy te testy działały wcześniej? Jeśli tak, to nie panikuj. Coś się zmieniło w bazie kodu lub we frameworku testowym, co prawdopodobnie powoduje niepowodzenie ich grup. Wyśledź to i sprawdź, czy możesz wyeliminować kilka tysięcy awarii za jednym razem. Nadal będziesz musiał ponownie ręcznie przeczytać te, które przechodzą, i dwukrotnie je sprawdzić, ale może to zajmie tylko kilka dni.
Gdyby nigdy wcześniej nie były sprawdzane, nadal robiłbym coś podobnego - poszukaj jakichkolwiek wspólnych elementów, które pozwolą ci naprawić duże grupy naraz.
W przeciwnym razie jest tam tak dużo hałasu, że możesz przegapić coś krytycznego, co się nie powiedzie.
Po tym zaakceptuj, że możesz nie być w stanie dotrzeć do wszystkiego i skup się na ścieżce kodu do generowania pieniędzy. Rzeczy, które muszą działać lub biznes się załamuje. Następnie, po usunięciu kilku więcej z nich, co drugi dzień lub trzy spójrz i sprawdź, czy nie ma już zgrupowanych błędów, jak wspomniano wcześniej, i spróbuj usunąć kilka kolejnych grup.
Uwaga: Odpowiadając na to z punktu widzenia SDET - kogoś, kto może samodzielnie naprawić problematyczną bazę kodu.
Jeśli ankieter wspomniał o błędach, a nie o niepowodzeniu testu (jeśli jego test się nie powiódł, zapoznaj się z odpowiedzią @Lewis
Przede wszystkim posiadanie 10000 aktywnych błędów w produkcie to naprawdę duża czerwona flaga.
I nigdy nie powinieneś wypuszczać takiego produktu. Ale jeśli decyzja kierownictwa wciąż ma zostać wydana,
Odpowiedzią, której oczekiwał ankieter, byłaby „ dotkliwość ”
Zespół powinien najpierw skupić się na naprawianiu błędów o dużym znaczeniu, jeśli nie ma priorytetów, i utrzymywać niski poziom po wstrzymaniu, jeśli nie jest to pilne wymaganie i nie wpływa na rzeczywistą logikę biznesową.
Skoncentruj się na początku automatyzacji testu dymu, a następnie zacznij automatyzować wszystkie zestawy regresji
Pogrupuj błędy i zobacz, gdzie ma miejsce ich grupowanie , i rygorystycznie przetestuj ten moduł po wprowadzeniu poprawki.
Przed wydaniem ręcznie przetestuj wszystkie scenariusze testów dymu (logika krytycznych firm)
Ponadto posiadanie 10000 błędów może spowodować maskowanie defektów, gdy te błędy maskują niektóre krytyczne błędy w produkcie.
Dlatego po wprowadzeniu poprawki należy przeprowadzić bardziej rygorystyczne testy wokół modułów, aby znaleźć bardziej krytyczne błędy
więc gdybym był na wywiadzie, odpowiedziałbym:
- 10000 błędów w każdym projekcie byłoby ogromną czerwoną flagą, pokazującą, że nie było odpowiedniego procesu naprawiania błędów i szacowania. Z pewnością martwiłbym się grupowaniem defektów i maskowaniem defektów, co oznacza, że istnieje możliwość, że większość błędów koncentruje się na jednym module, a tak wiele błędów może maskować wszelkie inne krytyczne błędy, które zostaną zidentyfikowane dopiero po dokładnym naprawieniu i ponownym przetestowaniu modułu . Z tego powodu zalecę przesunięcie daty premiery dalej.
Chociaż zespół programistów jest zajęty naprawianiem błędów, zaczniemy automatyzować przypadki użycia testów dymnych i przypadki użycia błędów. Po nadejściu poprawki przydzielaliśmy zadania ponownego testowania testerom ręcznym, a my sami wykonujemy rygorystyczne testy adhoc modułu, aby znaleźć ukryte krytyczne błędy.
- Jeśli nie ma priorytetu, bezczynne byłoby ponowne przeglądanie błędów krytycznych lub o dużym znaczeniu, a także zbadanie czasu życia błędów i zrozumienie, dlaczego błędy nie zostały naprawione tak długo, aby pomóc w ulepszeniu ogólnego procesu w przyszłości.
O błędach o niskiej wadze musimy podjąć zespołową decyzję dotyczącą osi czasu oraz decyzji o wydaniu, czy wydać pierwszą wersję z tymi błędami, ale nadal dokumentując te same i obejścia, jeśli jest to wymagane. Jeśli to możliwe, podaj również datę następnego wydania możliwej poprawki.
Będąc więc starszym QA, powinieneś wyrazić swoją zdecydowaną opinię, aby pozostać „NIE”, gdy widzisz czerwone flagi. Nie bądź zbyt elastyczny
Inne odpowiedzi tutaj są dobre, jeśli chodzi o udzielenie konkretnej odpowiedzi.
Jednak wielu ankieterów zadaje niejasne pytania bez konkretnej odpowiedzi, ponieważ chcą wiedzieć, jak myślisz, lub zrozumieć, czy przyjmujesz przypuszczenia dotyczące pytania. Chcą, abyś zadał im wyjaśniające pytania, aby uzyskać szczegółowe informacje. Pomaga to w uzyskaniu odpowiedzi.
Scenariusz jest taki, że ty i 2 inne osoby składacie się z zespołu testowego. Ty, lider, jesteś jedyną osobą, która może wykonywać automatyzację, inni mogą wykonywać tylko testy ręczne. Masz prawie 10 000 zgłoszonych błędów i masz 4-5 tygodni lub mniej, zanim ten produkt zostanie dostarczony. Co zrobisz, aby produkt dotarł na czas?
Kilka pytań do zadania:
- Jakie doświadczenie mają manualni testerzy QA?
- Czy testerzy manualni mają doświadczenie w tym projekcie? Czy też są nowicjuszami w projekcie?
- Czy wszystkie 10000 trzeba naprawić przed datą dostawy?
- Czy istnieje oprogramowanie do śledzenia błędów używane przez zespoły? Jeśli tak to co?
- W jaki sposób śledzone są znane błędy? Czy mają priorytet i wagę? Czy są pogrupowane / oznaczone według obiektu?
- Czy są obecnie używane jakieś testy automatyczne dla oprogramowania? Jeśli tak, to ile testów jednostkowych, testów integracji, testów interfejsu użytkownika? A może muszę stworzyć od podstaw wszystkie testy automatyczne / framework w okresie 4-5 tygodni?
- Za ile testów są odpowiedzialni programiści? Czy tworzą testy jednostkowe / integracyjne?
- Czy 10000 błędów jest błędami interfejsu użytkownika? A może kombinacja błędów, które można przetestować za pomocą testów jednostkowych, testów integracji, testów interfejsu użytkownika?
- Jakich urządzeń należy użyć do testów?
- Jaki poziom jakości musimy osiągnąć, aby zadowolić użytkowników i interesariuszy? Jak interesariusze postrzegają jakość?
- W jaki sposób interesariusze decydują o pomyślnym uruchomieniu projektu?
- Jaka jest definicja ukończenia zespołu?
- Czy po wydaniu projektu zespół będzie miał czas na naprawienie błędów? A może przechodzimy do następnego projektu? Ile będziemy mieli czasu, jeśli znajdziemy czas?
- Czy zespół używa Agile SDLC czy Waterfall SDLC?
Istnieje nieskończona liczba pytań, które możesz zadać, aby uzyskać wyjaśnienia, których potrzebujesz, aby udzielić dobrze przemyślanej odpowiedzi.
Po szczegółowej rozmowie powyżej, ankieter wciąż podpowiadał, jak włączyć testerów manualnych do swojego planu. Daje to dużą wskazówkę, czego szuka ankieter: nie chcą, abyś wziął na siebie cały ciężar samodzielnego testowania tego projektu; chcą wiedzieć jako starszy inżynier SDET / QA, w jaki sposób jesteś mentorem / prowadzisz zespół młodszych testerów.
Pamiętaj, że wywiady nie powinny być przesłuchaniami, podczas których po prostu odpowiadasz na ich pytania. Wywiady powinny być rozmową, w której można zadać wszystko, co pomoże wyjaśnić ich pytania.