Czy powinniśmy śledzić wady w rzeczach innych niż kod?

Question

W różnych momentach mojej kariery zachęciłem personel, z którym współpracowałem i/lub udało mi się wykryć defekty artefaktów procesu rozwoju innych niż kod źródłowy (tj. Wymagania, testy, projektowanie). Za każdym razem, gdy prośba została spełniona ze zdumieniem, zmieszaniem i oporem. Wydaje mi się to tak oczywiste, że zawsze jestem trochę zszokowany, kiedy ludzie się temu sprzeciwiają.

To, co otrzymamy z tego ćwiczenia, to obraz miejsca powstawania błędów i ich lokalizacji (w której części procesu). Jeśli tworzymy złe wymagania, będziemy o tym wiedzieć i będziemy mogli je ulepszyć.

Czy ktoś jeszcze zbiera informacje o błędach nie w kodzie źródłowym?

Answer 1

Tak, śledzić wszystkie.

Dokumentacji, Dokumenty projektowe, wymagania itp

Jestem też zdziwiony, jak ty, gdy słyszę „argumenty” przeciw niej.
Co najmniej system śledzenia powinien być w stanie określić, gdzie wykryto usterkę i jaka część procesu została wstrzyknięta.

Answer 2

Tak, zdecydowanie. Artefakty otaczające twój kod - modele, specyfikacje, doco, informacje o wymaganiach, przypadki użycia itp. - mogą zawierać błędy, które wpływają na sam kod.

Answer 3

Zazwyczaj systemy śledzenia błędów mają założenie, że są listą rzeczy, które należy naprawić lub zaimplementować. Śledzenie błędów w wymaganiach lub innych dokumentach (np. Listach zadań) nie wydaje się być tym samym. To bardziej kwestia prowadzenia rejestrów, aby można było zgłaszać problemy i oceniać, czy robisz ich mniej.

Śledzę je, ale poza naszym systemem śledzenia błędów.

Answer 4

Cóż, cóż ... cokolwiek można poprawić, co można poprawić!

Traktowanie wszystkiego jako śledzenie błędów ma sens - opinia będzie się różnić, jak zauważysz - ale użycie jednego systemu śledzenia da spójny duży obraz tego wszystkiego, pozwoli na przypisanie zadań itp. Może demonstracja, pokaz slajdów lub coś, co ma na celu wykorzystanie tych systemów w sposób wykraczający poza oryginalne śledzenie kodu źródłowego - zdjęcia przekonują bardziej niż słowa.

Answer 5

Zazwyczaj śledziłem źródło wszystkich usterek. Mogą zostać naprawione w kodzie, ale niekoniecznie są spowodowane przez to.

Niewłaściwe wymaganie, źle zinterpretowane wymaganie, zły projekt, programiście brainf * rt, zła dokumentacja, zły test, brakujący test, nieaktualny test, kod, który nie robi tego, co robi programista, błąd narzędzia/kompilatora (bardzo rzadko, według mnie), problem z systemem kompilacji ...

Dla mnie wszystkie są "system nie robi tego, co klient chce, aby to zrobił", a wszystkie wskazują, że coś musi zostać zmienione, aby Robi to, co klient chce zrobić. Przekonanie, czy to defekt lub funkcja, albo błąd kodu źródłowego, czy jakaś inna kwestia odwraca uwagę od rozwiązywania problemów.

Answer 6

Absolutnie. Wystarczy spojrzeć na Ubuntu Bug #1.

Answer 7

Jedną z większych rzeczy, o której nikt nie wspomniał, jest stworzenie bazy danych o nieprzyjemnych zapachach i pułapkach do użytku podczas recenzowania.

Jest to nieocenione źródło informacji dla osób, które faktycznie dokonują przeglądu.

To zdecydowanie się opłaca w dłuższej perspektywie. To powinno być również dokument żywo, bazy danych, itd., które są dodawane jako:

• błędy są stałe
• jak rówieśnicy wykonywania opinii i
• jak świeża krew dociera do przyłączenia się do zespołu (-ów) przynosząc ze sobą nową wiedzę i doświadczenie.

HTH.

okrzyki,

Rob

Answer 8

aboslutely. jeśli twój proces jest wystarczająco dobry, aby prześledzić z powrotem źródło defektu do orgin. pomaga klientom i projektantom pokonywać ograniczenia, w których działają.

klientów: opracowanie robota do cięcia trawy, gdzie wszystkie źdźbła trawy mają być cięte do precyzyjnego jednakowej długości

projektant: będziemy leworęcznych nożyczki przedszkolne montowane prostopadle do podłoża zapewniają ostry/precyzyjnych cięć

QA: cięcia są dokładne.

klient: dlaczego 6 dni zajmuje robotowi cięcie trawy. potrzebujemy za 30 minut lub mniej!

wyraźne prześledzenie źródła defektu wydajności może pomóc w formowaniu rozmów i usprawnieniu procesu w przyszłości.

Answer 9

Śledzimy błędy w oprogramowaniu, błędy w dokumentach, błędy w rysunkach i żądania nowych funkcji przy użyciu tego samego narzędzia śledzenia.