KISS, czyli nie komplikuj, głuptasku

29 kwietnia 2018 | Słowotok, czyli felietony

Łapka w górę, kto słyszał o regule KISS. Oczywiście nie mogę Was widzieć, ale wyobrażam sobie, że zgłosiłby się każdy, kto już dłuższy czas pracuje przy wytwarzaniu oprogramowania, a ten, kto pisze automaty i programuje już na sto procent. Ale czy wiecie jaka jest historia tej reguły? I jak można ją wykorzystać w testach?

Keep it simple, stupid. Takie rozwinięcie akronimu znamy dzisiaj, choć ciekawostką może być, że kiedy powstało, pozbawione było przecinka pomiędzy „eskami”, co sprawiało, że rzeczownik wówczas był przymiotnikiem, a całość pozbawiona była negatywnego wydźwięku. Po polsku tłumaczylibyśmy „Spraw, by było to tak proste, że aż głupie”. Ale zasada (przynajmniej w tłumaczeniu na nasz ojczysty język) z czasem postanowiła poddać się rekurencji i dziś możemy powiedzieć „Nie komplikuj, głuptasie!”. Oba rozwinięcia jednak niosą tę samą treść: zachowaj umiar.

Narodziny tej przeuroczej i znanej dziś niemal każdemu reguły datuje się na lata 60. ubiegłego wieku, a za autora uznaje się Kelly’ego Johnsona – amerykańskiego inżyniera lotnictwa i pracownika Lockheed Skunk Works, którego entuzjaści wojskowości, szpiegostwa czy aeronautyki mogą kojarzyć i wiązać ze „szpiegowskim” samolotem dalekiego zasięgu Lockheed SR-71 Blackbird. Panu Johnsonowi i jego kolegom po fachu zależało na tym, by samoloty przez nich projektowane były jak najprościej. Celem tej prostoty było ułatwienie pracy jego użytkownikom na polu walki: każdy, nawet średnio uzdolniony mechanik, powinien być w stanie naprawić maszynę. I to z użyciem prostych narzędzi. Oczywiście w polowych warunkach.

Jak to zwykle z wojskowymi wynalazkami zwykle bywa, zasada szybko przesiąknęła na grunt cywilny, stając się w latach 70 nawet bardzo popularną. A dzięki własnej prostocie i uniwersalności, zdążyła też wyewoluować w inne rozwinięcia – oto tylko kilka z wielu przykładów:

„Keep It Super Simple”
„Keep It Simple, Sweetie”
„Keep It Small and Simple”
„Keep It Simple, Smart”
„Keep It Short and Simple”
„Keep It Short and Sweet”

Zasadę KISS przywołuje się dziś w architekturze, budownictwie, biznesie czy… programie 12 kroków, który możecie kojarzyć z grupami AA. No i oczywiście w programowaniu. Ale w zasadzie nie ma takiej dziedziny, w której nie można by jej wykorzystać. A już tym bardziej w testowaniu, które leży tuż obok programowania.

Największe możliwości wdrożenia zasady KISS upatruję w przypadkach testowych i pozostałej dokumentacji naszej pracy. Głównie chyba dlatego, że to przy tym konkretnie aspekcie najczęściej zdarzało mi się przebąkiwać pod nosem: „Keep it Simple, Stupid”. No i przypadki testowe zawsze postrzegałam jako podstawowe źródło łatwo przyswajalnej wiedzy. Poniżej dla ułatwienia będę posługiwać się przede wszystkim stwierdzeniem „przypadki testowe”, ale większość pozostanie prawdziwa, jeśli zamienicie słowo na „dokumentacja”.

Less is more, a elegancja to umiar

Choć zgadzam się ze słowami Eddiego Veddera z piosenki „Society”, że powiedzenie „Less is more” znacznie utrudnia utrzymywanie wyników, to jednak jego zastosowanie w wielu dziedzinach jest całkiem przydatne. W tym miejscu mam na myśl liczbę przypadków testowych. Ich mnogość w pierwszym kontakcie zwykle sprawia, że oblewa mnie zimny pot. I owszem, są systemy tak złożone, że mogą wymagać wielu przypadków. Ale z własnego doświadczenia wiem, że jednak znakomita większość wcale taka nie jest, a ogromne ilości dokumentacji biorą się z tego, że albo nie sprawdzamy, czy nie istnieje już przypadek pokrywający daną funkcjonalność (lub mogący ją pokryć po drobnej modyfikacji), albo przyjęliśmy strategię tworzenia przypadków sprzyjającą ich mnożeniu (np. znaczne skrócenie ścieżek, produkowanie ogromnej ilości „unhappy pathów”, podczas gdy te łatwo można wywnioskować z „happy pathów”). Najlepiej liczbę przypadków monitorować już od samego początku istnienia projektu, zwykle ich “niezdrowy” przyrost jest widoczny na tyle szybko, że strategię możemy zmienić relatywnie bezboleśnie. A jeśli tego nie zrobimy, to problem będzie narastał, zwykle logarytmicznie.

Einstein: Jeśli nie potrafisz czegoś prosto wytłumaczyć, nie rozumiesz tego dostatecznie dobrze

Kiedy zimny pot na mym ciele wysycha, pojawiają się dreszcze. A te związane są z tym, że przypadki testowe są tak skonstruowane, że nic z nich nie rozumiem. Nieraz zdarzało mi się trafić na coś, co wskazywało że autora poniosła ułańska fantazja i zapomniał, że nie każdy zna jego żargon, a już na pewno nie każdy zna zawiłości i powiązania projektowe, które pozwolą wykonać dany przypadek. Zdarzyło mi się trafić na krok „wystartuj proces”. Po dochodzeniu trwającym około godzinę okazało się, że „wystartowanie” nie jest takie proste, ponieważ pomijając całą masę wymagań wstępnych, powinnam jeszcze włączyć w przeglądarce konsolę i wykorzystać odpowiednią funkcję, a jej wywołanie zmienia się w zależności od środowiska na którym testuję. Ktoś może powiedzieć, że tutaj po prostu ktoś… popłynął z prostotą. Ale pamiętajmy, że prostota to nie tylko ilość, ale także jakość.

Da Vinci: Prostota jest szczytem wyrafinowania

Zrozumienie zawiłości projektowych może okazać się dopiero małym kroczkiem do pojęcia całości – często skomplikowanie technologiczne idzie w parze z językowymi zawiłościami. I o ile trudne słowa ładnie wyglądają we wpisach blogowych (hehe), o tyle długie i skomplikowane zdania utrudniają odbiór treści przypadku. To prawda, że słowa takie jak trychotomia, kuriozum, majuskuła i minuskuła czy atawizm brzmią świetnie i pozwalają nam zabłysnąć w towarzystwie czyniąc, że jesteśmy postrzegani jako bardziej światowi. Sytuacja jednak nie jest już taka kolorowa, kiedy chcemy szybko przyswoić jakąś wiedzę albo mamy mało czasu na testy, a musimy korzystać z googli by zrozumieć co autor miał na myśli.

Przypadki testowe? A komu to potrzebne? A dlaczego?

Kiedy sama tworzę przypadki testowe mam z tyłu głowy zawsze kilka pytań: czy ktoś będzie miał chęć i cierpliwość, by przyswoić dokumentację w takiej formie? Czy będzie dla niego to przydatne? Czy będzie wiedział jak to wykorzystać i rozbudować? Głęboko bowiem wierzę, że pisanie dokumentacji i przypadków testowych ma sens tylko wtedy, kiedy ktoś będzie mógł (i chciał!) z tego korzystać. A im prostsze będą, tym przyjemniej będzie się do nich zaglądać i do nich wracać.

Podsumowując, gdyby zastosować zasadę KISS do przypadków testowych i pozostałej dokumentacji, to moglibyśmy je opisać:

Mało,
Zrozumiale technologicznie i językowo,
Użytecznie.

Oczywiście zasadę KISS można też wdrażać w innych „działkach” naszej pracy – automatyzacji testów, komunikacji, narzędzi, „stajni” narzędzi i technologii. Wszystko tak naprawdę zależy od tego, jak bardzo chcemy uczynić świat wokół siebie prostszym 🙂

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!