W ostatnich latach nareszcie nastąpiło systematyczne podejście do problemu testowania oprogramowania. Widać to w tematyce konferencji, publikacji prasowych, ukazujących się książek; wreszcie po ogłoszeniach o pracę i pojawiających się ofertach specjalnych centrów testowych. Im większy nacisk kładzie się na testowanie, tym bardziej należy zadawać pytanie: dlaczego musimy testować? Gdzie - i dlaczego! - zawiódł proces wytwórczy, że tak intensywna kontrola jakości na jego wyjściu jest konieczna? Odpowiedzi mogą nam podsunąć systemy jakości dla przemysłu.

Anegdota mówi, że zapytano Niemca, Amerykanina i Japończyka co to jest dobry produkt. Niemiec odpowiedział, że dobry produkt to taki, który spełnia wszystkie stosowne normy DIN oraz TÜV. Amerykanin odpowiedział, że dobry jest ten produkt, który się dobrze sprzedaje. Japończyk zaś odparł, że dobry produkt poznać po tym, że przez ciągłe doskonalenie coraz lepiej spełnia oczekiwania odbiorców.

Ta krótka historia ilustruje, jak różnice mentalności pomiędzy poszczególnymi nacjami i kulturami każą różnie postrzegać tak oczywiste - wydawałoby się - a jednocześnie ważne pojęcie. Mówiąc o jakości systemów informatycznych, mówimy tak naprawdę o wszystkich perspektywach. Dobre oprogramowanie musi być skonstruowane na wszystkie trzy sposoby. Musi zarabiać na siebie, by jego dostawca mógł stale funkcjonować na rynku, doskonaląc istniejące produkty i wypuszczając nowe. Musi wychodzić naprzeciw oczekiwaniom klientów, a także odrobinę je wyprzedzać - bo tylko to daje mu przewagę nad innymi. Zaś zgodność ze standardami i dobrymi praktykami powinna być jak najszerzej stosowana w inżynierii informatycznej.

Pod pojęciem "zapewnienie jakości" systemu IT dziś rozumie się przede wszystkim jego testowanie. Niektóre podejścia, np. XP, uczyniły z testowania temat nieomal nadrzędny wobec wymagań ("wiesz jak coś ma być zrobione, dopiero gdy powiesz jak będzie sprawdzane"). Jednak nie sposób nie zauważyć, że taka perspektywa ma zasadniczą wadę: koryguje błędy późno, prowadzi do marnotrawstwa wysiłku i - co za tym idzie - ogólnej nieobliczalności procesu wytwórczego.

Oprogramowanie jak samochód?

W systemie jakości opracowanym przez firmę Toyota, a uogólnionym pod nazwą lean manufacturing w licznych publikacjach, kursach i szkoleniach, nacisk położono na cały proces wytwórczy, dobrą organizację miejsca pracy, elastyczność, innowacyjność, wczesne wykrywanie błędów, robienie wszystkiego od razu dobrze (first time right) i we właściwym momencie (just-in-time); nie zapominając o takich elementach, jak myślenie procesowe i systemowe, nieustające doskonalenie oraz praca zespołowa. Przytoczmy motto lean: "robić właściwe rzeczy we właściwym miejscu i czasie, od razu dobrze oraz z otwartością na zmianę".

Zanim jednak przejdziemy do dalszego ciągu wywodu, zaznaczmy wszystkie różnice, które dzielą przemysł od inżynierii oprogramowania. Tworzywo masowej produkcji to produkt materialny, podczas gdy software to produkt niematerialny - odpadają więc liczne problemy związane ze składowaniem i magazynowaniem. Nie istnieje także problem odpadów - co najwyżej problem (za to poważny!) marnotrawstwa czasu na czynności nieefektywne. Przekaz produktu niematerialnego jest nieomal natychmiastowy - z tego powodu część logistyczna lean jest także poza zakresem naszego zainteresowania. W fabryce buduje się wiele identycznych produktów; w firmie informatycznej produkt za każdym razem w pewnej mierze wymyśla się od nowa. Last but not least, inny typ osobowości zaludnia "podłogę" fabryki, a inny firmy software'owe.

Wbrew jednak temu, co twierdzą niektórzy informatycy, budowa systemów dla biznesu nie jest działalnością stricte innowacyjną i kreatywną. W znacznej mierze polega na rzetelnym odtwarzaniu pewnych standardów i technik dla nowych zastosowań. Tak więc mimo wszystkich różnic, warto inspirować się w informatyce niektórymi technikami zaczerpniętymi z systemów jakości dla produkcji. A przy okazji - nauczyć się kilku japońskich słów, bo choć sama Japonia nie odniosła sukcesu jako producent oprogramowania, to jednak niektóre idee, które stanowiły o jej przewadze jako ultrawydajnego producenta dóbr przemysłowych, mogą zostać zastosowane w informatyce.

Produkować, by nie testować

Prezentację wybranych elementów zacznijmy od rzeczy zaczerpniętej z TQM; najmniej wymiernej, ale najważniejszej: "żeby się chciało chcieć". Mowa nie tyle o stanie mechanizmów zarządczych w organizacji, ile o jej kulturze i stanie ducha osób w niej pracujących. Jeżeli informatycy rozumieją, jaki cel ma przedsiębiorstwo lub projekt, oraz wiedzą, w jaki sposób ich praca może się przyczynić do tego celu i najnormalniej w świecie zależy im na jego osiągnięciu - połowa sukcesu jest za nami. W takiej firmie to jeden człowiek "ciągnie w górę" zespół, a zespół człowieka.

O ile jednak trudno podać dobry przepis na dobrą kulturę pracy, o tyle łatwiej podać przepis na drugą rzecz: systematyczność i porządek, po japońsku seiri. Otoczenie, w jakim pracujemy, rzutuje na efekty naszej pracy - szczególnie wtedy, gdy praca ta wymaga koncentracji uwagi na złożonych problemach. "Środowiskiem pracy" dla informatyka jest z jednej strony fizyczne miejsce, w którym siedzi, z drugiej zaś - jego "warsztat wirtualny", czyli aplikacje i systemy, które służą do codziennych zadań. Dobrym przykładem jest sposób zorganizowania biura; kontrproduktywne jest np. sadzanie informatyków w środowisku hałaśliwym, niedającym odrobiny prywatności i poczucia osobistej przestrzeni, niepozwalającym na skupienie. Nie mniej ważne jest środowisko wirtualne - przeszkadza w pracy nieustannie przychodząca poczta elektroniczna lub dzwoniący telefon; całe dnie "rwane" spotkaniami, nieustanne zmiany planu i harmonogramu. Nic dziwnego, że produkt wychodzący z rąk takiego informatyka jest chaotyczny, pełen niedoróbek i niekonsekwencji.

Zadziwiająco niewiele firm informatycznych stosuje coś, co znane jest z inżynierii mechanicznej lub budowlanej - książki standardów i stylów. Tymczasem pewne rozwiązania po prostu dają mniej możliwości popełnienia błędu niż inne. Przykładem może być wymuszenie nawyków programistycznych, takich jak możliwie późna deklaracja zmiennej lub możliwe typowanie. Podobne znaczenie mają pewne wzorce (patterns) analizy i projektowania.

Nienależytą wagę w informatyce przykłada się do jakości "surowca informatycznego". W dzisiejszych czasach, kiedy systemy nader często "skleja się" z gotowych komponentów, nader niefrasobliwie podchodzi się do zarządzania tymi komponentami. To także kontrast do np. przemysłu motoryzacyjnego czy lotniczego - tam dostawcy podzespołów muszą wdrożyć nie gorsze systemy jakości niż odbiorca półproduktów. Jedna z zasad lean to partnerstwo z dostawcami w osiąganiu właściwej jakości produkowanych przez nich podzespołów.