#1: Dziękuję!
W środę odbyła się wirtualna kawka - pierwsze luźne spotkanie czytelników newslettera. Wprawdzie liczba uczestników była niewielka, ale przecież liczy się jakość, nie ilość. A jakość była na naprawdę wysokim poziomie!
W ciągu niespełna półtorej godziny omówiliśmy naprawdę ciekawe tematy:
- jak pokazać zaangażowanie podczas rekrutacji,
- jak przygotować "portfolio" i co w nim wykazać,
- czy warto robić egzamin ISTQB,
- nietypowe podejście do sylabusa ISTQB oraz egzaminu,
- dlaczego ISTQB lepiej robić mając już doświadczenie zawodowe i jak to uzasadnić podczas rekrutacji,
- z jakich narzędzi korzystać podczas nauki - dedykowane aplikacje czy klasyczne edytory tekstowe.
Było też kilka luźniejszych tematów.
Joanno, Urszulo, Sławku - bardzo Wam dziękuję za udział i wartościową wymianę poglądów.
Powyższa lista brzmi ciekawie? Nie dotarłeś/aś na spotkanie? Nic straconego, ponieważ...
✅ KOLEJNA KAWKA JUŻ W PRZYSZŁYM TYGODNIU! ☕
Daj mi proszę znać, który termin Ci odpowiada. Link do ankiety. Do wyboru jest środa, czwartek oraz piątek. Będę wdzięczny, jeżeli uda Ci się wypełnić ankietę do końca niedzieli. W poniedziałek postaram się przesłać zaproszenie, które będziesz w stanie dodać do swojego kalendarza. Dzięki temu nie zapomnisz o spotkaniu 😉
Czego można się spodziewać? To zależy od Ciebie - to luźne i bezstresowe (hmm... no, może nie dla mnie 😉) spotkanie, podczas którego rozmawiamy o wszystkim i niczym, choć staramy się trzymać branży QA/testerskiej. Możesz zatem zadać kilka pytań, opowiedzieć o ostatnich rekrutacjach czy postępach w nauce. Niech to będzie spontaniczne... 😉
#2: Warto doczytać
- Promocja w sklepie Helion, również na książki związane z testowaniem oraz zapewnianiem jakości. Pospiesz się - promocja trwa tylko do 2 sierpnia.
- Co zespół wie o Quality Assurance?
- Przestań traktować QA gorzej od QAA (oraz testerów manualnych gorzej niż automatyzujących). Krótki, ale dający do myślenia wpis na LinkedIn.
#3: (Prawdopodobnie) najbardziej niebezpieczne sytuacje w pracy Quality Assurance
Bywa czasami tak, że chcemy coś przekazać, ale nie wiemy jak to podsumować w dwóch zdaniach czy określić tytuł nagłówka. Niebezpieczeństwo nie dotyczy tutaj zapewniania jakości w aplikacjach medycznych (bezpośrednio podłączonych do człowieka), bo to prawdopodobnie najbardziej stresujący projekt. Na drugim miejscu można wstawić projekty bankowe - te też nie należą do sielanki, choć nie zagrażają bezpośrednio życiu człowieka. Mogą zagrażać jedynie jego portfelowi.
My jednak skupimy się nie na konkretnym projekcie, a na podejściu do wytwarzania oprogramowania.
Wyobraź sobie taką sytuację - przychodzi prezes wielkiej korporacji, w której pracujesz, i mówi że ma pomysł na świetny projekt. Po dostarczeniu bardzo szczątkowych, dosłownie kilkuzdaniowych opisów (zapomnij o dokumentacji czy konkretnych wymaganiach - to przecież prezes, taki dość "stanowczy", któremu nie można się sprzeciwić*), wiesz już że to nie może się udać (powód jest tutaj nieistotny). Prezes oczywiście uważa, że to innowacja, a Twoje argumenty oparte na 10-letnim doświadczeniu, do niego nie trafiają. Projekt ma być gotowy za miesiąc, zaangażowani będą wszyscy w firmie. Co robić? Przecież to właśnie do Ciebie (oraz reszty zespołu) należy utrzymanie jakości, a tutaj ciężko będzie o jakość, skoro projekt umrze tydzień po publikacji. W dodatku wszystkie zasoby zostaną zużyte.
Jeżeli żadne argumenty (Twoje czy całego zespołu) nie trafiają do zaborczego klienta, postaraj się wdrożyć MVP. Przeanalizuj sytuację, rozbierz ten projekt na czynniki pierwsze, przegadaj to z zespołem i zaproponuj stworzenie MVP - projektu z minimum działającej funkcjonalności. Dzięki temu uda się to zrobić w (przykładowo) tydzień, a po jego wydaniu będzie można zebrać dane, statystyki, wykonać rozbudowaną i zaawansowaną analizę na gotowym produkcie. Dodatkowo będzie można porozmawiać z klientami, zebrać feedback oraz inne dane, które jasno wskażą, że ten projekt to... dno. Mając konkretne dane (których często nie da się zebrać, nie mając niczego na produkcji), będziesz w stanie przekazać je klientowi i pokazać, że ten projekt się nie uda. Jeżeli zrobisz to dobrze, klient zrezygnuje lub zmieni wymagania projektu, zaufa procesowi oraz Twojemu doświadczeniu, przy okazji oszczędzając zasoby i ogromną ilość czasu.
Warto pamiętać, że czasami ciężko przekonać klienta, omawiając wyłącznie sytuacje z przeszłości i bazując na własnym doświadczeniu. Nierzadko trzeba będzie zdobyć konkretne dane, informacje zwrotne, wykonać odpowiednią analizę, a (często) najlepszym sposobem jest wydanie MVP projektu. To też dobry pomysł do tego, by zebrać dane o wykorzystywanych przez potencjalnych klientów urządzeniach - przyda się to, jeżeli projekt nie zostanie porzucony.
* tak, nadal istnieją takie podejścia do pracowników. Niestety.
Przejdźmy zatem do drugiego przykładu. Wyobraź sobie projekt, który ma szansę podbić rynek. Jest innowacyjny, potencjalni klienci już są gotowi, by z niego korzystać. Marketing działa od jakiegoś czasu, hype rośnie... Jako QA odpowiadasz za jakość, a zatem również za datę wydania aplikacji na środowisko produkcyjne (wraz z PO). No właśnie - kiedy to zrobić? Aplikacja ma jeszcze trochę defektów. Początkujący QA będą zapewne wstrzymywać taki projekt, do momentu naprawy większości błędów. Opóźnienie premiery może skutkować tym, iż konkurencja pierwsza wejdzie na rynek i zgarnie największy kawałek tortu. Wydawać zatem od razu? Może znów zrobić MVP? Albo poinformować, że jest to wersja beta (rozwiązanie stosowane często w grach)? Cóż, tym razem nie odpowiem Ci wprost. Ale żeby nie było za łatwo, dorzucę jeszcze trochę do pieca i namieszam Ci w głowie - jeżeli wydamy produkt zbyt późno, nie będziemy w stanie zebrać odpowiedniej ilości danych użytkowników. Bo przecież klienci również "testują oprogramowanie". Nie zawsze możemy sobie pozwolić na testy akceptacyjne, a czasami są one wykonywane przez nasz wewnętrzny zespół (co nie zawsze przekłada się dobrze na praktykę). Otrzymując realne dane od realnych klientów zbyt późno, czasami nie będziemy w stanie już nic z tym zrobić - będzie za późno. I mimo iż produkt był idealny, zabezpieczony, wydajny, dostępny itd itp, to wciąż główna funkcjonalność lub logika biznesowa może zawieść.
Prawdopodobnie projekt, nad którym będziesz w przyszłości pracować, nie będzie bezpośrednio związany z ludzkim życiem. Nie oznacza to jednak, że nie będzie to istotne na rynku. Bo dla klienta, który chce zarabiać na tym, na pewno będzie. Pamiętaj o tym projektując proces zapewniania jakości. Określ kiedy należy zacząć zapewniać jakość, kiedy należy skończyć, a kiedy włączyć do tego klientów aplikacji. Jakość nie może być zbyt niska. Nie można też przedobrzyć w drugą stronę i w nieskończoność wstrzymywać premierę. MVP jest często dobrym rozwiązaniem, bo pozwoli nam zebrać najcenniejsze dane i feedback, ale czasami nie można sobie na to pozwolić od razu (tajny, innowacyjny projekt - jeżeli go opublikujemy na zbyt wczesnym etapie, konkurencja z 10x większym zespołem może nas szybko przegonić). Gdzie zatem jest ta magiczna granica zapewniania jakości?
|