Klient – władca wymagań

Niezwykle modnym (wręcz obecnie jedynym słusznym!) podejściem do wytwarzania oprogramowania jest podejście zwinne. Kod, testy oraz wymagania cały czas dynamicznie się zmieniają. Daleko nie szukając: Mail od klienta precyzujący wymagania, wysłany o 11:37:

„…process must assign passengers…”

W zespole panika, ponieważ przetestowany I oprogramowane było zachowanie zupełnie odwrotne. Pożar na całego, gdy nagle o 11:49 przychodzi kolejny mail od klienta:

„ Let me correct the last sentence. … process should not assign passengers…”

I jak tu nie lubić tej pracy…

Kto jest odpowiedzialny za jakość oprogramowania?

Kto stoi na straży jakości oprogramowania? Wiadomo – tester. Do czego sprowadza się więc jego rola? Wytykania gdzie developer popełnił błąd? Marudzenia, że znowu nie ma dokumentacji technicznej? Zdawania trudnych pytań klientowi? Co tak naprawdę sprawia, że możemy nazywać siebie strażnikami jakości?

Czy projekt informatyczny mógłby się udać bez udziału testera? Teoretycznie tak. Co do jego jakości możnaby się wspierać, ale nie ma przeciwskazań, żeby wypuścić software nieprzetestowany.

Natomiast czy można stworzyć software bez udziału programistów? Nie. Więc to programiści, jako niezbędny element projektu informatycznego powinni być odpowiedzialni za jakość. Powinni, ale nie są. Co innego jest napisać kod, a co innego napisać działający kod zgodnie z życzeniem klienta, spełanijący dane reguły biznesowe itp. Dlatego też niezbędna jest tu rola testera.

   Programista jest osobą konieczną, ale niewystarczającą aby projekt informatyczny miał szansę powodzenia.

Najlepiej, gdy programista i tester uzupełniają się nawzajem. Wygląda na to, że testerzy i programiści uzupełniają się nawzajem. Jeden ma wiedzę domenową, drugi ma pogląd na całość projektu. Programista wie CO ma działać, tester wie JAK to coś ma działać. Ostatecznie oboje są odpowiedzialni za jakość dostarczanego produktu. Od ich podejścia zależy, jaka będzie ostateczna ocena ich pracy.

Jeśli po zgłoszeniu błędów programista zaklnie i zwyzywa, że te łajzy znowu się czepiają, a przecież tłumaczył im, że to tak ma działać to zacząłbym się martwić o powodzenie projektu. Z drugiej strony tester wyzywający, że znowu w tym samym miejscu, ta sama funkcjonalność nie działa, też nic dobrego nie osiągnie.

Kluczem do sukcesu jest komunikacja, wzajemne zrozumienie i wyjście na piwo raz na jakiś czas. Nic tak nie rozwiązuje problemów jak kufel dobrej craftowej IPY.

Jak testować coś nowego?

Nikt nie wie wszystkiego. Nie ma osoby, która na poziomie zaawansowanym umie przetestować wszystko. Webówka, aplikacje mobilne, aplikacje desktopowe, backend, frontend, testy sprzętu – tego jest po prostu za dużo. Co więc zrobić, kiedy jesteśmy wrzucani do projektu, gdzie musimy zająć się rzeczami o których nie mamy pojęcia?

W BJJ, zanim zastosuje się nową, nieznaną wcześniej technikę w walce powtarza ją się w nieskończoność na treningu. Zaczyna się og oglądania, jak wykonuje ją trener. Następnie ćwiczy się ją z partnerem, starając się „złapać ruch”. Następnie coraz płynnie, przy zachowaniu koordynacji i detali. Kolejny krok to walki zadaniowe, gdzie przeciwnik stawia czynny opór ale nie na 100%. Powyższe działania trzeba powtórzyć 100 razy, po czym można uznać, że dana technika nie jest nam obca. Oczywiście wykonywać dźwignię/duszenie/sweepa na treningu a wykonywać w walce to dwie zupełnie różne rzeczy. Jak w większości przypadków potrzeba czasu, cierpliwości i systematyczności.

No dobra, a co z testowaniem oprogramowania? Mam iść do seniora i powiedzieć: Ej, stary! Jak się testuje mobilki, pokarzesz mi parę sztuczek? – Słabe, co nie?. Człowiek najwięcej się uczy robiąc rzeczy samodzielnie. Osobiście zacząłbym od google.com oraz youtube.com. Z pewnością problem, który dla nas jest oryginalny, nie raz i nie dwa był przerabiany już w Internecie. Na początek, trochę teorii. Co będziemy testować? Czy ekspert z dziedziny QA wygłosił może konferencję na interesujący nas temat? Czy są jakieś filmiki szkoleniowe, na których ktoś pokazuje, jak należy testować. Jakich narzędzi pomocniczych będę potrzebował? Postmana, Jmetera?

Teorię mamy już za sobą. Pora przejść do praktyki. Na całe szczęście, istnieją środowiska testowe. Tam możemy zacząć przygodę z czymś nowym od najprostszych rzeczy. Testujesz API? Wyślij najpierw jedno, najprostsze zapytanie GET i zobacz, co i w jakiej formie dostaniesz w odpowiedzi. Aplikacja mobilna? Włącz, obróć ekran, przeskroluj, zapytaj się analityka, co ona ma robić. Testujesz sprzęt? Podłącz go do prądu (tak, zdarzyło się znajdywać błędy, związane z tym, że sprzęt elektroniczny lepiej działa, jak się go podłączy do źródła zasilania).

Zasada mówi: od ogółu do szczegółu. Stopniowo wchodź coraz głębiej w funkcjonalności, poznawaj nowe rzeczy i nie bój się zadawać pytania. Jeśli myślisz, że programista ma już Cię dość, to z pewnością nie znasz tych, z którymi ja pracujęJ Wiem, że mają mnie serdecznie dość, ale gdy czegoś nie wiem, to się pytam, a nie domyślam. W końcu razem odpowiadamy za jakość produktu, który dostarczamy.

Z pewnością, im mamy więcej doświadczenia, tym łatwiej będzie nam z nowymi rzeczami. W BJJ mamy pamięć ruchową, czyli pewne czynności robi się automatycznie i nie trzeba się na nich skupiać. W testowaniu oprogramowania wiele rzeczy jest wspólnych, niezależnie od tego co testujesz.  Każda nowa rzecz, to wyzwanie, z której płyną same benefity. Pytanie, jak szybko będziemy spijać śmietankę z efektów naszej pracy?

Eksploracja bez dokumentacji

Zygfryd ze zdumieniem czytał najnowszego maila. Wprost nie mógł uwierzyć temu, co właśnie czytał. Czuł się jakby właśnie dostał prezent urodzinowy i to lepszy niż PS4, które dostał od żony w tym roku. Z niedowierzaniem jeszcze raz przeleciał wzrokiem tekst od góry do dołu. Klient zgodził się, aby testy w projekcie zostały przeprowadzone za pomocą testów eksploracyjnych. Bez test planów, bez test casów, bzdurnych opisów i dokumentacji. Ba! Mało tego, klient zrezygnował z testów automatycznych na rzecz eksploracji!

Do tej pory Zigi nie wiedział, że ma aż taki dar przekonywania. W ciągu godzinnej rozmowy z klientem namówił go na wszystko co chciał. Teraz czuł się, jakby właśnie samego Pana Boga złapał za nogi. Cały czas spędzony w projekcie będzie mógł przeznaczyć w końcu na testowanie a nie pisanie bzdurnych i nikomu nie potrzebnych test planów i obszernej dokumentacji. Jednak marzenia się spełniają.

Kilka dni później pierwsza wersja aplikacji była gotowa na testy. Zygfryd wygodnie rozsiadł się w fotelu, przymknął oczy i zaczął intensywnie myśleć jakie testy by tu wykonać. Po chwili już wiedział. Po prostu odpali aplikacje i przeklika wszystko co mu przyjdzie do głowy. W końcu przy jego doświadczeniu plan działania nie jest potrzebny. Zadowolony z siebie odpalił aplikacje i przystąpił do testów.

Niecałe 6 godzin później pierwsze testy zostały zakończone. Zigi był zadowolony z siebie jak nigdy. Znalazł kilka błędów krytycznych, parę minorów i kilkanaście literówek. W sumie dzień można uznać za udany. Kątem oka zerknął jeszcze na skrzynkę mailową. U samej góry była jedna nieprzeczytana wiadomość. Była od Steve z teamu z USA, który razem z naszym niezłomnym testerem sprawdzał aplikację. Dziękował on mu za dzisiejszą pracę, gratulował znalezionych błędów i prosił o podsumowania, co dzisiaj zostało przetestowane, aby mógł kontynuować testy. W tym momencie Zygfryd oblał się zimnym potem. No właśnie, co on dzisiaj tak naprawdę przetestował? Znalazł błędy, to fakt, ale jakie obszary pokrył testami? W sumie to na pierwszej stronie sprawdził walidacje pól, na drugiej obsługę błędów. Potem sprawdził wynik działań algorytmów i coś tam zerknął do API. Na stronie z podsumowaniem w sumie nie pamiętał co sprawdzał, ponieważ gdy ją testował do pokoju weszła szefowa HRu i przedstawiła nową koleżankę, która dzisiaj zaczynała pracę. W tym momencie krew odpłynęła Zigiemu z mózgu w zupełnie inne miejsce. Spocony, Zigi na szybko napisał bardzo ogólnikowego maila, wyłączył telefon, żeby Steve nie mógł się z nim skontaktować i czym prędzej poszedł do domu.

Następnego dnia, Zigi z niepokojem czytał maila do swojego kolegi z zza ocenau. Steve pisał, że sprawdził główną funkcjonalność aplikacji, następnie obsługę błędów na wszystkich stronach oraz zostawił włączoną aplikację, tak aby sprawdzić, czy dalej będzie działać po 24h nieprzerwanej pracy. Dodatkowo wysłał skan swoich notatek, gdzie spisał swoje spostrzeżenie, obszary warte ponownego sprawdzenia i wnioski. Poziom zdenerwowania Zygfryda rósł z każdym kolejnym czytanym zdaniem. Jego kolega ze Stanów był w tym momencie od niego lepszy. Przeprowadził lepsze testy i dał dużo lepszy feedback na temat swojej pracy. Zdenerwowany, ale z drugiej strony nieco zrezygnowany Zigi odpalił Google i wpisał nową frazę do wyszukiwarki: how to test using exploratory tests books…

 

Cztery metody powrotu do formy.

Kontuzje, wypadki losowe, L4. Lista rzeczy, która może uniemożliwić pracę i treningi jest długa. Przerwa od trenowania ciała i umysłu może trwać nawet miesiącami. Jak wrócić do pełnej formy po dłuższej przerwie?

Znasz to uczucie, kiedy przychodzisz na matę i jedynym pomysłem jaki masz podczas walki to balacha z gardy? Berimbolo? To chyba była nazwa drinka. Rolling panda na rozgrzewce? To jakiś taniec nowoczesny?

Wracasz do pracy, a jakiś junior pyta się ciebie o 7 zasada testowania. Coś tam było w sylabusie ISTQB, który zdawałeś 10 lat temu. Przypominasz sobie trzy a potem symulujesz kaszel, aby jak najszybciej móc się oddalić. Co więc robić? Jak żyć?

  1. Rozciągaj się

Wielu zawodników traktuje rozciąganie jak homeopatię. To po prostu wymysł jakiś znachorów i nie ma prawa działać. Traci się tylko cenny cza, podczas którego możnaby zrobić masę. Nic bardziej mylnego. Rozciąganie jest bardzo skuteczne i pozwala utrzymać ciało w dobrej kondycji, nawet wtedy gdy nie możemy normalnie trenować. W zdrowym ciele zdrowy duch. Łatwiej jest wrócić do pracy i na matę, gdy mimo wszystko człowiek się trochę porusza.

  1. Trening mózgu

Mózg też można, a właściwie trzeba trenować. Czy to oglądanie walka na YT (walk BJJ, nie kotów, wypadków, seriali, tylko walk najlepszych zawodników na świecie), czy rozwiązywanie sudoku, taki trening pozwoli w łatwiejszy sposób wrócić nam szybciej do pełnej formy. Oglądanie prelekcji z konferencji testerskich? Czemu nie. Jak nie teraz to kiedy?

  1. Back to basics

Powrót do podstaw. Nie ma lepszego pomysłu na spędzenie czasu jak powtórka absolutnych podstaw. Książka Adama Romana „Testowanie i jakość oprogramowania” może nie jest najlepszą lekturą do poduszki, ale skrypt ISTQB już tak. Przypomnienie sobie podstawowych sweepów i technik kończących jest jak najbardziej wskazane.

  1. Nakręcanie się na powrót

Ostatnie metoda. Wizualizacja tego, co się będzie działo po powrocie. O czym będziesz gadał z kumplami na treningu? Że znowu przytyłeś, pfu! Zrobiłeś masę? Że symulowałeś? Że znowu Cię żona z domu puścić nie chciała? A w pracy? Że projekt żyje i ma się dobrze, klient jest zadowolony, a Twoja obecność w cale nie jest niezbędna, tak jak się to PMowi wydawało. Że znowu bug na produkcji wyszedł o 2 w nocy, lub co gorsza, automat do kawy się zepsuł.

Czy stosowanie się do powyższych zasad pomoże? Z pewnością! Jestem tego przykładem. Najgorsze to nic nie robić. Wiem, że dobry serial nie jest zły, ale warto poświęcić trochę czasu na inne rzeczy. Wysyłek niewielki, a benefity ogromne. Osssss!

Projekt ławka

Jak to w każdej większej firmie zdarza się, że testerzy „siedzą na ławce”. Innymi słowy: projektu nie ma i póki co nie będzie. Co wówczas robić, gdy musimy siedzieć 8h w pracy bez konkretnych zadań? Możliwości jest klika:

Self learning:

Czyli to, co właściwie powinniśmy robić. Testowanie jest olbrzymim obszarem więc każdy powinien znaleźć tutaj coś dla siebie. Frontend, Backend, aplikacje mobilne, wydajność, bezpieczeństwo itp. Tematów można by mnożyć. Minusy? Ileż można!? Dzień, dwa, tydzień nauki bez przerwy? Każdy by oszalał. Ponadto czas upływa powoli…bardzo powoli. Gdy praca do wykonania jest konkretna, wówczas czas zdaje się płynąć szybciej.

Granie w gry:

Opcja niebezpieczna, lecz kusząca. Szefowie raczej nie będą patrzeć przechylnym okiem, ale z drugiej strony, gdy w biurze jest 100 osób, to wówczas nie tak łatwo wyizolować tę, która nic nie robi. Ponadto gry rozwijają. Artykułów na ten temat też jest dość sporo. Zresztą, nie trzeba grać w gry na konsoli, zawsze są planszówki.

Work from home:

Ma sens. Skoro I tak się uczę, to czemu nie uczyć się z domu, gdzie rozpraszaczy jest dużo mniej. Warunki bardziej sprzyjają a i baza wiedzy bywa większa. Pytanie, czy ten czas pracy z domu na pewno poświęcimy rzeczywistej nauce.

Retrospektywa i porządki:

Skończyliśmy projekt, nie mamy nowego, ale może jednak warto podsumować nasze dotychczasowe dokonania. Zawsze znajdzie się obszar, w którym coś nam nie poszło, gdzie moglibyśmy cos poprawić. Warto więc zrobić porządek zarówno w dokumentacji jak i na biurku.

Oglądać YouTube:

Ilość filmów z kotami wystarczy nam na długie miesiące siedzenia na ławce. Może i nic się nie nauczymy, za to będziemy szczęśliwi. Zresztą, nie tylko koty są w internetach.

Załatwiać rzeczy prywatne:

Trzeba zrobić przelew, opłacić rachunki, zamówić prezenty, pojechać przypilnować malarza itp. Brzmi znajomo? To codzienność tych, którzy nie mają projektu. Niech kwestią naszego sumienia pozostanie jak bardzo będziemy chcieli wykorzystywać firmę do własnych potrzeb.

Zmienić pracę:

Nic tak nie demotywuje jak monotonia. Gdy czas spędzony na ławce jest zbyt długi, czasem warto po prostu poszukać innej pracy. Krok drastyczny, ale czasami konieczny.

Różowy projekt

Zygfryd z niedowierzaniem patrzył na ekran. Ilość odcieni koloru różowego raniła zarówno jego oczy jak i dumę. Dlaczego ja? Dlaczego takie rzeczy zawsze muszą mnie spotykać? –  Niestety pytanie pozostało bez odpowiedzi. Jeszcze tydzień temu myślał, że znalazł niebo na ziemi. Dostał projekt, w którym trzeba było zrobić i przetestować porównywarkę zdjęć kobiet w bikini. Projekt życia. Gołe laski na ekranach monitorów w pracy i to za pozwoleniem szefa! Lepszego projektu nie mógł sobie wyobrazić.

Niestety błogostan nie trwał długo. Raptem dwa dni po rozpoczęciu projektu, przyszedł PM i oznajmił, że jedna osoba będzie oddelegowana do innego projektu. Sklep internetowy kucyków Ponny i i innych zabawek w kolorze różowym. Tak. Klient, a właściwie klientka, wymarzyła sobie sklep, gdzie można kupić zabawki tylko w kolorze różowym. Gdy Zigi pierwszy raz zobaczył kobietę, odpowiedzialną za ‘’różowy projekt’’, omal nie spadł z krzesła. Kobieta 40-50 lat, tleniona blondi z mózgiem wielkości ameby. Pieniądze ma od mężusia, a nadmiar wolnego czasu wykorzystuje na solaria i masaże. Co spowodowało, że zachciało jej się własnego biznesu? Tego prawdopodobnie nigdy się nie dowie. A dlaczego to właśnie on musiał trafić do różowego piekła? Bo kamień bije nożyczki…

Zygfryd z niesmakiem oglądał skaczące po ekranie kucyki i jednorożce. Strony dosłownie nie dało się oglądać, jednak klienta była zachwycona dotychczasowym efektem. Abstrahująca od wyglądu, ile błędów może być w sklepie internetowym? Tyle co zawsze. Pod tym względem projekt nie odbiegał od innych. Największy problem Zigi miał z kolorami. Jako typowy mężczyzna rozróżniał trzy: fajny, brzydki i ch*jowy. Tymczasem na samej stronie głównej, według specyfikacji (jeśli można tak nazwać opowiastkę Blondi, jak strona ma wyglądać), miał trzy odcienie różowego. Zrezygnowany odłożył testy UI na bok i jeszcze raz sprawdził działanie koszyka.  Kategoria: dodatki…uprzęże dla kucyków…kolor….biały…dodaj do koszyka….cena się zgadza, ilość też. Idź dalej…kategoria jednorożce…ku*wa!…dodaj jednorożca…NIE!! Tak dalej być nie może.

Zygfryd zrezygnowany czym prędzej zamknął laptopa i wyszedł z pokoju. Poziom testosteronu znacznie spadł dużo poniżej normalnego poziomu. Musiał odreagować. Czym prędzej poszedł na drugą stronę biura, gdzie stało nowiutkie PS4 PRO. Musiał przyznać, że tym razem szef miał gest. Nowa konsolka i zestaw gier naprawdę świetnie działała jako przerywnik w pracy. Zigi rozsiadł się w fotelu i włączył konsolę. Pół godzinki gry w Street Fightera później mógł spokojnie wracać do swoich obowiązków. Nieśpiesznie i w dobrym humorze ruszył do swojego biurka.

W tym momencie jego telefon odezwał się dźwiękiem, informującym, że SMS dotarł na pokład. Zigi odblokował ekran i zaczął czytać. Dobry humor jak szybko przyszedł tak szybko odszedł. Krótka wiadomość tekstowa informowała go, że za godzinkę przyjedzie Blondi z nowym pomysłem na sklep. Tym razem będzie to muzyczka, która będzie towarzyszyć klientom będącym na stronie. Już na samą myśl o potencjalnych piosenkach, które będzie musiał przesłuchać, Zigi poczuł, że robi mu się niedobrze. Czym prędzej zawrócił i biegiem udał się z powrotem do ukochanej konsoli. Tym razem pół godzinki grania będzie zdecydowanie za mało.

Programistyczna Wieża Babel

Developerzy w danym projekcie programują w jednym języku programowania. Java, C#, .NET, nie ma znaczenia – zawsze jest to jeden konkretny język. Dzięki temu są oni ekspertami w swojej dziedzinie znając wszystkie tajniki, jak również za i przeciw danego rozwiązania.

Ile języków programowania powinien znać tester? Żadnego, bo przecież jest testerem manualnym? A jak jest automatykiem? To góra jeden. Selenium + Java. Bo teraz wszystko jest pisane w Selenium. BDD + find.by i wystarczy. Czy aby na pewno?

Czasami jest tak, że testerzy przypisani do projektu muszą sobie radzić sami z całym projektem, niezależnie od tego jakie są technologie i potrzeby, bo akurat ławka testerska jest pusta. I tak: Mamy Web aplikacje, no to piszemy Selenium+ C#, bo przecież Framework już jest i nie będziemy wymyślać koła na nowo. Web serwisy? POSTMAN/SOAPUI nie ma znaczenia, i tak będziesz pisać w Java Scripcie. Klient chce aplikacje mobilną? Developerzy zabierają się za Xamarina, więc nie masz wyboru. Musisz użyć Calabasha, a w jakim języku pisze się w Calabashu? Rubym. Do tego jeszcze na początku projektu, kiedy wydawało się, że klepania kodu w ogóle nie będzie, programik do generowania linków pisałeś w Pythonie. Potem dla klienta developerzy piszą cały backed od nowa. No to w czym piszemy testy? REST assured – czyli w Javie.  Razem daje nam to pięć różnych języków programowania. Jednak tester to cwana i pojęta bestia.

Soft skills – hit czy kit?

Czy w branży IT ważne są umiejętności miękkie? Czy dobry programista, bez umiejętności komunikacji będzie postrzegany jako gorszy i zarabiać mniej? Opinii na ten temat jest tyle, ile odpowiadających. Moim zdaniem umiejętności miękkie są równie ważne co umiejętności twarde.

Zdarzało Wam się rozmawiać z kimś na jakiś temat, po czym po 15 minutach wymiany zdań okazuje się, właściwie mówicie o dwóch różnych rzeczach? A co z kontaktami z programistami? W jednym z projektów, gdy po kolejnym wypuszczeniu softu, po raz n –ty ten sam błąd był widoczny pewien tester lubił mówić:” Kur*a ten debil znowu nie naprawił tego buga, co za osioł. Mówiłem mu że to i to nie działa, co za zjeb!” – po czym pisał maila eskalacyjnego dodając do wątku PMa, i inne osoby decyzyjne. Efekt? Żaden. Powstał dodatkowy konflikt, w który zaangażowani musieli zostać liderzy i menadżerowie z obu stron. Przykład ten pokazuje wyraźny brak umiejętności miękkich. Komunikacji – brak. Brak też było jakiejkolwiek inicjatywy zrozumienia, dlaczego problem występuje. Zero empatii, pomysłu na rozwiązanie problemu.

Po drugiej stronie mogę przytoczyć sytuacje z innego projektu, gdy developer dziękował za znalezienie błędu! Był to dla mnie szok, ponieważ nigdy wcześniej się z czymś takim nie spotkałem. Z drugiej strony po zakończeniu projektu programiści udzielili kiedyś feedbacku, na temat zespołu testerskiego. Był od dość cierpki, ale bardzo merytoryczny i oparty na faktach. Można było zareagować na niego w dwojaki sposób: Stwierdzić, że nie mają racji, nie znają się na naszej pracy, kazać im się odwalić i strzelić focha, po czym dać równie ostrą informację zwrotną, niezależnie od tego, czy byłaby ona prawdziwa. Innym sposobem, który zresztą został wybrany, było przeanalizowanie tego, co zostało powiedziane. Bez emocji, oczerniania, wszystko na spokojnie. Przeanalizowaliśmy fakty, zrobiliśmy szybkie 5-why i wyciągnęliśmy wnioski. Od razu wprowadziliśmy pewne akcje w życie, dzięki czemu nasza praca stała się prostsza i lepiej widoczna. Powstała też checklista, w której umieściliśmy wskazówki, co i jak testować i na co zwracać uwagę, bazując na naszym doświadczeniu i znając „buggy zone” w projekcie. Mała pomoc dla przyszłych testerów. Efekt: wszyscy zadowoleni. W końcu jeśli mamy się rozwijać, musimy wiedzieć co robimy źle. Pochlebstwa w żaden sposób nie wpłyną na nasz rozwój i poprawienie jakości pracy. Jest to najczęstsza bolączka juniorów, którzy boją się mówić źle o kolegach z zespołu i strasznie oburzają się na negatywny feedback na temat ich pracy.

W komunikacji codziennej umiejętności miękkie są niemalże konieczne. Problem, który można by rozwiązać w 5 minut, ciągnie się godzinami na Skype, ponieważ jedna i druga strona stara się udowodnić, że ma rację. Zero próby zrozumienia, za to wzajemne przeszkadzanie i wykrzykiwanie ciągnące się w nieskończoność.

Oczywiście poza komunikacją mamy jeszcze inicjatywę, elastyczność, umiejętność pracy w grupie, kreatywność itp. Ale to pojęcia na osobny wpis.