Historia testowania oprogramowania. Jak wyglądało wczoraj, a jak wygląda dziś?
Na przestrzeni lat postęp technologiczny odpowiadał za zmianę naszego stylu życia. Od prostych udogodnień, jak pilot do telewizora, aż po zmianę całych gałęzi przemysłu. Technologia z natury przynosi ze sobą coś nowego, co nie do końca jest znane, a nie wiadomo, jak wpłynie na nas i na naszą przyszłość. Zmiany prędzej czy później dotykają wszystkich, również testerów. Kilka lat temu mówiono o zmierzchu testów manualnych na rzecz automatycznych. Dziś mówi się, że sztuczna inteligencja wyprze testerów manualnych i automatycznych. Jak będzie? Zobaczymy. Jednak nim to nastąpi, spójrzmy w przeszłość.
Spis treści
Pierwszy bug
Pierwsza wzmianka o bugach, czyli małych problemach, które sprawiają, że coś nie działa, pojawiła się w notatkach i listach Thomasa Edisona. Nowe określenie zostało podchwycone przez dziennikarzy oraz inżynierów, by zagościć na stałe w słowniku Thomasa Sloane – Standard Electrical Dictionary (1892), jako „Bug. Any fault or trouble in the connections or working of electric apparatus…” . Tym samym, termin ten zawdzięczamy inżynierom telekomunikacyjnym.
Praprzodkiem komputerów były maszyny liczące wymyślone przez matematyków takich jak Charles Babbage czy Alan Turing. Ich budową zajmowały się uniwersytety, a pierwszymi programistami i operatorami byli właśnie matematycy. To właśnie oni byli też pierwszymi testerami, weryfikując obliczenia maszyn. Pracowali oni wtedy w małych grupach, zrzeszonych wokół danego wydziału na uniwersytecie, co warunkowało wielkość zespołów i ich działanie. Druga wojna światowa przyczyniła się do rozwoju komputerów dzięki dotacjom wojskowym. Wojsko wykorzystywało maszyny liczące do łamania szyfrów (Bomba Turinga), czy do budowy najpotężniejszej bomby, czyli bomby atomowej.
Kolejna wzmianka o bugach, a w zasadzie o bugu komputerowym, pojawia się w 1947 roku. Został on odnotowany w komputerze Mark II przez Grace Hooper i operatora Williama „Billa” Burke. Owy bug (z ang. robal) był faktycznie ćmą, która powodowała błędy w odczycie taśmy perforowanej. Po znalezieniu została przyklejona do dziennika operatorów (log book) z dopiskiem: „First actual case of bug being found”. Dziennik znajduje się do dziś w zbiorach Smithsonian National Museum of American History.
Jakość oprogramowania
Późniejszy rozwój technologii niewiele zmienił. Tendencja do pracy w małych zespołach utrzymała się dość długo, ze względu na wielkość i dostępność maszyn. Testy ad hoc wystarczały do zapewnienia wystarczającej jakości. Joseph Juran jako pierwszy zauważył i podkreślił potrzebę jakości oprogramowania w swojej książce pt. “Quality control handbook” (1951), która notabene była przewodnikiem po świecie jakości w firmach zajmujących się wytwarzaniem rzeczy na skalę przemysłową, a nie firm stricte deweloperskich.
Na pierwsze standardy i terminologię przyszło nam czekać aż do 1979, gdzie Glenford J. Myers wydał książkę pt. “Art of Software Testing” i opisał w niej podejście do testowania oprogramowania, które rozdzieliło debugowanie od testowania oprogramowania oraz wprowadziło pojęcie czarnej skrzynki – „Black box”.
Komputery osobiste
Jednak prawdziwym przełomem było wprowadzenie komputerów osobistych przez IBM w 1981 roku. Po raz pierwszy firmy zewnętrzne niezwiązane z danym dostawcą komputerów, mogły tworzyć oprogramowanie na sprzęt inny niż własny. Spowodowało to rozwój nie tylko samego rynku komputerów przenośnych, bo za sukcesem IBM i inne firmy zaczęły tworzyć własne wersje PC-tów, ale i rozwój samego oprogramowania. Wolny rynek musiał dostosować się do konsumenta, a więc oprogramowanie musiało być kompatybilne z różnym osprzętem, jak i systemem operacyjnym.
Exploratory testing
W 1988 Cem Kaner w książce Testing Computer Software użył po raz pierwszy określenia „exploratory testing”. Książka zmieniła podejście do testowania oprogramowania i wytyczała nowe ścieżki, dzięki pokazaniu przykładów z życia wziętych, jak choćby tworzenie test planów, test raportów, czy opisywania błędów. Kolejny przełom został wymuszony przez rozwój globalnej sieci – Internetu. Dystrybucja oprogramowania stała się łatwiejsza, a tym samym częściej można było wprowadzać nowsze wersje oprogramowania. Związane było to z popytem i chęcią szybszego dostosowywania oprogramowania do potrzeb konsumenta.
Testy kompatybilności
Takie oczekiwania również przyczyniły się do zmian w samym podejściu do testowania. Przede wszystkim trzeba było wprowadzić testy kompatybilności oprogramowania w oparciu o dostępne podzespoły, zoptymalizować i przyspieszyć sam proces wytwarzania oprogramowania, tak by oprogramowanie jako produkt mogło być wydawane szybciej i częściej. Do zmiany modeli dostarczania jakości przyczynił się również Linux (1991), który pokazał, że można dostarczyć skomplikowane oprogramowanie z kodem źródłowym dostępnym dla wszystkich i testowanym przez społeczność zrzeszoną wokół produktu (crowd testing).
W 1993 Jeff Sutherland, John Scumniotales i Jeff McKenna stworzyli oprogramowanie w zespole scrumowym i nazwali go Scrumem. To był pierwszy przypadek, w którym oprogramowanie zostało wytworzone w oparciu o model przyrostowy, bazujący na krótkich cyklach wytwórczych. Umożliwiło to zmianę podejścia do samego produktu w trakcie jego wytwarzania, łamiąc tym samym klasyczne modele, gdzie z góry jest opisany produkt finalny.
Macintosh
W roku 1984 Apple wypuszcza Macintosha z pierwszym systemem operacyjnym opartym o interfejs graficzny. Powoduje to kolejne zwiększenie zakresu testów o interfejs graficzny – nie tylko samego systemu operacyjnego, ale również oprogramowania, które miało być na nim instalowane. Z czasem testy interfejsów graficznych zmienią się w zupełnie nową dziedzinę – UX.
Windows 95
W roku 1995, Microsoft wprowadza system Windows 95. Jest to pierwszy system operacyjny reklamowany jako multimedialny. Komputer osobisty staje się domowym centrum rozrywki. Liczba możliwości zastosowań ciągle rośnie, otwierając kolejne drzwi dla programistów i testerów. Zaczyna się powolny podział na specjalizacje w testach, którą potęguje wydanie w 1999 roku książki napisanej przez Marka Fewstera i Dorothy Graham. Opisują w niej podejście do testów automatycznych, strategie i taktyki. To pierwsze tego rodzaju wydanie, które kładzie podwaliny pod rozwój testów automatycznych.
Manifest Agile
Około roku 2000 liczba dostępnych modeli wytwarzania oprogramowania, podejść i definicji zaczyna wprowadzać chaos. Między innymi dlatego na konferencji w Utah w 2001 roku zostaje wydany Manifest Agile, który przedstawia 12 wspólnych zasad wytwarzania oprogramowania metodą zwinną, a w 2002 zostaje powołana organizacja ISTQB, której głównym zadaniem jest standaryzacja zawodu testera.
Selenium
W roku 2004 zostało stworzone oprogramowanie Selenium, które jest jednym z głównych narzędzi testerów automatycznych przy tworzeniu testów automatycznych dla interfejsów UI. Jest również jednym z najczęściej wybieranych narzędzi przez testerów zaczynających przygodę z testami automatycznymi.
Smartfony
W roku 2007 firma Apple pokazała swój najnowszy produkt – iPhone. Łączy on w sobie funkcje telefonu, odtwarzacza muzyki, przeglądarki internetowej oraz wyświetlacza dotykowego. Przyciski fizyczne zredukowano do minimum, dzięki czemu klient zyskał bardzo duży wyświetlacz, na którym mógł oglądać teledyski czy filmy. Telefon okazał się dużym sukcesem. Konkurencja również zaczęła produkować podobne urządzenia, które obecnie są w powszechnym użyciu.
Nowe urządzenie, obecnie znane jako smartfon, przysporzyło pracy nie tylko programistom, ale i testerom. Doszła kolejna platforma, kolejne systemy operacyjne i nowe wymogi. Mimo że telefon miał funkcje multimedialne, to nadal był telefonem i ta funkcja do dziś ma nadrzędną rolę, o czym testerzy tych urządzeń muszą pamiętać.
Continuous Delivery
Dziś bardzo często oprogramowanie dostarcza się w podejściu Continuous Delivery, gdzie pisanie kodu, jego rozwój i testowanie jest zamknięte w ciągłym cyklu, a dostarczane często w systemie dziennym. Oczywiście to wszystko jest możliwe dzięki różnego rodzaju narzędziom wspierającym te procesy.
Przyszłość
Pod wielkim znakiem zapytania stawia nas sztuczna inteligencja. Choć wiele osób uważa, że wyprze ona programistów i testerów, to nie jest to do końca prawda. Wszystko odbywa się poprzez ewolucję, a nie rewolucję. Już dziś mamy oprogramowanie wykorzystujące sztuczną inteligencję do zarządzania testami.
Jednym z nich jest “mabl”, które służy do utrzymywania testów regresyjnych. Mabl dba o to by set regresyjny był aktualny, poprzez poprawianie błędów, które wynikają ze zmian w frameworku tworzonego oprogramowania. Samo komunikuje spadek wydajności kodu oraz porównuje zmiany wizualne w UI.
Jeżeli takie oprogramowanie wyprze testerów jakich znamy dziś, to na ich miejsce pojawią się nowi, którzy wykroczą poza znany nam Świat IT. Tester przyszłości będzie posiadał wiedzę z takich dziedzin jak behawiorystyka, procesy nauczania czy budowa modeli prognostycznych. Jednak nim to nastąpi, wystarczy rozróżniać podstawowe pojęcia jak AI, Deep Learning i Machine Learning. Pamiętajmy, nieważne w jakich czasach żyjemy, zawsze wiedza była, jest i będzie potęgą. Im więcej o czymś wiemy, tym bardziej świadome decyzje podejmujemy, a co za tym idzie, lepiej kształtujemy naszą przyszłość.
Zdjęcie główne artykułu pochodzi z pexels.com.