Jakość w procesie tworzenia oprogramowania

Gdyby zapytać jakiegokolwiek programistę, czy jego systemy są wysoko jakościowe, czy stosuje Dobre Praktyki, wzorce, standardy – otrzymamy odpowiedź, że jak najbardziej, że oczywiście! Przecież każdy dba o jakość swojego systemu!

Gdyby jednak zapytać konkretnie, co robią by podnieść jakość aplikacji to tutaj już odpowiedzi zaczynają być różne. Najczęściej programiści podkreślają istnienie testów bądź też testów jednostkowych w procesie tworzenia oprogramowania. Inni zaznaczają stosowanie standardów nazewniczych podczas developmentu. Inni jeszcze chwalą się stosowaniem przedrostków w nazewnictwie tabel, pakietów czy procedur.

Oczywiście wszystkie te elementy (stosowane sensownie) to bardzo dobre kroki. Jednak łańcuch jest tak mocny jak jego najsłabsze ogniwo. Jeśli jakość jest stosowana tylko w wybranych elementach lub dopiero w jednym z ostatnich etapów tworzenia oprogramowania (testy) to nie można powiedzieć, że system jako całość ma wysoką jakość.

Etap testów z reguły jest traktowany jako odpowiedzialny za jakość w systemie. Nie bez przyczyny etap ten nazywany jest Quality Assurance – czyli Zapewnianie jakości. I to byłoby w porządku, gdyby to nie był JEDYNY etap, na którym myśli się o jakości.

Jakość to jednak nie tylko testy. Jakość to jednoznaczne, zrozumiałe wymagania. Jakość to spójny projekt. Jakość to ortagonalny, łatwy do modyfikacji i przetestowania kod. Jakość to różne rodzaje testów: testy jednostkowe, automatyczne, funkcjonalne, regresyjne. Jakość – to łatwość wdrożenia, łatwość utrzymania i rozwoju. Jakość to system zgodny z wymaganiami, wydajny, bez błędów, łatwy do modyfikacji i rozwoju.

Brak jakości powoduje, że system jest bardzo trudny do przetestowania i znalezienia oraz naprawy błędów. Większości błędów na etapie testów tester wręcz nie ma szans znaleźć. Niektóre błędy wynikające ze słabej jakości wymagań czy projektu w ogóle nie są możliwe do przetestowania i zostaną znalezione dopiero przy eksploatacji przez użytkownika końcowego lub przy próbie dalszego rozwoju. Na zadbanie o jakość jest już na etapie testów często po prostu za późno.

Brak jakości na jednym etapie ogromnie wpływa na koszty i jakość kolejnego etapu, co z kolei lawinowo przekłada się na niską jakość na kolejnym etapie. Błędy na etapie analizy przekładają się na gorszą jakość projektu. Słaby projekt prowadzi do niskiej jakość kodu. Kiepski kod – powoduje trudności w poprawnym przeprowadzeniu testów i znacznie zwiększa koszty takich testów. Słabej jakości testy zaś nie wykryją błędów i skończy się to oddaniem klientowi wadliwej i niskiej jakościowo aplikacji.

Żeby osiągnąć wysoką jakość w aplikacji należy o nią dbać na wszystkich etapach tworzenia oprogramowania. Każdy etap powinien mieć wdrożone metody zapewniania jakości dostosowane do konkretnego etapu. Jakość aplikacji jest wynikiem jakości poszczególnych etapów. Testy to jedynie weryfikacja poprawności działania systemu, weryfikacja jakości.

Nie czekajmy do etapu testów, by myśleć o jakości! Dbajmy o jakość na wszystkich etapach tworzenia oprogramowania – od analizy, przez projektowanie wysokiego i niskiego poziomu, development aż po testy, wdrożenie i eksploatację! To się opłaca!