Nauka a praktyka: czego brakuje w publikacjach naukowych dotyczących testowania oprogramowania?

Nauka a praktyka: czego brakuje w publikacjach naukowych dotyczących testowania oprogramowania?
Analiza publikacji naukowych, dotyczących zagadnienia jakości i weryfikacji oprogramowania może pozwolić wyciągnąć wnioski dotyczące braków w ich zawartości.
Publikacji naukowych zajmujących się tematem jest, według moich szacunków, ponad tysiąc. Jest ich wiele, ale poświęcając odpowiednią ilość czasu, możliwe jest zapoznanie się z nimi. Oto kilka moim zdaniem najpoważniejszych braków.
  1. Artykuły naukowe zawierają małe powiązanie oraz małe odniesienie do praktyki. Większość artykułów zawiera badania nieprzydatne testerowi, który pracuje w firmie zajmującej się tworzeniem oprogramowania i testującej je pod kątem poprawności oraz zgodności ze specyfikacją. W testowaniu nie jest ważne porównywanie czasów rozwiązań problemów postawionych w publikacjach. Dla testera ważne jest samo wygenerowanie danych diagnostycznych bądź wygenerowanie przypadków testowych, które będą poprawne i będą w stanie sprawdzić poprawność testowanych funkcjonalności.

  2. Nieznajomość specyfiki pracy branży tworzącej oprogramowanie. Zdarza się, że problemy postawione w publikacjach naukowych niekoniecznie są problemami występującymi w praktyce. Porównywania algorytmów albo wyścigi algorytmów na czas realizacji np. generowania danych diagnostycznych nie są wcale potrzebne testerom w praktyce. Jeśli dwa algorytmy potrafią rozwiązać pewien problem, przy czym czas rozwiązania między jednym a drugim algorytmem różni się o kilka sekund, to z testerskiego punktu widzenia nie ma sensu kategoryzować takich algorytmów, ponieważ oba są równie dobre.

  3. Mylne przekonanie o tym, że testowanie polega na wyszukiwaniu błędów. Często w artykułach naukowych pojawia się zdanie czy zwrot, że "testowanie służy do znajdywania błędów". Nie jest to prawda, ponieważ testuje się oprogramowanie po to, aby sprawdzić poprawność działania zaimplementowanych w nim funkcjonalności. Owszem, jeśli w testowanym programie występują błędy, to przypadki testowe powinny być na tyle dobre i poprawne, by je wychwycić. Natomiast nacisk na orientowanie się na błędy z perspektywy programistów jest czynnością destrukcyjną. Może to negatywnie wpłynąć na powodzenie projektu informatycznego.

  4. Prosty i krótki  kod testowanego programu. Algorytmy ewolucyjne lub tradycyjne przedstawione w artykułach naukowych związanych z wykorzystaniem instrukcji kodu na ogół są niewielkie. Takich aplikacji nikt tak naprawdę nie stosuje, ani nie testuje jako całości systemu. Współcześnie sprzedawane oprogramowanie lub oprogramowanie pisane na życzenie posiada dużą ilość kodu. Podział oprogramowania na klasy czy segmenty ma sens z punktu widzenia tworzenia przypadków testowych albo testów integracyjnych. ”Prawdziwe” oprogramowanie, na którym firma programistyczna chce osiągnąć dochody, jest zazwyczaj złożone i zawiera sporo kodu. Proste programy są na ogół darmowe, czyli na licencji open source.

  5. Brak wskazania testera jako odbiorcy treści zawartych w artykule. Najczęściej artykuły naukowe (szczególnie te wymienione w bibliografii) pisane są w taki sposób, aby były przyjęte w wysoko punktowanym czasopiśmie lub w czasopiśmie z dużym współczynnikiem IF (ang. impact factor), co zdecydowanie nie jest skierowane do osoby testującej oprogramowanie zawodowo. Osoba testująca pragnie mieć podany dobry oraz działający sposób podejścia do testów w przypadku nietypowych problemów.

 

Prawdziwe staje się więc, że dla testera, bardziej od artykułów naukowych, przydatne są magazyny branżowe lub książki pisane przez osoby znające testowanie od strony praktycznej.

 

 

Autor: Marek Żukowicz

 

 

To powinno Cię zainteresować