Zatrudniamy osobę odpowiedzialną za kontrolę jakości i mam kilka pytań do rozmowy kwalifikacyjnej. Prawda jest taka, że nie wiem zbyt wiele o tym, co powinien wiedzieć dobry inżynier ds. Kontroli jakości, a tym bardziej o tym, jakie mogą być pytania dotyczące dobrych rozmów kwalifikacyjnych. Czy ktoś ma jakieś sugestie?
Niektóre informacje: Środowisko to dwie osobne (ale powiązane) aplikacje internetowe dla stosu Microsoft (ASP.NET, SQL Server, IIS).
Odpowiedzi:
Jeśli nie masz dużego doświadczenia w pracy z testerami, przeczytaj kilka pierwszych rozdziałów „Testing Computer Software” Cem Kanera, aby zapoznać się z rodzajami terminów, które chcesz usłyszeć: testy graniczne, testy błędów, testy szczęśliwej ścieżki, funkcjonalne, wydajność, bezpieczeństwo, integracja itp. Jeśli nie znasz języka, nie będziesz w stanie przeprowadzić dobrego wywiadu.
Daj im specyfikację dla małego kawałka twojego systemu. Poproś ich o przetestowanie. Szukasz organizacji myśli i ich zdolności do wymyślania ciekawych testów. Chcesz zobaczyć, jak dzielą obszary testowania w uporządkowany sposób, a następnie analizują każdy z nich, opracowując coraz więcej interesujących przypadków testowych. Naprawdę dobrzy testerzy potrafią to robić godzinami ze wszystkimi, oprócz najbardziej trywialnych problemów, więc być może będziesz musiał je odciąć i przenieść do innej kategorii, aby dobrze poznać ich zdanie.
Opisz zachowanie spowodowane prawdziwym błędem w twoim systemie, które było trochę trudne do zrozumienia. Zapytaj ich, co by zrobili, gdyby zobaczyli ten błąd podczas testowania. Tutaj szukasz redukcji błędów - możliwości znalezienia najprostszego zestawu okoliczności, które mogą odtworzyć błąd. To sprawia, że debugowanie jest znacznie łatwiejsze dla programistów, ponieważ lepiej odgadną przyczynę problemu i demonstrują wyraźną zdolność do rozwiązywania problemów oraz jasne zrozumienie czynników, które mogą oddziaływać w celu spowodowania błędów. W przypadku konkretnego produktu omawianie warunków wyścigu może być świetną zabawą.
Daj im prosty program wiersza poleceń, który razem zhakowałeś (być może pełen błędów) i prostą specyfikację, i pozwól im usiąść przy komputerze i bawić się nim w celu znalezienia problemów. Tutaj szukasz kreatywności i umiejętności celowania w obszary problemów. Powinny przetestować takie rzeczy, jak duże dane wejściowe, małe dane wejściowe, dziwne dane wejściowe, puste dane wejściowe. Jeśli znajdą błąd, poproś go, aby spróbował dowiedzieć się, kiedy dokładnie ten błąd się pojawi (ponownie z redukcją błędu!).
Zapytaj ich, co by zrobili, jeśli SDE zareaguje na błąd za pomocą „No Repro” lub „Won't Fix”, jeśli uważają, że błąd jest ważny. Tutaj szukasz kogoś, kto nie będzie tylko popychaczem, ale także nie będzie antagonistą. Rozsądne odpowiedzi obejmują dodanie przykładowych scenariuszy, które wyraźniej pokazują wagę błędu, a następnie ponowne otwarcie biletu, rozmowa z twórcą, aby spróbować zrozumieć, dlaczego rzeczy zostały rozwiązane w ten sposób przed zamknięciem itp.
Porozmawiaj z nimi o swojej aplikacji na wysokim poziomie. Zapytaj ich, jakie testy chcieliby przeprowadzić. Tutaj szukasz ogólnych obszarów testowania, takich jak testy komponentów funkcjonalnych, testy integracji, testy wydajności, testy bezpieczeństwa.
Jeśli jest to inżynier SDET / inżynier automatyki, odpowiedz na kilka pytań do deweloperów z około 1/3 do połowy ich całkowitego doświadczenia.
Jeśli jest to Twoja pierwsza osoba odpowiedzialna za kontrolę jakości, upewnij się, że może ona rozpocząć się sam. Zapytaj ich, jak wyobrażają sobie swój pierwszy tydzień do miesiąca pracy. Powinni powiedzieć coś o zbieraniu wymagań i konfigurowaniu narzędzi, a następnie opisać rozsądne podejście do rozpoczęcia testowania. Szukasz kogoś, kto nie potrzebuje szefa, który powiedziałby mu, jak rozpocząć testowanie i potrafi samodzielnie zarządzać. Jeśli masz już pracowników QA, jest to mniej ważne.
To, co robię, gdy przeprowadzam wywiad z kandydatami do kontroli jakości, to poproszenie ich o opracowanie strategii testowej dla aplikacji. Zwykle daję im mój telefon i wybieram aplikację z ograniczonymi funkcjami - lub pozwalam im wybrać coś, co jest im bardziej znane. Kiedy wymieniają strategię wysokiego poziomu (niektórzy nie mogą), mogę poprosić ich o drążenie w dół i listę kilku przypadków testowych.
Po zakończeniu mogę dać im scenariusz, w którym mamy ograniczone zasoby i zobaczyć, w jaki sposób ustalają priorytety.
Pytam ich również, kiedy oprogramowanie jest wystarczająco dobre do wysyłki, jak radzić sobie z sytuacjami, w których PM lub deweloper nie uważa, że błąd jest ważny, ale robią to. Typowe scenariusze rozwoju produktu.
Są to dla niekodujących pozycji QA. Kodowanie pozycji QA Daję im wywiad / testowanie kombi.
Zapytaj ich, jak zaprojektują plany testów. Zapytaj ich, czy mają doświadczenie w stosowaniu testów regresji i jak to zrobili, jeśli tak. Zapytaj ich, jak sobie radzą z testowaniem interfejsu użytkownika. Zapytaj ich, jak poszliby na testowanie importu danych, które nie przechodzą przez interfejs użytkownika (jeśli robisz takie rzeczy). Zapytaj ich, jak przekażą swoje problemy programistom i jak sprawdzą rozwiązanie problemu. Zapytałbym ich o najciekawszy (lub najtrudniejszy do znalezienia) błąd, jaki znaleźli i jak go znaleźli.
Zanim zaczniesz rozmowę, poszukaj kilku książek na temat testowania i podsumuj, co powinna zrobić osoba odpowiedzialna za kontrolę jakości. To pomoże ci ocenić ich odpowiedzi.
Ponadto szukasz dobrego dopasowania osobowości. Nie chcesz osoby zapewniającej kontrolę jakości, która jest popychaczem, ale nie chcesz też tyranu ani palanta. Ale chcesz kogoś, kto przeciwstawi się zarządzaniu, gdy coś jest nie tak, i nie zatwierdzi wszystko, ponieważ zarząd chce dotrzymać terminu. Chcesz kogoś, kto będzie efektywnie współpracował z programistami i który rozumie wymagania tego, co testują. Ktoś z pewnym doświadczeniem w rodzaju testowanej aplikacji może być dobry. Tester z doświadczeniem w dziedzinie opieki zdrowotnej będzie wiedział o rzeczach, których może nie wiedzieć ktoś pochodzący z innej dziedziny.
Wydaje mi się, że nie można oczekiwać od nich poważnej wiedzy na temat technologii - ktokolwiek najprawdopodobniej odmówi pracy jako zwykły tester.
Najlepsze, co możesz zrobić, to szukać wspólnych rzeczy, takich jak dbałość o szczegóły, dociekliwy umysł, entuzjazm do eksperymentowania i tak dalej.