Jak przeprowadzane są testy oprogramowania w startupach technologicznych?

10

Widziałem wiele artykułów badawczych i blogów technicznych, które mogą pochwalić się zaletami testowania oprogramowania. Przekonałem się w tym. Ale ponieważ wszystkie badania nad testami oprogramowania są prowadzone przez duże firmy produkujące oprogramowanie, nie sądzę, aby naprawdę dotyczyły startupów. Ponieważ startupy mają różne potrzeby i ograniczenia w porównaniu do dużych firm programistycznych.

To wywołało pytania. Czy startupy technologiczne powinny pisać automatyczne testy? Jeśli tak, to czy są one wykonywane w taki sam sposób, jak duże firmy produkujące oprogramowanie? (test dymu, test regresji itp.) Najlepiej, jeśli możesz odnieść się do niektórych artykułów badawczych na ten temat ... ponieważ nie byłem w stanie samodzielnie znaleźć żadnego z nich.

(Muszę przyznać, że chociaż wciąż jestem na początku kariery, ale nie widziałem jeszcze startupu, który poważnie poświęciłby się pisaniu automatycznych testów)

ming_codes
źródło
5
Dołączyłem do 10-letniego małego startupu i jako pierwszy w rzeczywistości dodałem testy, które działają w nocy. Nie dlatego, że byłem geniuszem, ale po raz pierwszy kierownik (także programista) uznał, że nadszedł czas, aby je dodać i że w końcu mieli siłę roboczą. Straty często muszą najpierw przetrwać, a potem doskonale. To prawda, że ​​start-up został rozpoczęty przez osoby niebędące technikami, więc tę funkcję trzeba było „wsunąć”.
Job
5
10-letni startup ...?
pap.
Dilbert powiedział : „Jeśli najlepsza praktyka zostanie przyjęta przez wszystkich w branży, wówczas najlepsza praktyka stanie się mierna”. To chyba prawda, heh.
ming_codes,
10-letni start-up ... oni muszą używać Java: 3 lata projektowania + 7 rozwoju :) po prostu żartuję (jestem programistą Java btw)
nuvio

Odpowiedzi:

11

Zawsze istnieje konflikt między tym, co należy zrobić, a tym, na co realistycznie mamy czas. Tak, wiele startupów rezygnuje z programowania i testów automatycznych, aby zaoszczędzić trochę czasu na uruchomienie projektu.

Serwisy społecznościowe i firmy oferujące aplikacje mobilne są teraz wielkimi bańkami i są bardzo konkurencyjne. Czasami różnica między uruchomieniem za 4 miesiące a 5 miesięcy oznacza, że ​​przegrywasz.

Czas na sprzedaż jest kluczem, a jeśli sukces się zdarzy, nadejdzie czas na skalowanie, wtedy będzie dużo czasu, aby przekształcić swoje beznadziejne oprogramowanie w coś wartościowego.

wałek klonowy
źródło
Czas na rynek to jednak mit. Późni uczestnicy rynku mogą zdmuchnąć istniejących graczy: friendster> myspace> facebook.
Joeri Sebrechts,
@JeriSebrechts Przeczytałem interesujący artykuł o postępie oprogramowania i jego związku z sukcesem późnych uczestników. W grę wchodzą zmienne, bezpieczny okres dla późnego uczestnika z podobnym rozwiązaniem jest równy czasowi, po jakim baza użytkowników oprogramowania może przejść z wczesnych dostawców do zwykłych użytkowników. Podobne rozwiązanie oznacza oczywiście funkcje, które są podobne i nie są przełomowe w porównaniu do pierwszego wchodzącego na rynek (np. Facebook był przełomowy w porównaniu z MySpace). Po osiągnięciu masy krytycznej Wczesnych Adoptera ogólni użytkownicy zaczynają migrować.
wałek klonowy
12

Testowanie oprogramowania nie jest religią. To tylko bardzo dobry pomysł.

Mówisz, że nie masz teraz siły roboczej do pisania testów? Ok dobrze. Za 6 tygodni będziesz miał siłę roboczą, aby znaleźć błąd, który powoduje awarię aplikacji, który zostałby znaleziony natychmiast, gdybyś miał odpowiednie testy?

Zbyt wiele testów może spowolnić rozwój. Zbyt mało testów może również spowolnić. Musisz znaleźć właściwą równowagę i zwykle trudno jest powiedzieć, gdzie to jest. I nic z tego nie jest specyficzne dla dużych ani małych firm.

Mike Baranczak
źródło
4

Przez wiele lat, pracując w małych firmach i start- upach, nie rozumiałem , że „nie miałem wystarczająco dużo czasu na napisanie testów jednostkowych dla mojego kodu” .

Kiedy pisałem testy, były rozdęte, ciężkie rzeczy, które tylko zachęciły mnie do myślenia, że ​​powinienem pisać testy jednostkowe tylko wtedy, gdy wiedziałem, że są potrzebne.

Ostatnio zachęciłem mnie do korzystania z Test Driven Development i uznałem, że jest to kompletne odkrycie .

Jestem teraz głęboko przekonany, że „nie mam czasu, aby nie pisać testów jednostkowych” .

Z mojego doświadczenia wynika, że ​​rozwijając się z myślą o testowaniu, otrzymujesz czystsze interfejsy, bardziej skoncentrowane klasy i moduły oraz ogólnie bardziej SOLIDNY , testowalny kod.

Za każdym razem, gdy pracuję ze starszym kodem, który nie ma testów jednostkowych i muszę coś ręcznie przetestować, ciągle myślę, że „byłoby o wiele szybciej, gdyby ten kod miał już testy jednostkowe” . Za każdym razem, gdy próbuję dodać funkcjonalność testu jednostkowego do kodu z wysokim sprzężeniem, ciągle myślę „byłoby to o wiele łatwiejsze, gdyby zostało napisane w sposób oddzielony” .

Jeśli odkryłem coś na przestrzeni lat, jeśli pracujesz na starcie, musisz być zwinny , nie tylko w sensie metodologii tworzenia oprogramowania . Dla mnie TDD jest ważnym narzędziem, które umożliwia uruchamianie i utrzymywanie zwinności .

Mark Booth
źródło
1

Nie chodzi o to, kto powinien przeprowadzać testy oprogramowania. Testowanie oprogramowania to rodzaj filozofii tworzenia oprogramowania. Testy oprogramowania stanowią podstawę dobrej jakości oprogramowania, a przy starcie jakość oprogramowania jest premią, gdy przejęcie przez dużą firmę jest tuż za rogiem;)

Francisco Valdez
źródło
1

Najlepsze praktyki są w branży, bez względu na to, czy robisz babcię stroną internetową, czy tworzysz system nawigacji satelitarnej. Zawsze powinni za nimi podążać ci, którzy chcą uważać się za profesjonalistów, dlatego nazywani są praktykami BEST.

Ryathal
źródło
Możesz być zaskoczony, słysząc, że najlepsze praktyki nie są dostępne w całej branży. thedailywtf.com
Gary Willoughby
@Gary jej bardziej z branży szeroko w teorii lub części tego utopijnego świata, gdzie projekty realistycznych harmonogramów i HTML ma znaczenie semantyczne i menedżerów przyznać, brakuje im wiedzy technicznej, która pomoże im w podejmowaniu lepszych decyzji ...
Ryathal
„Najlepsze praktyki” zwykle oznaczają robienie rzeczy takich jak wszyscy inni, przynosząc średni wynik. Średnia firma o ustalonej pozycji radzi sobie dość dobrze, ale przeciętny startup technologiczny nie dociera wystarczająco daleko, by spektakularnie się zawiesić.
David Thornley,
1
@DavidThornley - Nie, myślę, że „najlepsza praktyka” jest tym, co większość ludzi uważa, że powinni robić, niezależnie od tego, czy mają na to czas, energię lub zgodę kierownictwa. * 8 ')
Mark Booth,
@Mark Booth: Zazwyczaj, kiedy słyszę to zdanie, oznacza to, co powiedziałem. Oczywiście YMMV. Ryathal odnosi się jednak do świata, w którym projekty mają realistyczne ramy czasowe, co niekoniecznie jest możliwe w biznesie. Wydanie produktu z opóźnieniem o dwa miesiące może być nieistotne lub śmiertelne (szczególnie dla startupu, który może być zagrożony wyczerpaniem pieniędzy), i denerwująco często istnieją mocne uzasadnienia biznesowe, aby uzyskać coś, co w większości działa natychmiast. Trudno mi uwierzyć w „najlepsze praktyki”, które mogą skazać firmę.
David Thornley,
1

Tak, startupy czasami skracają rogi i nie sugerują właściwego testowania. Czasami jest to właściwe (w przypadku wystarczająco małych projektów lub gdy krytyczny jest czas / pieniądze)

Nie dotyczy to jednak wyłącznie startupów. Jeden z naszych dostawców kontrahentów IT nie ma nawet środowiska testowego. Wszystko odbywa się od razu, a jest to duża, międzynarodowa firma produkująca oprogramowanie (przerażające!)

Tom Squires
źródło
1

Powinni? Tak. Czynią to w praktyce, nie tak często, jak powinny.

Najbardziej typowym podanym powodem jest brak zasobów, który obejmuje czas programisty, koszt wynajmu dedykowanego lub półetatowego testera, koszt utworzenia środowiska testowego i tak dalej. Te wymówki można nawet znaleźć w dużych firmowych ustawieniach, a także w małych przedsiębiorstwach typu start-up.

Patrząc z innej strony, testowanie jest jedną z najłatwiejszych rzeczy, które można wyciąć z harmonogramu opracowywania, szczególnie z bardzo ciasną presją czasu i / lub presją kosztów w celu uzyskania widocznych wyników. Wraz ze szczegółowymi pracami projektowymi wielu menedżerów uważa to za „puch”, a na pierwszym miejscu powiedzą „skróć to, abyśmy mogli sprawić, by nasz harmonogram i budżet działały”, a następnie „Dlaczego nie kodujesz?”.

W niektórych firmach będzie ktoś, kto przeprowadzi testy wypychania. Zwykle będzie to programista zatrudniony i zwykle będzie to ktoś z doświadczeniem i prawdopodobnie ktoś, kto ma jakieś finansowe udziały w firmie. Firma, która zaczyna się od tego „DNA”, prawdopodobnie przeprowadzi testy od samego początku.

jfrankcarr
źródło