Skip to content

Michal Dobrzycki

Praca z lokatorami w konsoli przeglądarki

Sporo osób, szczególnie podczas początków nauki automatyzacji ma problem z tym jak weryfikować poprawność XPath i CSS Selectors.

Pełna dokumentacja dla nich jest w linkach poniżej:

W tym artykule pokażę jak możemy bawić się lokatorami bezpośrednio w konsoli przeglądarki. Rozwiązanie jest o tyle fajne, że wymienione rozwiązania działają w każdej przeglądarce (nawet w IE11, serio).

Read More →

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 →