Startup a testowanie

Startup a testowanie
Startup to w dużym uproszczeniu koncepcja dynamicznego budowania biznesu w oparciu o istniejące lub też nieznane jeszcze potrzeby. Czy możemy na ich przykładach lepiej zrozumieć, czym jest testowanie?
 

Miałem przyjemność wziąć udział w warsztacie prowadzonym przez Damiana Strzelczyka ze Startup Academy i tutlo.com, który omówił prowadzenie projektów start-upowych. Wiedza przekazywana na spotkaniu była podstawowa, ale czasami warto wrócić do początku, aby przeanalizować, jak bardzo odeszliśmy od korzeni. Przemyślenia po samym warsztacie nastroiły mnie do odświeżonego spojrzenia na samo testowanie.

U korzeni samego startupu leży zestaw czynności i filozofia, która przez wiele lat nie miała swojej nazwy, aż pewnego dnia została określona przez Pana Rise'a jako Lean Startup. Jest to ekstremalnie szybka metoda budowania produktu i poddawania go weryfikacji użytkownika. Jeśli nałożymy na to jeszcze koncept, że wszystko ma być robione najniższym możliwym kosztem i w oparciu o prototypy, mamy bardzo ciekawą analogię do opłacalnego biznesowo testowania.

 


 

Czego tester mógłby się nauczyć z prowadzenia projektów startupowych?

  1. Testuj od pierwszego dnia. Startup nie polega na budowaniu produktu, ale na testowaniu koncepcji. Nie mając absolutnie nic za wyjątkiem pomysłu możemy zacząć testować, czy usługa lub produkt, który chcemy sprzedać jest potrzebny na rynku. Najlepszą i najtańszą metodą jest testowanie prototypów, koncepcji i idei.
  2. Weryfikacja bez użytkownika nie ma sensu. Dziesiątki ludzi może powiedzieć nam, że produkt jest zrobiony (programiści), czy że działa (testerzy), ale to, czy się sprzeda przyjdzie jako informacja od końcowego klienta. Po co więc testować z programistami i testerami, którzy nie są naszymi odbiorcami? W pierwszych etapach musimy skrócić drogę informacji zwrotnej i pójść bezpośrednio do klienta.
  3. Produkt nieoceniony przez użytkownika nie ma żadnej wartości. Po to budujemy MVP (ang. minimal viable product), aby dostarczyć użytkownikowi możliwość doświadczenia samego produktu i jednocześnie uzyskać od niego potwierdzenie: kupię lub chcę zobaczyć więcej.
  4. Środków i czasu nigdy nie ma wystarczająco dużo. Wszystko co robimy musi mieć uzasadnienie biznesowe. Dlaczego mielibyśmy marnować to na robienie rzeczy bez znaczenia w danym momencie lub w bliskiej perspektywie. Unikanie marnotrawstwa to również umiejętność właściwego doboru testów i testowania właściwych i ważnych rzeczy.
  5. Automatyczne weryfikowanie nie ma żadnej wartości w pierwszych etapach rozwoju produktu. Automaty mają to do siebie, że ich wytworzenie i utrzymanie jest kosztowne i czasochłonne, a zwrot z inwestycji jest długoterminowy. W startupach mamy jednak często do czynienia z piwotami, czyli próbami zmiany kierunku rozwoju produktu najlepiej dopasowanego do klienta końcowego. Produkt będzie zmieniał się tak dynamicznie, że większość pracy nad automatyzacją pójdzie do kosza.
  6. Nasi klienci nie szukają defektów, a starają się posłużyć funkcją. Potencjalni klienci świadomi tego, że mają do czynienia z prototypem lub z wczesną wersją nie będą czepiali się braków funkcjonalnych. Będą ciekawi tego, co istnieje. Jakość jest subiektywnym odczuciem odbiorcy produktu i nie zależy bezpośrednio tylko od liczby defektów, które się w oprogramowaniu znajdują.
  7. Dług technologiczny nie istnieje jeśli produkt nie ma perspektywy długiego życia. Możemy więc dowolnie "szyć" i "mockować" do czasu, aż produkt zostanie pozytywnie zweryfikowany przez klienta i na horyzoncie pojawi się pozytywny zwrot z inwestycji.

 

Możemy się spierać, czy to podejście jest możliwe na dłuższą metę. Pewnie nie, bo testowanie w utrzymaniu produktu wymaga zmiany podejścia i, zamiast gwałtownie coś rozwijać, po prostu próbujemy utrzymać stały poziom jakości. Jednak podejście to pokazuje, że całego projektu nie musimy prowadzić w ten sam sposób, a to znaczy, że nie musimy też zawsze stosować tych samych metod. Inaczej testowanie będzie wyglądało w pierwszych fazach cyklu życia, inaczej w fazie dostarczania produktu, a zupełnie inaczej po tym, gdy już go wdrożymy. Musimy więc bezustannie monitorować, czy jeszcze jesteśmy w fazie startupowej czy też już czas na przełączenie się do poziomu projektowego.

Czy przy pomocy Lean Startupa zbudujemy rakietę, którą wyślemy w kosmos? Pewnie, że tak. Elon Musk swoje pierwsze działania prowadził stosując metody z PayPala. Jednak teraz, kiedy z fazy prototypowania wyszedł do fazy produktu, nie może sobie pozwolić na takie podejście.

 

Autor: Radek Smilgin

 

 

SPRAWDŹ TAKŻE
Startupy w infografikach 
Marnotrawstwo w testach oprogramowania 
Dług technologiczny 
Piramida potrzeb użytkownika i MVP 

 

To powinno Cię zainteresować