my unexpected journey becoming software tester
„Budujesz udane życie… Dzień po dniu…”
Moja podróż jako testera oprogramowania rozpoczęła się nieco nieoczekiwanie.
Pojawiłem się na pierwszych rundach rozmów, zakładając, że jest to okazja do rozwoju. Szczerze mówiąc, jak każdy inny absolwent informatyki, byłem nieco sceptyczny co do kontynuowania testowania.
Ale w końcu zdecydowałem się spróbować. Tylko z nadzieją, że moja ciekawska natura pomoże mi w tej dziedzinie.
Nie mogłem zaakceptować oferty bez postawienia tego pytania - czy będę miał możliwość przejścia na programowanie, jeśli testowanie mnie nie interesuje? :).
Uwierz mi - nigdy nawet nie pomyślałem o opuszczeniu testów po tym.
jak napisać plan testów oprogramowania
Kiedy pojawiłem się na rundzie technicznej, nie byłem przygotowany na nic więcej niż podstawowa koncepcja testowania oprogramowania . Chyba jedyną rzeczą, która mnie poprowadziła, była myśl, że jestem oceniany logicznie, a nie teoretycznie ”.
To była moja pierwsza nauka w testowaniu - zrozumiałem, jak ( odświeżacze ) zostały ocenione.
Nawet dzisiaj używam podobnych technik podczas zatrudniania odświeżaczy dla mojego zespołu. Ponad wszystko sprawdzam ich logikę, wytrwałość i podejście do problemu.
Zalecana lektura => 4 Ważne rzeczy, których nauczyłem się podczas mojej podróży jako kierownik ds. Testów jakości
Dołączyłem do Zycusa jako stażysta ds. Kontroli jakości i przydzielono mi produkt około trzeciego lub czwartego dnia. Był to jeden z największych (wtedy powstałych w koncepcji) i najbardziej ambitnych produktów firmy. Po ustatkowaniu się przez kilka pierwszych tygodni, nie było już dla mnie odwrotu.
Zaczynaliśmy jako dwuosobowy zespół ds. Kontroli jakości i wkrótce po kilku miesiącach byłem jedyną osobą kierującą działaniami testowymi. W ciągu pierwszych 2-2,5 roku zarejestrowałem prawie 3000 usterek w różnych kategoriach, takich jak funkcjonalność, wydajność, bezpieczeństwo, interfejs użytkownika, użyteczność, Wielojęzyczny , Wielu najemców itp.
Przez długi czas, zanim dołączył do zespołu testerów, miałem do czynienia z silnym 15-16-osobowym zespołem deweloperskim. Nawet po dodaniach stosunek QC: Dev nie był zbyt dobry i nadal mogę z dumą powiedzieć, że była to udana podróż, biorąc pod uwagę wszystko, co przetestowaliśmy, dostarczyliśmy i obsłużyliśmy.
Ważną kwestią, którą chcę tutaj podkreślić, jest- Wszystko to wynikało ze zrozumienia testowania w praktyce, a nie tylko w teorii.
Zajmuję się testowaniem oprogramowania od prawie sześciu lat. To była niesamowita podróż z tak wieloma różnymi doświadczeniami i mnóstwem owocnej nauki.
Obecnie pracuję jako Senior QA Manager i opiekuję się około 5-6 produktami i modułami. Ale prawdziwą radość i szczęście sprawia mi kierowanie zespołem ponad 30 szczęśliwych i pełnych pasji Testerów.
Oczywiście wiele osób przyczyniło się do mojej nauki, ale nadal mogę powiedzieć, że większość mojego doświadczenia i wiedzy przeszła trudną drogę (i prawdopodobnie najlepszą), tj. Uczenie się / rozwiązywanie tego samodzielnie.
'Doświadczenie jest najlepszym nauczycielem.'
Chociaż to mówię, wcale nie chcę powiedzieć, że nie odniesiesz korzyści z nauki lub podążania za udokumentowanymi teoriami dotyczącymi testowania oprogramowania. Wierzę, że to wszystko na pewno pomoże, ale nic nie jest w stanie przebić zrozumienia istoty koncepcji i śmiałego stawiania czoła problemom.
Wierzę, że udokumentowane rzeczy cię nie nauczą prawdziwe testy , chociaż może dać ci jakiś kierunek i wtedy jesteś sam. Przynajmniej w moim przypadku były problemy, które mogły nie zostać udokumentowane w celu rozwiązania moich konkretnych problemów lub nie mogłem ich znaleźć na czas. Moim jedynym wyborem było zrozumienie problemu / sytuacji u podstaw i zareagowanie na to podejście, które uznałem za właściwe.
Przykłady - jak postępowałem w różnych sytuacjach
Pozwólcie, że wyjaśnię to za pomocą problemów / sytuacji, z którymi się mierzyłam i jak do nich podeszłam.
1) Zrozumienie biznesu jest o krok wyżej niż zrozumienie testowania
Cóż, wszyscy to wiecie. Testowanie to nie tylko testowanie kilku walidacji i przeprowadzanie weryfikacji.
Jako tester powinniśmy bezbłędnie wizualizować każdy możliwy scenariusz, nawet najrzadszy z rzadkich. Powinniśmy rozważyć wszystkie możliwe dane testowe, których może używać rzeczywisty użytkownik.
Za to wszystko powinniśmy jak najpełniej zrozumieć biznes.
Nie będzie źle, jeśli powiem, że powinniśmy rozumieć biznes i bazę użytkowników tak samo, a nawet więcej niż analityk biznesowy.
Miałem podobne szanse.
Miałem zrozumieć złożone scenariusze biznesowe w dziedzinie zakupów przeprowadź burzę mózgów na temat nowych wymagań i rozważ je z perspektywy użytkownika. Miałem nie tylko opracować swoje przypadki, ale także uczestniczyć w fazach wymagań i projektowania każdej iteracji. Nawet tutaj żadne gotowe odniesienie nie przyszło mi na ratunek poza moimi zdolnościami myślenia i rozumowania.
Aby lepiej zrozumieć biznes i lepiej zaprojektować swoje scenariusze / przypadki, nic nie działa jak długopis i papier.
Przeczytaj także => 5 Niezbędne narzędzia testujące dla testerów, aby ułatwić życie
Przed wyjazdem Omówienie wymagań na spotkaniu wcześniej zapisywałem ewentualne wątpliwości / poprawki / niejasne punkty. Kiedyś zapisywałem scenariusze, na których chcę wypróbować lub zbudować przypadki testowe; czasami nawet rysowanie scenariuszy działa jak urok.
Kiedy piszesz / rysujesz, wchodzi to do twojego umysłu z większą klarownością, a następnie twój umysł pracuje nad tymi informacjami i tworzy więcej scenariuszy i daje lepszą klarowność. To trwa, dopóki nie poczujesz, że GOTOWE !!!
# 2) Występowanie wbrew przeciwnościom i presji
Pracowałem nad produktem, który był / jest na tyle duży i złożony, że zespół 30 inżynierów pracuje nieprzerwanie przez trzy długie lata, aby doprowadzić go do sprzedaży.
Przez większość początkowej fazy albo walczyłem (sam) z zespołem 15-20 programistów na poziomie juniorskim, średnio-starszym i seniora, albo towarzyszyło mi jeden lub kilka innych testerów. Wszyscy nieustannie dodawali nowe funkcje do produktu, co wymagało równej i równoległej uwagi ze strony testujących.
Bycie częścią spotkań wymagań, pisanie przypadków, ich wykonywanie, rund eksploracyjnych, utrzymywanie serwerów, wdrażanie - nic nie było opcjonalne.
Do tego czasu nie znałem żadnej metodologii, najlepsze praktyki , kurs lub książkę, która może pokazać mi rozwiązania takich problemów. Nawet dzisiaj nie jestem pewien, czy jest coś, co może dokładnie pomóc ci w walce z ziemskimi realiami, gdy się z nimi zmierzysz.
Raczej robiłem agresywne i szybkie rundy testów eksploracyjnych (Do tej pory nie znałem nazwy) przy każdej funkcji po kolei, a potem powtórz. To rozwiązanie działa wyłącznie na to, jak szybko możesz zmienić swoje myśli i sformułować sytuacje / scenariusze.
Oczywiście wymagało to naprawdę szybkiej i agresywnej pracy, ale zadziałało.
Mówiąc agresywną rundę, mam na myśli, celujesz w jedną rzecz naraz (Mów po jednym elemencie formularza na raz) i przetestuj go niezależnie iw połączeniu z innymi połączonymi elementami / rzeczami.
Zalecana lektura => Jak być maniakiem produktywności (zwłaszcza jako tester)
Na przykład. Jak przetestować pole tekstowe.
program do pobierania filmów z dowolnej strony internetowej
Możesz tutaj przetestować:
- Czy akceptuje i przechowuje dane bez zmian
- Walidacja typu danych
- Weryfikacja maksymalnej długości
- Obsługa znaków specjalnych
- Obsługa XSS
- Wielojęzyczna obsługa danych
- Obsługa pustych przestrzeni / brak danych
- Zachowanie klawisza tab i enter
- Obsługa błędów (w różnych przeglądarkach)
- Wyrównanie interfejsu użytkownika (w różnych przeglądarkach)
- Kopiuj wklej dane / przeciągnij dane linków do pola tekstowego
- Najważniejsze - zachowanie tego pola w.r.t. inne powiązane elementy (wszelkie oczekiwania biznesowe związane z tym polem, takie jak wypełnienie czegoś w innym polu na podstawie danych w tym polu)
Czy myślenie o powyższych testach daje Ci pewność, że w tej dziedzinie nic nie może pójść źle?
Cóż, celowanie w jedną rzecz na raz zawsze działało dla mnie i czasami kończyłem też pracę.
# 3) Kiedy mierzysz się z „nieoczekiwanym”
Jak myślisz, która książka nagle pomoże ci w „Jak”, kiedy masz zrobić coś, czego nigdy wcześniej nie robiłeś?
Jeśli mówimy konkretnie, to- Brak.
Pamiętam czasy, kiedy pod nieobecność naszego Product Leadera, wraz z kilkoma innymi członkami Junior i Mid-Senior mieliśmy po raz pierwszy wdrożyć naszą aplikację na instancję Demo (wtedy była dla nas produkcyjna). Było to bardzo krytyczne dla pierwszego demo naszego produktu.
Cóż, zrobiliśmy to, ale z dużą ilością prób i błędów. Powodem jest to, że nikt z nas nie miał doświadczenia Linux i skrypty powłoki . Pamiętam, że nasz dział IT (wszystko w dobrej wierze) zgłosił mojemu ówczesnemu kierownikowi obawy dotyczące tego, że wykonuję niewłaściwe polecenia na serwerach produkcyjnych. Może to był tylko katalizator, a skryptowanie powłoki / Linux było moim naturalnym zainteresowaniem, ale wkrótce potem wziąłem odpowiedzialność za utrzymanie i aktualizację pięciu do sześciu środowisk jednocześnie.
Shell i Linux tak bardzo mnie zainteresowały, że wkrótce to ja zacząłem prowadzić na nim wewnętrzne szkolenia.
# 4) Kiedy mierzy się twoją wydajność, twoje doświadczenie nie jest
Bardzo wcześnie w mojej karierze byłem porównywany i mierzony z bardzo rozwiniętymi i doświadczonymi testerami. Myślę, że wielu z was musiało doświadczyć podobnej sytuacji i wie, co te dodatkowe oczekiwania robią z wami.
Rozwiązaniem było tutaj Pchaj się i rozwijaj .
Jedynym wyjściem było nie myśleć o tym, jak mniej doświadczony jestem, nie ograniczając się do światowych standardów pomiaru, jak wolno / szybko powinienem się rozwijać / uczyć. Nie ograniczając się do światowych kryteriów, jak szybko należy zacząć przewodzić i jakiego tytułu trzeba, zanim to zrobimy.
Muszę powiedzieć, że w tym miejscu, niezależnie od tego, do której dziedziny należysz, polecam przeczytanie książki Robina Sharmy The Leader Who Had No Title. Pomoże ci uwolnić to, co w tobie leży. Powie ci, że nikt oprócz ciebie nie może cię powstrzymać.
Jeśli muszę zawrzeć swoje doświadczenie w kilku zdaniach, to wygląda to tak:
„Twoja ciekawość, dbałość o szczegóły, dyscyplina, logiczne myślenie, pasja do pracy i umiejętność analizowania rzeczy to wszystko, co jest ważne, aby być destrukcyjnym i odnoszącym sukcesy testerem. U mnie zadziałało i mocno wierzę, że zadziała dla Ciebie. Jeśli masz te cechy, to musi na ciebie zadziałać ”.
Cóż, czytając tak daleko, jeśli myślisz, że przedkładam podstawowe ludzkie cechy nad głębszą wiedzę teoretyczną, to nie jest to do końca prawdą. Wierzę, że aby zacząć od czegoś i zasmakować w tym sukcesu, zależy to nieco bardziej od twoich wbudowanych cech niż od informacji, których się nauczyłeś. Jednak aby zajść daleko w dowolnej dziedzinie, musisz nauczyć się lekcji, zasad i doświadczeń.
W moim przypadku również musiałem do pewnego stopnia nauczyć się terminologii, pojęć, teorii, gdy sięgałem dalej w swojej karierze. Powód jest taki, że jako tester musisz wchodzić w interakcje z kilkoma osobami, które będą mówić w tych terminach i musisz to zrozumieć.
Jako lider lub współtestujący będziesz mieć nowego testera pochodzącego z jakiejś części świata z własną znajomością faktów, definicji i terminologii. Tutaj również nie możesz pozostać bierny wobec tych rzeczy; musisz mieć wcześniejszą wiedzę na temat maksymalnych możliwych użytych / powiedzianych rzeczy.
Uczenie się jest nieuniknione.
Musiałem dowiedzieć się więcej o różnych typach testów, jak je wykonywać i jak wyjaśnić to ludziom w moim zespole na odpowiednim etapie. Musiałem ocenić nowe pomysły, narzędzia i je wdrożyć. Uczenie się nowych koncepcji i metod staje się równie ważne, gdy wspinasz się po drabinie.
Czytaj więcej => Przewodnik od A do Z dotyczący wyboru najlepszej automatyzacji
Wniosek
Chociaż zapisanie każdej ważnej i najdrobniejszej rzeczy, której nauczyłem się przez lata, jest prawie niemożliwe, próbuję podsumować to w formie wypunktowanej listy.
- Testowanie jest bardzo trudne do zdefiniowania. Ktoś może przeprowadzić doskonałe testy i może nie być w stanie zdefiniować tego słowami. Jest tak, jak to widzisz.
- Każdy może mieć własną definicję testowania. Mój był prosty „Otrzymujesz coś - znajduj błędy i ulepszaj je”.
- Nie musisz koniecznie wielkich teorii, złożonych macierzy lub ISTQB, aby być testerem destrukcji. Musisz być ciekawy , skupiony i pełen pasji, myśli logicznie i ma zdolność analizy. Jednak wiedza o tym więcej nie szkodzi, ale nie kosztem utraty sedna.
- Tradycyjne podejścia / koncepcje również mają swoje znaczenie i mam do nich równy szacunek, biorąc pod uwagę fakt, że w dużej części świata są one słuszną koniecznością. Samo testowanie nie może ewoluować; otoczenie również musi ewoluować w tym celu.
- Jako tester równie ważne staje się uczyć się nowego narzędzia, techniki i metodologie w miarę postępów . Planowanie testów, lepsze podejścia do wykonywania różnych typów testów, testy sytuacyjne to tylko kilka z nich.
- Ponieważ testowanie jest płynne, definicja odpowiedniego dopasowania również znacznie się różni w zależności od organizacji. Bycie destrukcyjnym lub doskonałym testerem może być wystarczająco dobre, aby otrzymać wypłatę, jeśli masz szczęście, lub może wymagać dodatkowej wiedzy na temat działania testów w tradycyjnych firmach. Obaj są na swoim miejscu.na przykładZatrudniam ludzi zgodnie z moją definicją testowania (która różni się nieco w zależności od doświadczenia kandydata i profilu oczywiście).
- Jak jest styl kodowania, jazdy, gotowania; istnieje również styl testowania. Możesz nie cieszyć się tym, chyba że robisz to po swojemu. Chodzi mi o to, że testowanie może mieć wytyczne, ale nie powinno być mocno ograniczane przez mikroprocesy.
- Skuteczna przewaga powinien sprawić, że jego zespół wybierze pracę, a nie przydzieli ją. Czasami może to zmienić, aby ulepszyć produkt.
- Spróbuj przeszkolić swoich ludzi w ich obszarze zainteresowań i razem z tym, gdzie chcesz, aby byli szkoleni. Połącz myśli i wysiłki swojego zespołu z celem końcowym, którym jest „Najlepsza jakość”.
- Nie próbuj zarządzać swoimi ludźmi, prowadź ich. Bądź przyjazny i przystępny, to znacznie ułatwia pracę.
- Każdy członek Twojego zespołu powinien kochać swoją pracę, mieć przywiązanie do produktu i przywiązanie do otaczających go osób. Wtedy wyjdą tylko najlepsze z nich.
- Świat testów musi ewoluować. Znaczna część świata przechodzi w kierunku bardziej praktycznych podejść, takich jak testowanie eksploracyjne, testowanie kontekstowe (które wielu ludzi robi, nie wiedząc, że to jest), które nawet inni powinni wypróbować i rozwinąć więcej technik, takich jak
- Powinno powstać więcej społeczności testujących, a ludzie o podobnych poglądach powinni się zjednoczyć na większą skalę. Jest tak wiele do udostępnienia, uczenia się, adaptacji i innowacji.
Mam nadzieję, że moje doświadczenie i odkrycia pomogą Ci stać się lepszym testerem lub lepiej zrozumieć testowanie.
Dalsza lektura => Od początkującego do profesjonalisty: kompletny przewodnik po udanej drodze testera
O autorze: Ten artykuł został napisany przez członka zespołu STH Mahesha C. Obecnie pracuje jako Senior Quality Assurance Manager, mając doświadczenie w prowadzeniu frontu testowania wielu złożonych produktów i komponentów.
Z przyjemnością odpowiem. Skomentuj tutaj lub skontaktuj się z nami. Wielkie dzięki za przeczytanie.
rekomendowane lektury
- Najlepsze narzędzia do testowania oprogramowania 2021 [Narzędzia do automatyzacji testów QA]
- Asystent testowania oprogramowania
- Kurs testowania oprogramowania: Do którego Instytutu Testowania Oprogramowania mam dołączyć?
- Wybór testowania oprogramowania jako swojej kariery
- Testowanie oprogramowania Praca pisarz treści technicznych Freelancer
- Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
- Opinie i recenzje dotyczące kursu testowania oprogramowania
- Doskonały przewodnik po testowaniu oprogramowania (z próbką wznowienia testera oprogramowania)