Oczywiście wszystko zależy od definicji, których jest mnóstwo w literaturze i internecie. Ale tak czy siak każdy kto choć trochę testował jest w stanie defekt określić jako mniej więcej "podejrzane zachowanie systemu" (1). Problem zaczyna się kiedy zaczniemy wnikać w szczegóły - gdzie zwykle diabeł nocuje.
Mnie zawsze interesowało co oznacza "podejrzane". Na jakiej podstawie stwierdzamy, że to konkretne działanie jest podejrzane a inne nie... oczywiście, że dużo zależy od doświadczenia, wiedzy, rozumienia systemu i reguł biznesowych nim rządzących ale i tak w każdym porządnym systemie ewidencji defektów istnieje flaga "To nie defekt" ("Not a bug") albo "Działa OK" ("Work as designed") lub inne temu podobne.
Wskazuje to na fakt, iż w jakiejś mierze jest to zgadywanie poparte bardziej (większe prawdopodobieństwo) lub mniej (mniejsze prawdopodobieństwo), iż poprzez proces intelektualny opisane przez nas symptomy będą rzeczywiście wskazywać na defekt.
Oznacza to, iż nie można tak zwanych raportów z defektów pozostawić samych sobie czyli systemowi ewidencji i zaszytemu w nim procesowi przetwarzania cyklu życia defektu. Według mnie takie systemy - a zwłaszcza cykle - nie obejmują tylko defektu obejmują także incydent.
Incydent staje się defektem dopiero po potwierdzeniu (czy to przez architekta, szefa działu rozwoju oprogramowania, lub biura do spraw jakości lub kogokolwiek innego władnego w tym zakresie) staje się on defektem. W ten sposób można oszczędzić wiele pracy i czasu przy naprawianiu nieistniejących defektów (efekt "brzydkiego kaczątka") lub poprawianiu funkcjonalności, która działa zgodnie ze specyfikacją.
Niestety, większość firm, z którymi ja miałem doczynienia podchodzi do zarządzania incydentami dosyć spolegliwie. Jedynym wyjątkiem są sytuacje, w których odbiorca zastrzega sobie kontrolę nad procesem dostawy.
Nie będę tutaj przytaczał konkretnych przykładów jednak chciałbym wymienić kilka zagrożeń związanych z takim macoszym traktowaniem defektów:
- Naprawa nieistniejących defektów
- Poprawa funkcjonalności nie wymagających takowej poprawy
- Strata czasu inżynierów rozwoju oprogramowania
- Komplikowanie rozwiązań
- Utrata świadomości lub raczej wyczucia systemu
- Brak zrozumienia natury procesu rozwoju konkretnego produktu
AD #1
To chyba jest oczywiste więc nie będę się rozpisywał. Chodzi po prostu o naprawianie czegoś co nie wymaga naprawy, a co naprawione niepotrzebnie na 100% wygeneruje więcej błędów. Następnie w czasie pomiędzy naprawianiem tego czegoś a wycofaniem tej naprawy, te "wirtualne" defekty zostaną naprawione co w sytuacji wycofania zmiany pierwotnej wygeneruje kolejny poziom defektów... taka baba w babie... a ponieważ nie zawsze da się utrzymać ścisły związek pomiędzy defektami a zmianami w kodzie... to mamy gotowy duży problem.
AD #2
Sytuacja podobna do poprzedniej... choć chyba ma większy wpływ na systemy wbudowane niż serwerowe. Czasami wyżyłowanie jednego parametru może spowodować kolosalne szkody.
AD #3
To chyba też oczywistość... nie chodzi tylko o czas zużyty na naprawę ale potem czas zużyty na "odkręcanie" tego...
AD #4
Jeśli w porę nie zostanie określone czy dany incydent jest, czy nie jest defektem, bardzo często dokonuje się tak zwanej "aktualizacji dokumentacji" poprzez np. żądania zmian (change requests). Jeśli taka nielegalna zmiana zostanie uznana za oficjalną to może się okazać, że implementuje się funkcjonalność do której system nie jest w ogóle przeznaczony... a konsekwencją tego jest oczywiście lawina defektów...
AD #5
Tutaj mam na myśli raczej fakt, wiele zmian "ułatwia" zapomnienie o końcowym celu projektu i "szatkowania" go poprzez problemy bieżące. Choć może z drugiej strony może to pozwala zrozumieć lepiej naturę problemu!?
AD #6
Tutaj chcę podkreślić tezę, że "brak uczestnictwa kierownictwa projektu w takim wydarzeniu jak przegląd defektów pozbawia go wyczucia natury projektu", jego problemów, ograniczeń oraz możliwości rozwoju. Jest to po prostu spolegliwe pozbywanie się ogromnych zasobów wiedzy... wiedzy która nie wynika tylko z raportów o incydentach ale także z komentarzy różnych stron uczestniczących w projekcie. Dodatkowo pozwala w łatwy sposób dystrybuować specyficzną dla danej strony projektu (np. testerów) wiedzę na całą populację projektu co znakomicie ułatwia rozwijanie łańcuchów komunikacyjnych w obrębie projektu.
Reasumując, uważam że raporty zgłaszane przez testerów powinny być traktowane jako raporty z incydentów a dopiero po potwierdzeniu i weryfikacji u programistów, architektów lub innych kompetentnych osób powinien być akceptowany jako bug. Następnym natomiast krokiem powinno być zdecydowanie czy dany defekt naprawiać czy nie... ale to już inna historia.
Brak komentarzy:
Prześlij komentarz