Skip to content

Tester Roadmap 2020

Kilka słów na temat technicznych umiejętności, które w moim osobistym odczuciu będą przydatne w nadchodzącym roku (i najbliższych kolejnych latach również). Zwizualizowane w postaci ładnej (mam nadzieję) mapy w SVG (skaluje się, bo jest wektorowa!) poniżej. Na githubie jest/będzie angielska wersja posta.

Podstawy

HTML/CSS

Aktualnie aplikacje webowe przejmują wszystkie możliwe platformy. Android, Desktop, iOS, Linux. Powstanie electrona przyśpieszyło ten proces. Visual Studio Code, Etcher, Torrent, Slack – to wszystko aplikacje webowe przeniesione na desktopa. Zrozumienie jak działa HTML/XML + CSS pozwoli Wam na szybsze, lepsze i głębsze testowanie aplikacji.

Powinniście wiedzieć czym jest Shadow DOM, jak strukturyzowany jest HTML 5 i w jaki sposób możemy dzieli strukturyzuje się DOM (pomaga to w pisaniu lokatorów do testów).

CSS/XPATH

Pisanie selektorów to żmudna praca (choć da się je skopiować prosto z przeglądarki). Wiedza czy lepiej w konkretnym przypadku użyć CSS Selectora czy Xpath często eliminuje późniejsze problemy projektowe. Dobrze napisany CSS Selector / Xpath powinien być odporny na najczęstsze zmiany w strukturze DOM. Polecam tutaj dwa ćwiczenia:

JavaScript

Najczęściej używany język programowania we wszechświecie (a już na pewno w aplikacjach webowych). Zrozumienie co dzieje się w DOMie, umiejętności debugowania, pisanie własnych skryptów w konsoli to umiejętności, które pobieżnie warto opanować. I co to do cholery jest ten „this” 😉 Kilka darmowych kursów poniżej.

Cenioną umiejętnością jest zrozumienie jak działa React i Angular (aktualnie najczęściej wybierana bibiloteka JS i najczęściej wybierany framework JS w dużych firmach). Zrozumienie czym są komponenty, jak działa ich odświeżanie w DOMie pozwala ustrukturyzować framework testowy w taki sposób, który zapobiega późniejszym problemom (polecam poczytać o Loadable Component jeżeli używacie Selenium).

Do tego zrozumienie działania Reduxa i umiejętność bawienia się storem prosto z przeglądarki (dzięki Redux DevTools) pozwala nam zahaczyć o początki pentestów.

Umiejętności ogólne

Dziś większość projektów prowadzonych jest w jakimś systemie kontroli wersji. Git jest chyba najbardziej popularnym, a na pewno takim systemem którego warto się uczyć. Dlaczego? Bo zrozumienie działania gita to taka gimnastyka umysłu, która pozwoli Ci zrozumieć wszystkie inne centralne systemu typu SVN czy TFVC.

Protokół HTTP. W dobie architektury klient-serwer (albo mikroserwisów) zrozumienie tego jak komunikują się moduły to obowiązek każdej osoby, która bierze się za testowanie i/lub developerkę. Pozwala to też zrozumieć co dzieje się po stronie klienta, a co po stronie serwera – co znacznie przyśpiesza raportowanie błędów i ich usuwanie.

Terminal nie gryzie. Klikanie jest dość wolne, a nam zależy na maksymalizowaniu czasu w którym myślimy i minimalizowaniu czasu w którym coś robimy. Tylko w ten sposób możemy konkurować z tańszymi „risorsami” zza wielkiej wody. Więcej o tym w części poświęconej bash.

Algorytmy i struktury danych. Temat bardzo ważny (choć pewnie nie wszyscy się ze mną zgodzą) jeżeli tworzymy framework testowy, który w dodatku musi być później miesiącami (lub latami) utrzymywany.

Zostawię tutaj tylko link do posta na freecodecamp, który odeśle Was do odpowiednich materiałów jeżeli jesteście tym zainteresowani.

Tech Skills

Programowanie

C# i Java potraktuję jako jedno. Zrozumienie jednego z tych języków pozwoli Wam przeskoczyć na drugi jeżeli zajdzie taka potrzeba. Dlaczego akurat te dwa języki? Dlatego, że są statycznie typowane i kompilowalne. To pozwala Wam dość łatwo zrozumieć co dzieje się pod spodem.

Maven/Nuget – to repozytoria paczek gotowego kodu w Javie/C#. Zrozumienie tego jak to działa jest dość proste. Dodatkowo warto wiedziec jak samemu takie paczki tworzyć.

LinQ/Streams – czyli zaczątek programowania funkcyjnego w języku obiektowym. Użycie tych technologii pozwala nam zadawać pytania na obiektach (trochę jak SQL). Dzięki temu możemy przetwarzać kolekcje obiektów wyszukując interesujące nas elementy, które chcemy przetestować.

Reflection – przy pracy nad frameworkiem testowym (lub narzędziem typu Gherkin) raczej później niż prędzej trafimy na refleksje. Moment w którym zaczniemy zastanawiać się jakiego typu jest pole w klasie i jak się do niego dostać, to moment kiedy będziemy musieli tego użyć.

DevOps

DevOps – czyli w rozumieniu testera szybkie dostarczenie aplikacji i feedbacku na temat ostatnich zmian.

Czym różni się CI od CD? Jak często chcemy dostawać raporty z wynikami testów? Co dzieje się z kodem po merge’u do brancha development?

CI – umiejętność konfiguracji testów integracyjnych i pokrycia funkcji biznesowych to podstawa. W moim przypadku czesto musiałem tłumaczyć adminowi jak uruchomić i jak zebrać wyniki takich testów. Dodatkowo wiedza o testach jednostkowe i narzędziach do statycznej analizy kodu mogą się przydać (w końcu celujemy w bycie architektem testów).

CD – czym Continuous Deployment różni się od Continuous Integration to jedno z najczęstszych pytań na rozmowach kwalifikacyjnych. Znajomość procesu pozwoli zaplanować w odpowiednim miejscu testy E2E, testy UAT. W moim przypadku (ponownie) to QA jest odpowiedzialny za popchnięcie aplikacji ze środowiska developerskiego na testowe i dalej na UAT. Dobrze wiedzieć jak działa ten guzik w narzędziu i co dzieje się pod spodem.

Skrypty

Do tego, żeby całe CI/CD działało szybko. Do tego żeby zautomatyzować sobie zrobienie git checkout development | git pull w siedmiu podkatalogach z siedmioma projektami potrzebujemy czegoś więcej niż zwykłej linii komend. Z pomocą przychodzą trzy rozwiązania: bash, Powershell i Python.

Bash – język skryptowy kojarzony mylnie tylko z linuxem. Dzięki git bash (który instaluje się razem z klientem git), możemy z niego korzystać również na Windowsie. Przykład: dodanie tej linijki do pliku .bashrc powoduje że w git bash zadziała nam komenda „brall”, która wydrukuje wszystkie podkatalogi dla katalogu w którym została uruchomiona + aktualny branch gita dla tych katalogów.

1
alias brall='for dir in $(ls -d */);do (cd $dir && echo "$dir [$(git rev-parse --abbrev-ref HEAD)]") ; done'

Powershell – język skryptowy dla Windowsa 10. Jeżeli pracujecie na stacku firmy Microsoft, to często musicie korzystać z takiej automatyzacji. Przykładem skryptu, który napisałem w Powershellu jest pobieranie z Azure Devops artefaktów ostatniego poprawnego builda aplikacji desktopowej + instalowanie aplikacji lokalnie na komputerze. Klikanie, rozpakowanie zipa zawsze trwało 10-15 minut (musiałem robić to codziennie). Skrypt spowodował, że mogłem w międzyczasie pójść zrobić sobie kawę.

Docker i konteneryzacja

Milion środowisk na jednym komputerze. Docker rozwiązuje nam problem różnych wersji bibilotek i frameworków, wersji języków programowania a nawet systemów operacyjnych. Dzięki znajomości dockera możemy lokalnie na naszym komputerze utworzyć całe środowisko testowe (tu jest link do repo z warsztatów o tej tematyce na konferencji Quality Excites 2019).

Testowanie API

Tutaj skoncentruję się na REST API i definicji Open API 3.0 (jako że GraphQL jeszcze nie jest standardem a SOAP już nie jest standardem).

90% aplikacji które są aktualnie tworzone są oparte na bezstanowej komunikacji HTTP (czyli architekturze REST) i mikroserwisach. Pozwala to na szybkie skalowanie w przypadku wykładniczo rosnącej ilości użytkowników. Według mnie świetnym toolem do testowania jest Postman. Pozwala nam czytelnie i przez sensowne GUI tworzyć testy, a następnie puszczać je dzięki aplikacji konsolowej newman. Wstęp do tworzenia frameworka w newmanie jest w kolejnym moim repozytorium (zakładam tam, że testy w Postmanie są już utworzone i zajmuję się ich uruchamianiem w różnych konfiguracjach).

Open Api 3.0 – kilka wiodących firm zdecydowało, że czas na wprowadzenie standardu tworzenia API i jego dokumentacji. Tak powstał OAS aktualnie w wersji 3. Narzędziami które wspierają tworzenie tej dokumentacji jest np. Swagger. Umiejętność przekonania programistów do trzymania się tej specki ułatwia życie w późniejszych etapach zarówno im jak i testerom.

SysAdmin, czyli linux Twoim przyjacielem

Instalacja pakietów apt-get, ustawianie mysql, znajomość niezbędnych komend to raczej miły dodatek niż wymaganie. Niemniej pomaga skrócić czas spotkań, dyskusji i ustaleń z sysadminami, więc może warto trochę poświęcić czasu na dokształcenie się w tej dziedzinie.

Mobile Testing

Testowanie mobilek i desktopów (UWP/WPF). Wszystko jest możliwe dzięki Appium, dlatego znalazło się na samej górze. To narzędzie pozwala nam testować zarówno Androida, iOS jak i aplikacje desktopowe na Windowsie. Moim zdaniem to świetny punkt wejścia do testowania mobilek (uczycie się raz i testujecie wszystkie platformy).

Espresso – narzędzie do testowania stricte aplikacji Androida. Według wszelkich opinii z rynku jest dużo szybsze do Appium, dlatego wskazane w przypadku gdy wasza aplikacja nie ma odpowiednika na iOS.

XCTest – jak wyżej, tyle że dla iOS. Wskazane jeżeli nie interesuje Was Android.

Xamarin i WinAppDriver – wrzuciłem to tutaj, bo pomogło mi przygotować kiedyś projekt testowy dla aplikacji rozwijanej na Windowsa, iOS i Android. WinAppDriver jest następcą CodedUI (toola dołączanego do Visual Studio Enterprise), który jest zupełnie opensource. Xamarin jest dość prostym do nauczenia toolem, ale zostawiającym wiele do życzenia pod kątem wydajności i elastyczności 😉

Znajomość rozwiązań chmurowych

Wiekszość rozwiązań które powstają aktualnie to rozwiązania oparte o architekturę chmury. Azure i AWS to najwięksi dostawcy tych usług. Dobre zrozumienie jak działają podstawowe funkcjonalności chmury pozwoli nie tylko dobrać odpowiednie rozwiązanie pod kątem technicznym ale również pod kątem ekonomicznym. W chmurze można zrobić wszystko, na kilka różnych sposobów i kilka różnych kosztów. Dlatego zachęcam do przerobienia materiału przygotowującego do certyfikacji AZ-900 (Azure Fundamentals), a być może i zrobienia tego certyfikatu.

Nie znam odpowiednika tego certyfikatu dla AWS, ale na pewno istnieje. Jeżeli więc Wasza firma stawia na innego dostawcę, śmiało. Jak zrobicie pierwszy cert, drugi będzie tylko formalnością.

Testowanie

Na koniec doszliśmy wreszcie do testowania samego w sobie.

Testy jednostkowe do frameworka testującego aplikację? A i owszem, zdarzyło mi się takowe pisać. Dodatkowo każdy framework oparty na selenium będzie musiał korzystać z biblioteki, która pozwoli nam przynajmniej na tworzenie asercji. NUnit dla C#, jUnit dla Javy, Jest dla JavaScriptu, to najpopularniejsze z narzędzi.

Ciężko tu nie wspomnieć o zdobywającym popularnośc Cypressie, który jest aktualnie jedynym potencjalnym kontrkandydatem dla Selenium (wreszcie dodali wsparcie więcej niż jednej przeglądarki :))

Wartym uwagi jest też tool mabl, choć płatny to w zasadzie niewiele jak na rozwiązanie oparte na sztucznej inteligencji.

Wisienką na torcie niech będzie organizacja uruchamiania testów za pomocą Selenium Grid (lub Zalenium czy Selenoida) oraz prezentacja wyników testów (a jeszcze lepiej możliwość ich uruchamiania w dowolnej chwili jednym kliknięciem) dla biznesu. W drugim przypadku z pomocą może przyjść ciekawe narzędzie od UncleBoba Fitnesse, które pozwala nam stworzyć „Wikipedię z testami i ich wynikami”.


Zapraszam do komentarzy i propozycji zmian roadmapy najlepiej via Twitter albo przez githuba (jak tylko przetłumaczę tekst na angielski)

PicoCTF 2019 – reverse engineering aplikacji Androida – część 3, ostatnia.

Zadanie 3 – zmiana, podpisanie i ponowna instalacjia aplikacji

Po dekompilacji pliku three.apk widzimy kod, który niezależnie od wyniku wywołuje metodę nope(), kawałek niżej widzimy też metodę yep()

return-object v0 zwróci nam napis „don’t wanna” i wydrukuje w aplikacji jako flagę, a my chcemy poznać wynik funkcji cilantro() z metody yep(). Zmieńmy zatem w linijce 25 wywołanie funkcji na inną.

Po zapisaniu zmian w aplikacji budujemy ją na nowo:

I instalujemy plik new_three.apk, żeby otrzymać błąd…

Problemem jest niepodpisana aplikacja .apk i to że mamy już taką aplikację zainstalowaną na emulatorze. Możemy poczytać o podpisywaniu aplikacji więcej w tym artykule, a ja w skrócie podam komendy które wygenerują nam klucz i podpiszą aplikację do użytku lokalnego.

Generowanie klucza (ważne jest to, żeby ścieżka do jdk/bin Javy była w zmiennej systemowej PATH, u mnie to C:\Program Files\Java\jdk1.8.0_211\bin).

1
keytool -genkey -v -keystore mycustomname.keystore -alias mycustom_alias -keyalg RSA -keysize 2048 -validity 10000

Musimy po tym przejść przez krótki generator i podać trochę danych (nie muszą być prawdziwe. Ci idioci tego nie sprawdzają 😉 )

Następnie podpisujemy aplikację gdy mamy już wygenerowany klucz:

1
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mycustomname.keystore new_three.apk mycustom_alias

Powinniśmy otrzymać na koniec komunikat, że się udało:

Teraz możemy uruchomić naszą zmienioną aplikację na emulatorze i zobaczyć czy zadziałało.

Uwaga: zanim zainstalujemy aplikację na nowo musimy odinstalować starą ręcznie z emulatora androida (drag and drop do kosza z nią wystarczy). Chwilę po tym możemy cieszyć się flagą wpisując dowolne hasło:

Flaga zadania three.apk

Zadanie 4 – ostatnie

Zaczynamy od dekompilacji aplikacji four.apk

Metoda getFlag() jest dość skomplikowana i można by pokusić się o odwrócenie funkcji wyliczającej hasło, ale oczywiście breakpoint załatwi nam sprawę szybciej. Ustawiamy go na linię 228 pliku FlagstaffHill.smali i odpalamy aplikację

Widzimy hasło: alphabetsoup, którego nawet nie musieliśmy wyliczać odwracając skomplikowany kod. Ale… co stanie się po wpisaniu go do aplikacji? Kod zwróci obiekt v5, czyli napis „call it” w miejsce flagi. Hmmm, wygląda na to że programiści zapomnieli wywołać odpowiednią funkcję w tym miejscu…

Po analizie pliku widzimy w linii 16 tego pliku ciekawą metodę statyczną (to jest import z biblioteki zewnętrznej) cardamom().

1
.method public static native cardamom(Ljava/lang/String;)Ljava/lang/String;

Wywołajmy zatem poprawną metodę zmieniając liniję 234 . Nasz kod po zmianie powinien wyglądać tak:

Kompilujemy, podpisujemy i uruchamiamy aplikację (tak jak powyżej w zadaniu 3) wpisując tym razem poprawne hasło „alphabetsoup” i… flaga jest nasza.

W ten sposób rozwiązaliśmy wszystkie zadania picoCTF2019 dotyczące reverse engineeringu aplikacji na Androida.

Podsumowanie zadań

  1. Każdą aplikację androida możemy zdekompilować, przerobić i uruchomić zdalnie. Trzymanie jakichkolwiek sekretów (nawet zaszyfrowanych) w aplikacji udostępnionej klientowi jest nieskuteczne.
  2. Prawie każdy kod da się odwrócić (wyjątkiem są algorytmy hashujące)
  3. A nawet jak się nie da, to wystarczy ustawić w dobrym miejscu breakpoint.
  4. A jeżeli nie da się ustawić breakpointa, to zawsze można zmienić kod (np. if (userEntry == passwordHash) na if (userEntry != passwordHash)
  5. Nie ma idealnych zabezpieczeń dla aplikacji Androida, są tylko takie których złamanie zajmie więcej czasu (będzie bardziej kosztowne) niż zakup licencji…

Tym optymistycznym akcentem, zachęcam do udziału w kolejnych edycjach picoCTF wszystkich testerów i programistów. Spojrzenie z tej drugiej strony na aplikacje jest niezwykle rozwojowe 🙂

picoCTF 2019 – reverse engineering aplikacji androida – one.apk i two.apk

Czas pokazać rozwiązania kolejnych zadań umieszczonych pod adresem: http://scvconsultants.com/apk/

Jeżeli chcesz ustawić środowisko, zajrzyj proszę o poprzedniego wpisu na moim blogu.

Zadanie 1 – hardkodowane stringi w aplikacji

Zaczynamy od dekompilacji aplikacji one.apk przy pomocy narzędzia apktool:

Dekompilacja aplikacji one.apk

Po czym otwieramy katalog one za pomocą IntelliJ:

Ustawiamy nasz katalog /one/smali przy pomocy komendy „Mark directory as -> Sources Root„.

MainActivity.smali z podkatalogu /one/smali/com.hellocmu.picoctf/ to klasa która odpalana jest jako punkt uruchomienia aplikacji Androida. Zajrzyjmy więc do niej:

MainActivity.smali

Po krótkiej analizie możemy zauważyć metodę buttonClick(), która wywołuję metodę getFlag z pliku FlagstaffHill.smali (ostatnia linijka kodu na screenshocie poniżej).

Przechodzimy więc do metody getFlag() w pliku FlagstaffHill.smali

Widzimy w nim stałą: const v0 – ta stała jest porównywana metodą if-eqz v1, :cond_0 z tym co zwraca metoda getString() z pola p1 (można się domyśleć, że jest to tekst który wpisze użytkownik w aplikacji).

(ctrl + shift + f w IntelliJ pokaże nam na co ta stała wskazuje). Po wyszukaniu widzimy obiecujące id stringa, o name=password:

Wyszukiwanie adresu 0x7f0b002f

Jeżeli hasła są równe (w linijce kodu if-eqz), to wywołana jest metoda fenugreek() z biblioteki libhellojni.so, która jak możemy podejrzewać ujawni nam flagę (wnioskuję to z poprzedniego zadania).

Zajrzyjmy jeszcze do pliku /res/values/strings.xml i zobaczmy jakie stałe zostały tam umieszczone:

strings.xml i zapisane stałe

To wygląda na hasło, które jest porównywane z tym co użytkownik wpisze. Zainstalujmy więc w naszym emulatorze aplikację one.apk i sprawdźmy co się stanie po wpisaniu hasła:

Et voila, flaga jest nasza.

Podsumowanie problemu

Trzymanie haseł jako czysty tekst w: bazach danych, aplikacjach androidowych, aplikacjach desktopowych to poważny błąd, który powinien zostać niezwłocznie zgłoszony i usunięty przez zespół developerów.

Każda stała w kodzie klienta jest domyślnie pakowana do binarki i musimy o tym pamiętać. Wyciągnięcie jej nie jest żadnych problemem.

Takie rzeczy można wyłapać na etapie Code Review i niezwłocznie zgłaszać sekrety w kodzie jako błędy P1 (o ile zależy nam na bezpieczeństwie).

Zadanie 2 – dobry breakpoint podstawą sukcesu

Zaczynamy od dekompilacji: apktool d two.apk i otwieramy folder przy pomocy IntelliJ ustawiając katalog smali Mark Directory as -> Sources Root. Jest to niezbędne do działania breakpointów.

Tym razem zobaczymy w metodzie getFlag() pliku FlagstaffHill.smali kilka czarownic z uniwersum Świata Dysku (sir Terrego Pratchetta). I dość skomplikowany na pierwszy rzut oka kod, który przerzuca metodami aput-object imiona czarownic 🙂 Przypominam Dalvik Opcodes gdyby ktoś chciał przeanalizować kod maszynowy na własną rękę.

Zdekompilowana klasa FlagstaffHill.smali z aplikacji two.apk

Tutaj mamy dwa rozwiąznia. Jedno, to prześledzić kod i go zrozumieć (lvl hard). Drugie – to ustawić dobrze breakpoint podczas wykonywania kodu aplikacji. Ja jestem leniwy, więc ustawiam breakpoint na linii 169:

if-eqz to porównanie, które w przypadku poprawnego sprawdzenia wywoła nam metodę sesame(string userEntry) z biblioteki libhellojni.so

Uruchomienie aplikacji i debugowanie

Po zainstalowaniu i uruchomieniu two.apk na emulatorze, IntelliJ + smali debugger (w poprzednim artykule opisałem jak to zrobić) pozwoli nam się podłączyć do procesu i ustawiać breakpointy.

IntelliJ Menu Run -> Attach Debugger to Android Process:

I widzimy uruchomiony proces w emulatorze Androida. Wybieramy com.hellocmu.picocft i klikamy ok:

Podłączanie debuggera do procesu odpalonego w emulatorze Androida

Przełączamy się do aplikacji (na emulatorze) i wpisujemy cokolwiek po czym klikamy myszką na guzik „HELLO I AM A BUTTON”. Breakpoint powinien nam zadziałać i zatrzymać się w linii 169:

Po przejściu do IntelliJ widzimy zmienną password, z którą porównywane jest to co wpisał użytkownik:

Breakpoint złapany! 🙂

Sprawdźmy czy to hasło faktycznie jest poprawne:

Flaga zadania two.apk

Podsumowanie problemu

Jakkolwiek skomplikowana byłaby metoda wyliczania zmiennej password, na niewiele się to zda, jeżeli w kodzie w pewnym momencie mamy warunek logiczny: if (userEntry==password). Wystarczy w odpowiednim momencie zatrzymać aplikację, odczytać z pamięci zmienną z którą porównujemy co wpisał użytkownik i nasze zabezpieczenie zostało złamane.

picoCTF 2019 – podstawy reverse engineeringu dla Androida

Jakiś czas temu wystartowaliśmy w picoCTF 2019 i jako drużyna AvaHack zajęliśmy 381 miejsce na 23 tysiące zgłoszonych drużyn. Zawody CTF (capture the flag) polegają na grzebaniu w aplikacjach i wyszukiwaniu ich słabych punktów. W skrócie chodzi o to, żeby zdobyć flagę (którą jest ciąg znaków), które organizatorzy sprytnie pochowali w różnych miejscach aplikacji (używając do tego różnych sposobów ukrywania lub szyfrowania tychże flag).

Chcę się podzielić rozwiązaniami zadań z działu reverse engineering aplikacji Androida. Jest to o tyle ważne dla testerów, że właśnie te zawody uświadomiły mi na jakie problemy (bezpieczeństwa i jakości) możemy natrafić podczas testowania aplikacji mobilnych.

Wszystkie 5 zadań (aplikacji androida) można pobrać stąd: http://scvconsultants.com/apk/.

Read More →

Reverse engineering – czyli TestingCup 2019 i Mr. Buggy pod lupą

Trochę czasu minęło od zawodów TestingCup, w których brałem udział (z bardzo przeciętnym skutkiem). Regulamin zabawy mówi wyraźnie, że nie można używać debuggerów ani dekompilatorów. Co innego po zawodach, w celach czysto edukacyjnych. Pełne informacje przesłałem do organizatora (Radka Smilgina), który odpowiedział w mailu, że następny Mr. Buggy będzie lepiej zabezpieczony. Liczę na to, że wszystkie potencjalne wektory ataku zostaną załatane.

Read More →

Rozpoznawanie „Agile Bullshit”

Dziś wszystkie projekty w IT „by default” są Agile. Na rozmowach kwalifikacyjnych padają pytania o metodologię Agile i czym to się różni od Scruma. Nawet na późniejszych rozmowach technicznych, dużo osób twierdzi że ich projekty są Agile-ish.

Aby pośmiać się z problemów (zwłaszcza w dużych firmach) związanych z wprowadzaniem na siłę zwinności stworzyliśmy fanpage na Facebooku – Watergile. To jest taki trochę śmiech przez łzy, który traktujemy jako wentyl negatywnych emocji związanych z codziennymi przygodami w projektach.

W związku z tym postanowiłem podejść do tematu trochę poważniej i ruszyć z dyskusją na temat „Agile Bullshit”. Chciałem stworzyć pytania, których odpowiedzi wykryją ściemę. Efektem tego była dyskusja na reddicie i zebranie w jednym miejscu kilku pytań, które możesz zadać na rozmowie kwalifikacyjnej. Oryginalna dyskusja w języku angielskim znajduje się tu.

Oto 10 wybranych przeze mnie pytań:

  1. Jak testujecie swój kod? Złe odpowiedzi: „Mamy niezależną organizację testującą”, „Testerzy są odpowiedzialni za testowanie”, „Testuje klient”. Dobra odpowiedź: „Mamy CI i każdy merge do developa odpala testy jednostkowe, integracyjne a po deployu lecą testy E2E pisane przez zespół.
  2. Jaki poziom automatyzacji macie w swoim developmencie, testowaniu, zapewnieniu bezpieczeństwa i deploymencie. Złe odpowiedzi: „Mamy CI ale deployment robimy ręcznie”, „Krzysiek odpowiada za deployment”, „Testy automatyczne? Mamy unit testy i developerzy są zobowiązani je uruchamiać przed pull requestem.” Dobra odpowiedź: „Programiści pushują zmiany na branch, wystawiają pull request który przechodzi code review a reszta dzieje się automatycznie sama.”
  3. Kim są wasi użytkownicy i jak wygląda interakcja z nimi? Złe odpowiedzi: „PM/BA kontaktują się z użytkownikami. Staramy się odseparować programistów od użytkownika, żeby nie tworzyć zamieszania.” Dobra odpowiedź: „Mamy Jirę/Confluenca (lub inne podobne narzędzia), w której użytkownicy mogą zgłaszać pomysły na usprawnienia, rozmawiać z nami. Po każdym sprincie robimy demo i słuchamy feedbacku”.
  4. Ilu programistów/testerów jest częścią organizacji odpowiadającej za budżet i kamienie milowe programu? Złe odpowiedzi: „Nie wiemy”, „Zero”, „To zależy jak zdefiniujesz programistę/testera”. Dobra odpowiedź: „Team lead ma wpływ na budżet i zasoby projektowe, QA lead ma wpływ na zasoby projektowe. Obaj mogą zwiększyć np. ilość wirtualnych maszyn lub ludzi przed releasem na proda”.
  5. Jakie macie metryki dla developmentu i deploymentu? Jak często używacie ich i w jaki sposób do wykrywania problemów. Jak często rozmawiacie o metrykach z menadżerami?
  6. Czego nauczyliście się podczas ostatnich trzech sprintów i co z tym zrobiliście? Złe odpowiedzi: „A czym jest sprint?”, „Czekamy na zatwierdzenie naszych propozycji przez menadżerów”. Dobra odpowiedź: „Na retrospektywie wskazaliśmy problem X,Y,Z. Udało nam się poprawić Z, bo X i Y czeka na akceptację budżetu.”
  7. Kim są użytkownicy którym dostarczacie działający program na koniec sprintu? Czy możemy z nimi rozmawiać? Złe odpowiedzi: „Nie przekazujemy działającej aplikacji bezpośrednim użytkownikom”, „Od rozmów z użytkownikami są analitycy”. Dobra odpowiedź: „Robimy tą aplikację dla firmy X. Jej pracownicy i zarazem użytkownicy końcowi aplikacji na koniec każdego sprintu są obecni na demo i zbieramy od nich feedback”.
  8. Ile czasu zajmuje, od momentu zgłoszenia zapotrzebowania, aby nowa funkcjonalność została zaimplementowana w aplikacji? Zła odpowiedź: „Mamy pipeline na takie usprawnienia, przechodzi to przez ręce analityka i product ownera, którzy po uporaniu się z tym wrzucają to do backlogu. Reszta już zależy, czasem nigdy nie implementujemy, a czasem jeszcze w aktualnym sprincie”.
  9. Czy feedback od użytkownika zostaje przekuty na konkretne zadania przypisane programistom? Czy zespół może samodzielnie wprowadzać zmiany do aplikacji na bazie feedbacku użytkownika? Zła odpowiedź: „Od wprowadzania zmian jest PO i tylko on może ruszyć backlog.”. 
  10. Czy cały ekosystem projektu jest prowadzony w metodologii Agile? (np. zwinne wytwarzanie oprogramowania, po którym następuje liniowy, biurokratyczny deployment z formalnym zatwierdzaniem przez zewnętrzny zespół testerski to porażka).

Antifragile – jak i czym konkurować w wytwarzaniu oprogramowania?

Po słowach krytyki i wsparcia dotyczących mojego poprzedniego postu postanowiłem opisać spojrzenie od strony klienta / stakeholderów dotyczących jakości oprogramowania.

Odpowiedź na pytanie postawione w tytule postu w przypadku zadania go osobie związanej z QA będzie jednoznaczna – należy konkurować jakością.

Odpowiedź zarządu firmy nie będzie już jednoznaczna. Zanim zaczniemy projekt firma musi go wygrać. Projekty w uproszczeniu wygrywa się według kryterium najlepszej oferty. Co składa się na ocenę najlepszej oferty?

Read More →

Zagrożenia sztucznej inteligencji według developerów – czyli ankieta Stack Oveflow 2018

„By the far the greatest danger of Artificial Intelligence is that people conclude too early that they understand it.” – Elizer Yudkowsky

„If you’re not concerned about AI safety, you should be. Vastly more risk than North Korea.” – Elon Musk

Wyniki rocznej ankiety StackOverflow są dostępne tutaj: https://insights.stackoverflow.com/survey/2018

Najbardziej zaciekawiła mnie część ankiety dotycząca etyki w zawodzie programisty i zagrożeń sztuczne inteligencji. Podsumowując:

  • Zaledwie ułamek deweloperów powiedział, że byliby w stanie napisać nieetyczny kod lub że nie muszą brać pod uwagę etycznych implikacji swojego kodu, ale poza tym, respondenci widzą dużą etyczną szarą strefę. Deweloperzy nie są pewni w jaki sposób zaraportowaliby etyczne problemy, i mają różne zdanie na temat tego kto ostatecznie odpowiada za nieetyczny kod.
  • Większość deweloperów zgadza się co do pozytywnych aspektów możliwości jakie oferuje sztuczna inteligencja, nie zgadzając się jednocześnie co do zagrożeń jakie AI ze sobą niesie.

Read More →

Kilka rzeczy, o których żałuję że nie powiedziano mi, gdy zmieniałem branżę na IT.

Do napisania tego posta natchnął mnie wpis na blogu Kuby Łopuszańskiego pt. Kilka rzeczy, o których żałuję, że nie powiedziano mi, gdy byłem młody

Mniej więcej 2,5 roku temu podjąłem decyzję o nauczeniu się programowania i przejściu do branży IT. Wcześniej przez ~8 lat zajmowałem się projektami w budownictwie i instalacjach sanitarnych. Przeszedłem drogę od inżyniera budowy przez konsultanta po PMa. Dziś po trochę ponad dwóch latach świadczenia usług w IT postanowiłem spisać rzeczy, które chciałbym żeby ktoś mi powiedział (lub móc powiedzieć sobie) na początku drogi związanej z przebranżowieniem.

Read More →