Definicja błędu oprogramowania. Blizzard Entertainment twierdzi, że mój „błąd” wcale nie jest błędem. Czy oni mają rację? [Zamknięte]

Według Wikipepdii

Błąd oprogramowania jest powszechnym terminem używanym do opisania błędu, wady, pomyłki, awarii lub błędu w programie komputerowym lub systemie, który daje niepoprawny lub nieoczekiwany wynik lub powoduje, że zachowuje się w niezamierzony sposób.

Ostatnio znalazłem „błąd” w StarCraft 2, który powoduje nieoczekiwany rezultat: http://eu.battle.net/sc2/en/forum/topic/2868627470

Problem polega na tym, że jeśli utrzymam minimalizację StarCraft 2 przez długi czas, gra nie rozłącza się ani nie generuje żadnej przerwy. Rozłącza się jednak po pierwszej bitwie i czasami traci dane gry (statystyki meczów).

Niestety, według Blizzarda:

Gra nie została zaprojektowana tak, aby była zminimalizowana przez tak długi okres czasu. (Blizzard) nie może uważać takiego zachowania za błędne, ponieważ StarCraft II nie ma być minimalizowany przez wiele godzin.

Czy mój „błąd” naprawdę jest błędem?

Dla zespołu oprogramowania błąd jest problemem oprogramowania, który należy naprawić. Nie wszystkie problemy z oprogramowaniem muszą zostać naprawione.

Aktualizacja oprogramowania jest droga. Blizzard mówi ci, że twój problem jest poważny . Innymi słowy, wykryty przez Ciebie problem przypadku niekoniecznie jest czymś, co przetestowali lub w inny sposób chcieliby wyjaśnić. Naprawienie problemu pomoże ci, ale najprawdopodobniej nie pomoże wielu innym. Koszt naprawy błędu może być jednak wysoki. Zamiast tego mogą inwestować swoje zasoby w nowe funkcje, a nawet ukończyć Diablo III.

Ten rodzaj przypomina mi kota w kuchence mikrofalowej , a konkretnie przypadek pani Smith z 1983 roku.

Chodzi o to, że oczekujesz, że produkt będzie działał w taki sposób. Głównie dlatego, że wiele podobnych produktów działa w ten sposób, tzn. Jeśli zminimalizujesz je na kilka godzin, a następnie otworzysz, będą działać (chociaż przeciwnie nie jest tak rzadkie, jak mogłoby się wydawać).

Pani Smith wiedziała ze swojego doświadczenia, że ​​suszenie kotów w piekarniku ich nie skrzywdzi (zakładając oczywiście ostrożność). Dokładniej z doświadczenia, jakie miała ze wszystkimi piekarnikami, których próbowała. Potem założyła, że ​​tak samo będzie z kuchenką mikrofalową, którą otrzymała. To założenie było błędne. Mikrofale nie są przeznaczone do suszenia kotów. Nie są też konwencjonalne piece. Zdarza się, że nie zabijają kota w tym procesie jako efekt uboczny procesów fizycznych, które wykorzystują do wytworzenia ciepła.

Teraz, jako producent mikrofal, możesz umieścić w kuchence mikrofalowej cewkę grzejną i liczbę czujników. Ten ostatni określa, czy obecna zawartość jest kotem i używa cewki zamiast mikrofal.

W ten sam sposób, że można by wyprodukować kuchenkę mikrofalową odpowiednią do suszenia kotów, Blizzard mógłby stworzyć wersję SC2, która jest odpowiednia do pozostawania w stanie zminimalizowanym przez dłuższy czas.

Osobiście byłbym skłonny zapłacić więcej pieniędzy za kuchenkę mikrofalową z funkcją suszenia kota tylko dla samej przyjemności (zakładając, że z przodu jest duże logo przydatności do suszenia kota), z dumą mogę wskazać). Ale nie dbałbym o grę, która może pozostać zminimalizowana przez wiele godzin.

SC2 został zaprojektowany, aby spełnić określone wymagania. Twoje oczekiwania nie są częścią tych oczekiwań. Możesz mierzyć SC2 pod kątem swoich oczekiwań. Ale to, czy Blizzard obejmuje je wszystkie w zakresie swoich wymagań, jest ostatecznie ich wyborem.

Jedyne, o co naprawdę można się kłócić, to to, że jest to awaria projektu. Zdrowy rozsądek nakazuje, że jeśli znaczna część użytkowników nie jest zdezorientowana projektem lub niezadowolona z niego, jest wystarczająco dobra. Jestem pewien, że jeśli wystarczająca liczba użytkowników stwierdzi, że podzielają twoje oczekiwania, Blizzard ustąpi i uwzględni je w projekcie. To sprawi, że twój problem będzie prawdziwym błędem, a Blizzard go naprawi.

Myślę, że jest to przypadek, gdy oprogramowanie nie jest używane zgodnie ze specyfikacją. Mówią

Gra nie została zaprojektowana tak, aby była zminimalizowana przez tak długi okres czasu.

Co oznacza, że ​​mają gdzieś definicję tego, co liczy się jako „długi okres czasu”. Jeśli zminimalizujesz program na więcej niż „długi okres czasu”, wykracza on poza specyfikacje i wykracza poza to, na co testowali (zakładając, że formalnie to uczyli) i nie gwarantują, co się stanie. Oczywiście byłoby miło, gdyby gdzieś w instrukcji było napisane: „Testowaliśmy ten program, aby go zminimalizować na okresy nieprzekraczające 10 minut. Minimalizuj na dłużej na własne ryzyko!”.

Więc nie, nie sądzę, że to naprawdę błąd. W moim biurze byłoby to nazywane „problemem szkolenia użytkowników” (który powiedziałbym, że jest to forma problemu z komunikacją , ponieważ w tym przypadku nie podano użytkownikowi maksymalnego okresu minimalizacji czasu), ponieważ użytkownik jest niewłaściwe korzystanie z programu. Nie dlatego, że to bardzo pomaga Blizzardowi, chyba że umieścili go w instrukcji ...

To nie błąd. Błąd to zachowanie niezgodne ze specyfikacją. Jeśli specyfikacja mówi, że przypadek użycia nie jest obsługiwany, to każde zachowanie - postrzegane jako prawidłowe lub nie - w tym przypadku użycia jest „zgodne z projektem”.

W tym scenariuszu działająca gra może być postrzegana jako zachowanie nieokreślone.

Gdybym był kierownikiem zespołu programistycznego tego projektu, nazwałbym to błędem, ale drobnym, ponieważ znacznie wykracza poza normalne oczekiwania dotyczące oprogramowania. Jeśli miałoby to w ogóle zostać opracowane, prawdopodobnie przypisałbym to młodszemu programistowi lub nowemu zatrudnieniu bardziej jako ćwiczenie edukacyjne dla nich niż cokolwiek innego.

Dobrym pomysłem jest śledzenie tych drobnych błędów, ponieważ mogą one wskazywać potencjalnie daleko sięgające problemy. Na przykład napotkany błąd zapisu danych. Wydaje się to niewielkie ze względu na to, jak to się stało, ale mogą istnieć inne przypadki utraty danych. Korzystając z systemu zgłaszania błędów, możesz znaleźć wszystkie przypadki, w których pojawił się podobny problem i sprawdzić, czy istnieje jakiś wspólny element. W złożonym systemie udokumentowanie tego rodzaju rzeczy może pomóc w znalezieniu poważniejszych i subtelniejszych błędów.

Nie zgadzam się z większością ludzi tutaj.

Jako były gracz (oryginalny) StarCraft mogę potwierdzić, że jest to (lub przynajmniej było) bardzo częste zachowanie. Użytkownicy opuszczają grę 24 godziny na dobę, 7 dni w tygodniu, aby utrzymać swoją pozycję w pokojach czatu i dołączać do gier, gdy wrócą. Jestem pewien, że zaktualizowane Battle.net ma pewne ulepszenia, które mogą zmniejszyć potrzebę tego, ale wciąż się to zdarza.

Byłoby o wiele bardziej sensowne, aby nie pozwalało ci dołączyć do gry bez ponownego połączenia, jeśli sesja w jakiś sposób, kształcie lub formie wygasła. To, że pozwala ci dołączać do gier po zakończeniu sesji, jest dla mnie błędem. Niepokojące jest tutaj to, czego tak naprawdę jeszcze nie poruszono, że programiści muszą zrozumieć swoich użytkowników. Może to być bardzo dobry przypadek, ale jest to bardzo dobry przypadek dla bardzo oddanych graczy, którym powinni się zadowolić.

Technicznie mogą argumentować, że jest to zgodne z projektem i nie jest to coś, co zamierzają naprawić. To wciąż wina w moich oczach, która ostatecznie zależy od nich, czy zaklasyfikują to jako błąd. To nie znaczy, że gracze się zgadzają.

W każdym razie myślałem, że przedstawię nieco inną odpowiedź niż ta, która została opublikowana do tej pory.

Błąd można zasadnie zdefiniować jako „każde odchylenie od zamierzonego zachowania oprogramowania”.

Najwyraźniej oni (i to ich oprogramowanie, aby mogli ustalić, jak powinien się zachowywać) nigdy nie zamierzali obsługiwać tego scenariusza, więc nie spełnia definicji błędu.

Jednak powiedziałbym, że przynajmniej nieoptymalny jest sposób, w jaki radzi sobie z tym warunkiem.

Zaśmiecanie, wyrzucanie śmieci (to znaczy, że użytkownik robi coś głupiego, złego lub nieoczekiwanego, a w rezultacie dzieje się coś złego) zostało uznane za zły standard zachowania. Powiedziałbym, że przynajmniej powinien być bardziej elegancki w sposobie radzenia sobie z tym warunkiem.

Więc nie tylko błąd, ale zła obsługa przypadku krawędzi.

To powiedziawszy, gdybym był nimi, nie jest to coś, co prawdopodobnie uważałbym za warte naprawienia (zbyt kosztowne za zbyt małą korzyść), chociaż mógłbym wspomnieć o tym zespołowi w celu odniesienia w przyszłości, że to coś, z czym mogliby sobie poradzić lepiej.

Definicja błędu nie ma nic wspólnego z zachowaniem oprogramowania. Błąd jest definiowany na podstawie tego, czy zachowanie oprogramowania odpowiada jego zamierzeniu. A kto ma powiedzieć, jaki był zamiar? (Ponieważ mam tutaj do czynienia z programistami, wyjaśnię pierwsze zdanie - nie ma możliwego zachowania oprogramowania, które samo w sobie stanowi błąd).

Należy pamiętać, że ogólnie błąd jest czymś, co twórcy oprogramowania powinni naprawić. Tak więc definicja błędu opiera się na tym, co chcą naprawić. Na przykład „prawidłowe działanie przez ponad 50% czasu to funkcja, którą planujemy wydać w przyszłych wersjach”. Wszystko można zdefiniować jako nie będące błędem, udając, że oprogramowanie nigdy nie miało na celu rozwiązania tego konkretnego problemu. Tak więc w praktyce błąd stanowi kwestię czysto polityczną.

(Nawiasem mówiąc, ogranicza to obie strony. Dla klienta, który nie musi płacić za poprawki błędów, ale musi płacić za nowy rozwój ”, nie ma funkcji, o której przed chwilą myślałem, ale którą teraz mam Zdecydowałem, że jest w 100% implikowany przez rzeczy, o których wspomniałem „to oczywiście błąd.)

Nie rozważałbym nie odłączenia błędu. Jest to tylko błąd, jeśli miał (z założenia, z założenia) się rozłączyć i tak się nie stanie. Zadzwoniłbym do tego, co przesłałeś żądanie funkcji.

To powiedziawszy, utrata danych po bitwie - to może być błąd. Nie wiem wiele o Starcraft, ale podejrzewam, że to nie z założenia.