Pytanie:
Jak mam zareagować jako programista, jeśli przydzielono mi testowanie ręczne?
Kaushal28
2019-10-22 19:23:23 UTC
view on stackexchange narkive permalink

Jestem inżynierem oprogramowania w prywatnej firmie usługowej. Nawet jako programista otrzymujemy na ogół powtarzalne zadania programistyczne.

Dzisiaj mój kierownik poprosił mnie o pomoc w ręcznym testowaniu, aby dotrzymać terminu projektu. Jednak jako programista nienawidzę zadań ręcznych, a zwłaszcza testów ręcznych. (Nie mówię o testach jednostkowych, które powinni wykonać programiści przed przekazaniem kompilacji testerom).

Również opóźnienie projektu wynika z ciągłych zmian w wymaganiach klientów, ale menedżer chce wchłonąć wszystkie takie wysiłki wymagane przez te zmiany i dostarczenie projektu na czas, dlatego prosi programistów o pomoc w testowaniu.

W takich sytuacjach nie mogę powiedzieć, że nie wiem, jak testować, ponieważ natychmiastowa odpowiedź byłaby taka, że ​​testowanie odbywa się zgodnie z instrukcjami zapisanymi w przypadkach testowych.

Jaka więc powinna być odpowiedź w tym przypadku? Nienawidzę testów!

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/100179/discussion-on-question-by-kaushal28-how-should-i-respond-as-a-developer-if-manua).
Pięć odpowiedzi:
rath
2019-10-22 19:36:16 UTC
view on stackexchange narkive permalink

Jeśli to jednorazowa czynność, przeprowadź testy. Twój zespół Cię potrzebuje. QA tonie. Przejmij część ich obciążenia pracą i pozostań z nimi w kontakcie, aby mieć pewność, że wykonujesz swoją pracę i robisz to dobrze.

Po udowodnieniu, że jesteś osobą, na której można polegać w mgnieniu oka, możesz następnie powiedz swojemu przełożonemu, człowieku, czy nienawidzę testów ręcznych , a może będą o tym pamiętać, gdy następnym razem będzie im brakować testerów.

Jedynym sposobem, aby nie robić ręcznych testów testowanie to zajęcie się czymś innym, co ma wyższy priorytet. W przeciwnym razie to twoja praca.

Myślę, że masz rację.To jest przydzielane mi po raz pierwszy.Zrobi to, a następnie poinformuje kierownika.Dzięki
Jedną z największych lekcji do nauczenia się w miejscu pracy jest to, kiedy i jak odpowiadać na prośby o pomoc, które są poza normą - poza godzinami pracy, poza ściśle określonym zakresem obowiązków itp. Z jednej strony chcesz być pomocny..Z drugiej strony nie chcesz się zbytnio rozciągać.Myślę, że ta odpowiedź zasługuje na pochwałę za przyjęcie środkowego podejścia, w którym możesz być pomocny w upale chwili, ale nadal staraj się kierować przyszłością.
Dokładnie.Wykonuj pracę, ponieważ pomaga to zespołowi, ale upewnij się, że Twój szef wie, że nie powinno to być regularną częścią Twojej pracy.Wyjątki w pracy powinny być po prostu wyjątkami.Jeśli te wyjątki będą się powtarzać, albo role zawodowe będą wymagały przedefiniowania, ludzie muszą zostać przeniesieni w firmie do pełnych faktycznych luk lub muszą zatrudnić ludzi.Jeśli jest trwały, musi być oficjalnym posunięciem i tutaj rozpoczynają się negocjacje.Nie bądź wycieraczką, ale też nie bądź primadonną.
@dwizum Obecnie jest to jeden raz, ale teraz, jeśli zaakceptuję wszystko, co mówią, natychmiast bez żadnych argumentów (nawet jeśli są ważne argumenty), poczują, że ten facet robi wszystko, o co poprosimy, nawet jeśli jest to poza jego zakresem obowiązków i przydzielą więcej takichzadania.Miałem podobne doświadczenie.Kiedyś przydzielono mnie do tworzenia podręcznika użytkownika aplikacji (generalnie powinna być osobna osoba do pisania dokumentów nietechnicznych).Zrobiłem to myśląc, że to kiedyś, a teraz przypisują mi takie dokumenty, często mówiąc, że robisz dobrą dokumentację, mimo że powiedziałem im, że tego nienawidzę.
@Kaushal28 Wtedy będzie tak samo z testowaniem ręcznym, a ta odpowiedź nie zadziała.Wielokrotnie jesteś proszony o zrobienie rzeczy wykraczających poza zakres twojej pracy, których nienawidzisz. Prosimy o ponowne rozważenie swojej przyszłości w tej firmie.
Jest inny sposób niż bycie zbyt zajętym: odmów i zacznij szukać innej pracy.
@Kaushal28 Bądź bardziej proaktywny.Po zakończeniu sytuacji awaryjnej porozmawiaj ze swoim przełożonym o tym, jak uniknąć takiej sytuacji w przyszłości.Zawsze będą nieprzewidziane wydarzenia;ale odpowiedź nigdy nie powinna brzmieć „miejmy nadzieję, że to się nigdy więcej nie powtórzy”.Na tym polega różnica między robieniem „9 do 5” a wykonywaniem swojej pracy.Prawdopodobnie masz to nawet w swojej umowie o pracę, pod jakimś półstandardowym sformułowaniem, takim jak „napędzaj doskonalenie procesów rozwojowych, aby zapewnić najwyższy możliwy standard jakości” lub tak dalej.
Kiedyś odkurzyłem toaletę, bo było tak źle, że woźny odmówił jej wyczyszczenia.To było dość paskudne, ale ** wszyscy ** o tym słyszeli.Nie jestem pewien, czy wpłynęło to później na którykolwiek z moich specjalnych projektów, ale ludzie wiedzieli, że skończę! Zrobiłem wiele specjalnych projektów TBH ...
Pamiętam, jak wykonywałem ręczne sprawdzanie wydrukowanych faktur wraz z głównym księgowym, gdy sprawy szły na południe.Wysysanie pychy daje szacunek.
GrandmasterB
2019-10-22 23:33:56 UTC
view on stackexchange narkive permalink

Powinieneś przeprowadzić testy.

Oprócz wszystkich powodów związanych z miejscem pracy, dla których warto to zrobić, weź pod uwagę korzyści programistyczne (tj. dla Ciebie) wynikające z wykonywania takich testów funkcjonalnych. Istnieje duża szansa, że ​​zauważysz nowe błędy lub dziwactwa, które należy naprawić, przeglądając produkt w sposób inny niż zwykle. To byłyby rzeczy, których nawet testerzy mogą nie zauważyć. IMO, pewna ilość takich testów jest dobra dla programistów.

O ile nie jest to własny kod.
Tego rodzaju testy nie są przydatne dla nikogo.Ten rodzaj testów powinien być zautomatyzowany.Powodem, dla którego mają problemy, jest niekompetentne kierownictwo stawiające głupie żądania.
+1 jest zdecydowanie argument, że programiści powinni używać tworzonego przez siebie oprogramowania, aby mieć lepszą empatię użytkownika
Powinien jednak obowiązywać limit czasowy.Zostałem zaszufladkowany w zadaniach, które miały być tymczasowe, ale stały się trwałe, „ponieważ jesteś w tym dobry”.Dobrze! = Baw się dobrze i wiele razy marnowałem moje umiejętności gdzie indziej.Byłem w tym dobry, ponieważ moje umiejętności znacznie przewyższały umiejętności potrzebne do zadania.
@computercarguy dokładnie!Miałem podobne doświadczenie.Zobacz mój komentarz w powyższej odpowiedzi.
@Davor Testowanie ręczne jest z pewnością przydatne w wielu typach projektów.Istnieje wiele pytań dotyczących tego, kto powinien wykonywać tę pracę, ile testów ręcznych należy wykonać w porównaniu z testami automatycznymi, testów eksploracyjnych w porównaniu z następującymi przypadkami testowymi i wszelkiego rodzaju innych kwestii, które zespoły kontroli jakości odkrywają, ale przynajmniej pewien stopień testów ręcznychjest zwykle wymaganiem.Co więcej, jest to sposób na rozszerzenie testów, poza ścisłą zgodnością ze specyfikacjami, o szerszy sens określania tego, co jest najlepsze dla użytkowników i produktu.
@Kaushal28 Zdecydowanie nie chcę sugerować, że powinno to być trwałe.Istnieje różnica między zdobywaniem luzu, gdy jest to potrzebne, aby pomóc firmie, a skuteczną zmianą pozycji!
@Davor Testowanie automatyczne nie może przetestować wszystkiego, ani nie może dać wiarygodnej informacji zwrotnej na takie rzeczy, jak drobne uciążliwości interfejsu użytkownika.Testowanie automatyczne jest dobre dla nisko wiszących owoców pod względem błędów, ale nie jest to jedyne testowanie, które należy wykonać.
@GrandmasterB Zgadzam się z twoją odpowiedzią.+1.Po prostu podzieliłem się podobnym doświadczeniem, które miałem wcześniej.
knallfrosch
2019-10-23 11:18:15 UTC
view on stackexchange narkive permalink

Oto rady od Joela Spolsky'ego, ukochanego współzałożyciela i byłego dyrektora generalnego sieci StackExchange. Jest autorem artykułów na blogach o nazwach takich jak:

Możesz je przeczytać i przedstawić swojemu szefowi niektóre argumenty.

Bez względu na to, jak trudno jest znaleźć testerów, nadal są oni tańsi niż programiści. Dużo taniej. A jeśli nie zatrudniasz testerów, to programiści będą testować. A jeśli myślisz, że to źle, kiedy masz testerów, po prostu poczekaj, aż zobaczysz, jak drogie jest zastąpienie tego gwiazdowego programisty za 100 000 USD rocznie, któremu znudziło się mówienie, że „spędza kilka tygodni na testowaniu zanim zwolnimy ”i przeniosłem się do bardziej profesjonalnej firmy. - Joel Spolsky, powód 5.

[Moje podkreślenie]

Jednak nawet jeśli uda Ci się zmienić sposób pracy firmy, nie stanie się to z dnia na dzień. Tym razem będziesz musiał to zrobić. Pamiętaj, że jeśli to pomoże, otrzymujesz pieniądze w zamian.

Heh, przyszedłem zamieścić ten dokładny link.Prawdopodobnie najlepszą rzeczą do zrobienia jest wskazanie, że jeśli ręczne testowanie stanie się codziennością, odejdziesz.Bardziej dyplomatycznie.A jeśli tak się stanie, po prostu odejdź, ponieważ programiści są bardzo poszukiwani.Byłem na tym samym stanowisku, zmuszony do ręcznego testowania regresji, potem więcej testów, potem jeszcze więcej ... To się nie skończyło, dopóki po prostu nie odszedłem i nie znalazłem nowej pracy, bo miałem jej dość.
To jest kluczowa sprawa.Jeśli to naprawdę jednorazowy wypadek, to dobrze.Podobnie, jeśli nie wszystko jest zrzucane na programistów (jeśli testowanie jest „tylko podążaniem za skryptem”, a jest to „jednorazowe, awaryjne zgłoszenie wszystkich”), to jestem pewien, że ci menedżerowie również pomagają w testowaniu ...prawda?), to po prostu pomóż.Ale jeśli istnieją jakiekolwiek oznaki, że stało się to normalną rzeczą, oznacz powyższe argumenty i przynajmniej zacznij myśleć o swojej strategii wyjścia.
Keith
2019-10-23 10:43:35 UTC
view on stackexchange narkive permalink

Możesz pomyśleć, że twoja „praca” polega na byciu programistą. To nie jest takie proste.

To przynieść wszelkie umiejętności i zdolności, które możesz, aby służyć firmie i klientowi. firma sprzedaje oprogramowanie, co zwykle oznacza, że ​​potrzebuje ludzi do pisania kodu.

Ale: Oprogramowanie, które nie jest testowane (w jakiś sposób, najlepiej automatycznie) jest bezużyteczne, ponieważ gwarantuje, że zawiera błędy.

Powszechna praktyka: Programiści udostępniają oprogramowanie do kontroli jakości, które jest pełne błędów. Każdy twórca warty swojej soli stara się postąpić inaczej; nie wszystkim się udaje.

Czy uważasz, że cały Twój kod jest wolny od błędów? Czy wdrożyłeś testy automatyczne, które obejmują wszystko? Czy zaprojektowałeś oprogramowanie, aby ograniczyć możliwe problemy i wychwycić to, co może się pojawić?

To, co musisz z tego wyciągnąć, to szansa na uświadomienie sobie, że testowanie ręczne jest okropne i że jeśli w ogóle to możliwe, kontrola jakości powinna zostać zautomatyzowana . Więc następnym razem będziesz wiedzieć , że w Twoim kodzie nie ma żadnego błędu, prawda?

Musisz się wtrącać i pomóc firmie odnieść sukces.

„* Oprogramowanie, które nie zostało przetestowane, jest bezużyteczne, ponieważ gwarantuje, że zawiera błędy *” - ** gwarantuje, że zawiera błędy ** ??Miej trochę wiary.Nie można zagwarantować, że nie będzie zawierał błędów, ale tylko dlatego, że nie został ręcznie przetestowany, nie oznacza, że ** będzie ** zawierał błędy.Czuję się źle, że takie jest twoje doświadczenie i zakładam, że nie jesteś programistą, w przeciwnym razie mówisz „cały mój (twój) kod zawiera błędy, przetestuj go, aby je znaleźć, w przeciwnym razie nie naprawię tego”.Co tylko zwiększa obciążenie pracą ze względu na to.
@freedomn-m Cały twój kod zawiera błędy.Nawet oprogramowanie Shuttle zawierało błędy - czy naprawdę twierdzisz, że jesteś lepszy od tego?Chodzi o to, że zawsze musisz mieć na uwadze klienta.Większość błędów nie jest warta naprawiania i najprawdopodobniej są lepsze rzeczy, które możesz zrobić w swoim czasie.Ale to nie znaczy, że błędów tam nie ma.Ale nie możesz nawet podjąć takiej decyzji, jeśli nie weźmiesz pod uwagę błędów (odkrytych lub spodziewanych).Ostatecznie tworzysz wartość dla klienta.Dlaczego _ chcesz_ wyrzucić tę wartość z powodu kilku głupich błędów?Na tym właśnie polega testowanie.
Nie, mówię, że przetestuję to, zanim przejdzie do kontroli jakości.Nie wszyscy programiści są tak niechlujni, aby * zawsze, automatycznie * wydawać niedokończony / błędny kod.Jak powiedziałem, * nie * gwarantuję, że nie ma żadnych błędów - to byłoby poza samozadowoleniem.Ale mogę zagwarantować, że część mojego kodu nie zawiera błędów, więc „cały twój kod ma błędy” jest po prostu niegrzecznym.Ale nie, nie całe moje oprogramowanie udostępnione do kontroli jakości zawiera błędy i nie możesz zagwarantować, że zawiera błędy **.
@freedomn-m pokaż mi kod, którego nie przetestowałeś, a pokażę ci błąd.Napisz kod.NIE URUCHAMIAJ GO i oddaj.za wszystko nietrywialne gwarantuję błąd.
Przepraszamy, ale powiedziałeś „udostępniony do kontroli jakości”, a nie nieprzetestowany.
@freedomn-m Przeredaguję pospieszny post.Stoję na stanowisku, że „niesprawdzone oprogramowanie zawiera błędy”, ale absolutnie zamierzam, że „testowanie” nie oznacza (najlepiej nie powinno) oznaczać oddzielnego zespołu ds. Kontroli jakości.
Lawnmower Man
2019-10-23 12:12:15 UTC
view on stackexchange narkive permalink

Po prostu zrób to ...

Jesteś proszony o wykonanie testów ręcznych, ponieważ nie pomogłeś zautomatyzować testów. Ciesz się, że jest to bolesne i coś, czego nie lubisz robić. Miejmy nadzieję, że wszyscy inni deweloperzy w Twoim zespole czują to samo. Po cierpieniu związanym z ręcznym testowaniem, zadaj sobie pytanie: „Dlaczego programiści w innych firmach nie muszą przechodzić przez wszystkie te ręczne testy?” Zapewniam Cię, że wiele firm dostarcza wysokiej jakości oprogramowanie bez obszernych testów ręcznych. Odpowiedź brzmi: automatyzacja.

... Następnie zautomatyzuj to

Jeśli masz już dobre pokrycie testów jednostkowych, to świetnie! Jak blisko jest do 100%? Czy masz testy integracyjne, które łączą moduły Twojego oprogramowania i sprawdzają koordynację? Nie? To kolejny krok w automatyzacji. Będziesz musiał wykorzystać swój osąd, aby zdecydować, które moduły wymagają szczególnej uwagi.

Wreszcie, czy masz testy akceptacyjne? Jeśli twoje oprogramowanie jest oparte na interfejsie użytkownika, będziesz potrzebować czegoś takiego jak Selenium / FitNesse / itp. Jeśli jest zorientowany na usługi i można go przetestować za pomocą prostego żądania internetowego, proponuję coś, co może być niestandardowe, ale okazało się bardzo przydatne: napisz testy akceptacyjne jako testy wydajnościowe, używając Gatling. Ok, to brzmi szalenie, ale wysłuchaj mnie ...

Gatling Tests

Gatling jest potężny, ponieważ piszesz specyfikację testu w Scali. Jeśli Scala nie jest Twoim językiem programistycznym, będziesz musiał nauczyć się podstaw, aby pisać testy. Ale zaufaj mi, warto zainwestować! Aby przeprowadzić test wydajności, chcesz skonstruować szereg dość reprezentatywnych żądań dotyczących Twojej usługi, a Gatling ułatwia to. Możesz odczytywać dane z plików konfiguracyjnych i generować dowolny obiekt żądania. Następnie możesz uderzyć w testowaną usługę tak mocno, jak Twoja stacja robocza testującego może wysyłać żądania i przetwarzać odpowiedzi (co jest generalnie znacznie szybsze niż usługa może obsłużyć żądania).

Teraz przeprowadzam zarówno testy dymu, jak i testy wydajności. Są dokładnie takie same. Jedyna różnica polega na tym, że testy dymu działają dokładnie N razy, dla małych N (powiedzmy 3), podczas gdy testy wydajności trwają przez czas T (około 15 m). Oba rodzaje testów generują żądania losowo. Niektórzy ludzie będą sprzeciwiać się temu, że determinizm jest lepszy ze względu na odtwarzalność, a argument ten ma swoje uzasadnienie. Ale lubię generowanie losowe dla pokrycia, ponieważ czasami otrzymujesz „interesujące” żądania, które wywołują niejasny błąd i pozostawi ślad w dzienniku, który możesz zbadać.

Wydajność jako akceptacja

Ale musisz wiedzieć, czy Twoje oprogramowanie działa ... a nie czy jest szybkie . Co to ma wspólnego z poprawnością ? Cóż, wszystko! Widzisz, jest jedna zabawna rzecz, która dzieje się w dużych firmach, które mają dedykowanych testerów. W końcu testerzy wyszukują i wywołują w kodzie nieprawidłowe / problematyczne warunki, aby zobaczyć, co się stanie. Ale tak naprawdę programiści powinni również wykrywać te warunki . Najlepiej byłoby, gdyby przynajmniej zarejestrowali BŁĄD, gdy dzieje się coś, co spowodowałoby, że SDET / SET zgłosiłby błąd. Co oznacza, że ​​dobre SDE i dobre SDET powinny robić pewne zbędne rzeczy względem siebie, co w rzeczywistości jest stratą bardzo kosztownego czasu.

Zamiast pisać zewnętrzny test, który wyraźnie sprawdza te warunki błędów, znacznie lepiej jest, aby usługa była bardzo agresywna w sprawdzaniu poprawności danych na wszystkich etapach obliczeń i rejestrowała wszelkie nieprawidłowości. Następnie część testu wydajności będzie obejmować sprawdzenie dzienników (mam nadzieję, że masz skonfigurowane przekazywanie dzienników, np. Splunk lub podobne). W szczególności chcesz sprawdzić, czy podczas testów wystąpił błąd lub HTTP 5xx (zarówno smoke, jak i perf). Jeśli tak, to wiesz, że masz problem, który warto zbadać.

Teraz to, co zrobiłeś, zmieniło twój test perfekcji w generator testów akceptacyjnych . Aby to działało dobrze, generator żądań musi mieć dobre pokrycie. W idealnym przypadku powinno trafiać do wszystkich części domeny dla każdego pola żądania, nawet jeśli określisz dystrybucję jako „realistyczną”. Na przykład załóżmy, że uruchamiasz Twittera i musisz sprawdzić, czy usługa TweetService działa poprawnie. Żądaniem będzie prawdopodobnie coś takiego: (nazwa użytkownika, wiadomość). Oczywiście musisz sprawdzić pełen zakres możliwych nazw użytkowników (długość, dozwolone znaki itp.), A także wiadomości (ponownie, długość, dozwolone znaki, osadzone linki itp.). Twój generator może preferować tworzenie średnio krótszych wiadomości, ale nadal powinien tworzyć wiadomości o maksymalnej długości czasami (co oznacza, że ​​powinny pojawiać się wiele razy w trakcie wykonywania perf).

Testowanie interfejsu użytkownika

Chociaż korzystałem zarówno z Selenium, jak i Fitnesse, testowanie interfejsu użytkownika nie jest moją mocną stroną i nie mogę tutaj podać szczegółowych wskazówek. Niestety nie sądzę, aby można było generować losowe testy dla UI tak, jak można to zrobić dla usług. To sprawia, że ​​jest to zupełnie inna bestia. Mimo to automatyzacja >>> testowanie ręczne. Znajdź framework, uzyskaj wpisowe od swojego zespołu, zautomatyzuj testy, zysk $$$ $$$!

Nadąsałem się, kiedy mój Szef przydzielił mi „pracę testową” (w przeciwieństwie do OP, nie było presji na termin).Po 6 miesiącach testowania zautomatyzowałem większość rzeczy, ORAZ potem jakość mojego kodu znacznie się poprawiła.Jak widziałem inny kod, jak ludzie piszą dobry kod, gdzie często popełniamy błędy… To było wspaniałe doświadczenie edukacyjne.
Testowanie interfejsu użytkownika to moja mocna strona (praca w Testim.io), a jego automatyzacja jest bardzo łatwa dzięki narzędziu dla przedsiębiorstw.Ponadto - generujemy testy dla interfejsu użytkownika, więc jest to:]


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...