W ramach zwinnego podejścia do pracy, koncepcja „kątowego przypadku” (ang. conrner case) odgrywa ważną rolę. W dzisiejszym artykule przyjrzymy się bliżej temu terminowi i dowiemy się, dlaczego jest on tak istotny.
Co to Corner Case?
Corner case (kątowy przypadek) to termin powszechnie używany w dziedzinie testowania oprogramowania. Jest to scenariusz lub sytuacja, która występuje rzadko lub w szczególnych warunkach. Corner case’y są trudne do przewidzenia i nie są uwzględniane w podstawowym zakresie pracy projektu. Mogą być wynikiem błędów, które pojawią się w niecodziennych okolicznościach albo przecięciem wielu przypadków brzegowych.
Zanim przejdziemy do dalszego znęcania się nad corner case, warto przypomnieć czym jest „przypadek brzegowy” (ang. edge case) i czym się różnią. Edge case oznacza szczególny przypadek lub zestaw danych, który jest granicznym lub ekstremalnym przypadkiem testowym. Przypadek krańcowy jest to taki scenariusz, który znajduje się na granicy zakresu, gdzie produkt lub system może zachowywać się inaczej niż w typowych sytuacjach.
„Krawędzie” bardzo często wyznaczają nam dane – jeżeli maksymalna wartość szybkiego przelewu to 500 zł, to przypadki krańcowe to oczywiście 0, 1, 499, 500 i 501. Nie ma sensu testować wartości pomiędzy 1 i 499, bowiem zakładamy, że funkcjonalność będzie działała w tym przedziale spójnie.
Skąd się biorą Corner Case’y?
Część corner case’ów to oczywiście konsekwencja splotu wielu przypadków brzegowych. Nasz użytkownik chce zrobić przelew na 34 EUR, na koncie ma 35 EUR, ale 2 EUR to koszty przelewu. Ma co prawda 9 zł na koncie, ale to jest mniej niż wartość prowizji w EUR, chyba, że uwzględnimy jeszcze konto w USD, itd., itp. Czytając dowolny raport z badania komisji wypadków morskich bądź lotniczych zwykle zobaczymy, że tragedie nigdy nie były spowodowane jedną rzeczą. To (prawie) zawsze był corner case.
Innym źródłem corner case’ów są szczególne przypadki zewnętrzne. Nasza zautomatyzowana chłodnia pięknie utrzymuje temperaturę nawet w gorące dni, ale w przypadku zmniejszonego ciśnienia czynnika chłodzącego, suszy, upałów i do tego pożaru tuż obok (nieprawdopodobna temperatura powietrza) sterowniki głupieją i nie są w stanie zapewnić odpowiedniego działania. Ponownie ktoś może powiedzieć, że to zestaw przypadków brzegowych – temperatura powietrza „na wejściu” wykroczyła poza zdefiniowane limity. Czasami jednak dzieje się po prostu coś niespodziewanego.
Ryzyka adresowania wszystkich Corner Case
Włączanie kątowych przypadków w proces zbierania wymagań produktu niesie ze sobą zarówno korzyści, jak i pewne ryzyka. Przede wszystkim – nie oszukujmy się, że damy radę wszystko przewidzieć. Próby przygotowania się „na wszystko” mogą zwiększać koszty projektu. Testowanie, analiza i rozwiązywanie nietypowych scenariuszy może wymagać dodatkowych zasobów i czasu.
Skupienie się na corner case’ach może prowadzić do przeznaczania zasobów na mało prawdopodobne scenariusze, kosztem rozwijania nowych funkcji lub rozwiązań kluczowych dla klienta. Może to spowolnić tempo rozwoju i opóźnić dostarczenie wartościowych funkcji. Może też sprawić, że produkt stanie się zbyt skomplikowany, co utrudni jego utrzymanie, konserwację i skalowanie.
Korzyści są oczywiste – wyższa dostępność, wyższa jakość produktu, niezawodność i – być może – zadowolenie klienta. Tylko pytanie, czy klient będzie zadowolony z obsługi przypadków, które nigdy nie wystąpią? Czy jest to działanie zgodne z pragmatyzmem?
Jak uniknąć Corner Case’ów?
Rozbijanie dużych wymagań na mniejsze, bardziej zrozumiałe i zarządzalne części jest czymś, co polecamy wszędzie i zawsze. Istnieje kilka ważnych powodów, dlaczego warto dokonywać takiego podziału mając do czynienia z corner case’ami.
Dzieląc duże wymagania i rozbijając kryteria akceptacji „na atomy” znajdziemy więcej przypadków brzegowych. To z kolei pozwoli nam uzmysłowić sobie, jakie mogą być przecięcia i które z nich powinniśmy zaadresować. Przykład z przelewem jest dość oczywisty. Wiele corner case’ów taka nie jest.
Nawet jeśli zdecydujemy się na działanie pragmatyczne i zaakceptowanie niektórych ryzyk, dzieląc wymagania możemy skoncentrować się na identyfikacji, testowaniu i rozwiązywaniu kątowych przypadków, które mają największe znaczenie lub są najbardziej ryzykowne. Możemy też najbardziej skomplikowane i rzadkie przypadki odłożyć je na później.
To oczywiście nie jest jedyne rozwiązanie. Dobra analiza, profesjonalny zespół, umiejętności analityczne i dobra priorytetyzacja wymagań powodują, że powinniśmy działać nad najbardziej istotnymi rzeczami. Nie musimy przewidywać wszystkiego, tylko to, co może wyrządzić najwięcej szkód lub dać najwięcej szans. Pozostałe rzeczy będziemy realizować, gdy już poznamy skalę zjawiska.
Bo nie ma przecież sensu wydawać milionów na zaadresowanie sytuacji, w której możemy co najwyżej stracić tysiące. Tym bardziej, jeśli prawdopodobieństwo wystąpienia tej sytuacji jest nikłe.
