Na podstawie wielu artykułów i poradników śmiało można stwierdzić, że spośród robiących obecnie karierę metodyk zwinnych najpolpularniejszą jest SCRUM. I teraz w momencie, kiedy uświadamiamy sobie, że faktycznie wszystkie działania podporządkowane są pewnej powtarzalności i regularności w każdym projekcie – szukamy schematu i przyczyn możliwego braku dobrej oragnizacji własnej pracy. I w takim momencie warto zapoznać się z metodyką SCRUM. Dla osób, które przeniosły się z pracy w metodykach tradycyjnych do pracy w metodyce SCRUM, pierwsze działania mogą wydawać się niczym innym jak chaosem.

Agile zaskakuje takimi aspektami jak: bliska wspólpraca w zespole (programiści, architekci, testerzy, osoby ‘biznesowe’), regularne pojawianie się nowych funkcjonalności, bezpośredni sposób komunikacji, wycofanie specyfikacji wymagań w formie masy kartek, częsta zmiana wymagań, ale z umiarem który określa niezmienny budżet.

Kiedy na stronie spoon.net gdzie udostępniane są zwirtualizowane aplikacje opublikowano informacje że Microsoft nakazał usunięcie IE z listy udostępnianych aplikacji rozpoczęły się poszukiwania alternatywy.
I takowa istnieje: Cameyo. Dzięki tej aplikacji można tworzyć zwirtualizowane programy, odpalać je bez instalacji – cośby jak portable i całkowicie za darmo, a z aplikacji korzystam za pomocą uruchamianego odizolowanego Sandboxa.

Do pobrania tutaj. Informacja zachęcająca do testowania tutaj.
Przeglądarkę można zainstalować obok standardowego Firefoxa. Jeżeli chodzi o interfejs to dla użytkowników Google Chrome rewolucji nie ma, dla użytkowników wcześniejszych wersji Firefoxa faktycznie zmiana jest znacząca.  Interfejs jest dużo lżejszy i dodatkowo bardzo przyjemny przy współpracy z Aero. Choć poprzez publikację wersji beta Mozilla głównie prezentuje nowy interfejs to w przeprowadzanych benchmarkach przeglądarka bije na głowę wersje poprzednie.  Sam silnik wyświetlania stron nie jest jeszcze zapewne stabilny. Piszę tu o wersji beta, choć ukazały się już jakiś czas temu informacje nagłaśniające wersję Firefox 4.0 pre-alfa – trochę rozśmiesza taka informacja dostępna na poważanych portalach, które zachęcały do śmiałego pobierania i instalowania Firefoxa w tej wersji.

Przychodzi taki czas, czas testów cross-browser, i zaczyna się miło i przyjemnie: Firefox, Google Chrome, Opera i po wstępnym zadowoleniu zgodnością aplikacji pod wymienionymi przeglądarkami nadchodzi TEN czas – czas testów po IE (Internet Explorer). Ponieważ blog służy do obnoszenia się subiektywnymi opiniami, to już na wstępie nie omieszkam szydery z produktu Microsoftu. Jasna rzecz, że wykazałam maksimum dobrych chęci do przyjaźni z IE ale sprawdziło się iż dobrymi chęciami jest piekło wybrukowane a IE narzędziem szatana pozostanie. Mogę śmiało stwierdzić, że pewne różnice (błędne wyświetlanie) świadczą o tym, że IE jest albo mega dokładne i skrupulatne albo mega głupie (najbanalniejszy przykład – niedomknięty <div … firefox daje rade bez problemu, IE nie)
Dlaczego IE jest mimo wszystko popularny? Wpis z basha jest kwintesencją odpowiedzi

internet explorer jest jak chrześcijaństwo – swoją popularność zdobył dlatego, że jest preinstalowany na większości komputerów

Istnieje wiele dobrych powodów, aby rozpocząć automatyzacje testów. Jednak bez braku konsekwencji sytuacja wygląda nie do końca kolorowo: firma startuje z  automatyzacją testów do projektu z nieokiełznanym entuzjazmem, który jednak z dnia na dzień przy ścigających team projektowy deadlinach kończy się godzinami spędzonymi nad manualnym testowaniem.

Oto klasyczne błędy zarządzania podczas wdrażania automatyzacji:

„Automatyzacja testów jest odpowiedzią na wszystkie problemy. Mamy tak wiele testów do wykonania i tak mało czasu, dalej! automatyzujmy testy użytkowania. To rozwiąż nasze wszystkie problemy. „

Nie jest to jednak prawda. Implementacja/ projektowanie skryptów poprzez narzędzia do automatyzacji może trwać od 3 razy do 100 razy dłużej niż

Kiedy Jeremy Clarkson testuje nowego Forda Fieste w klasycznym Top Gearowym stylu, gdy pościg po centrum handlowym i desant plaży razem z marines staje się częścią zaplanowanego scenariusza testowego… mam tylko jedną myśl: jakie to musi być niebanalne uczucie mieć możliwość wykonania tak ekstremalnych testów. Skąd w ogóle takie pomysły? Odpowiedzi udziela sam Jeremy, ponieważ zarzucono mu że testy, które przeprowadza są mało praktycznie i właściwie bezsensowne, postanowił pokazać test praktyczny i test przydatny w codziennym życiu. Możesz dowiedzieć się jakim samochodem najlepiej wybrać się na zakupy, a jakim na jazdę ekstremalną po plaży :> Teraz każdy już wie, dzięki tym testom, chociażby to, że Corvetta zdecydowanie na jazdę po centrum handlowym się nie nadaje – wiedza życiowa i praktyczna.

Skąd w ogóle ten temat?

Eeeeh nie wygrałam :/ life is brutal… Ale różnice nie były wielkie pomiędzy wpisami… nie będę się rozwodzić jak to się mogło stać podzielę się tym, jakich chwytów użyłam… :] Facebook, lista znajomych z Gmail’a, lista kontaktów gg, link w profilu na forum wydziału… chyba tyle, o nie – jeszcze NK – link pod nowo dodanym zdjęciem (tu się chyba podłożyłam – za późno umieściłam link na NK – tak długo próbowałam zapomnieć o lansie na NK, że nie wykorzystałam darów jakie za sobą niesie posiadanie konta…) buahahah :> Na koniec tego wpisu dziękuję wszystkim, którzy kliknęli, którzy pomogli w reklamie (młodemu, pałlinie, sokowi :> …wszystkim) I gratuluje Ottawce :]

Morał testera: doświadczenie idące za tym wydarzeniem pozwoliło przetestować zaangażowanie znajomych w sprawę wielkiej wagi dla samego testera.

…obalono mit

Mit z artykułu George’a Wilsona “Agile testing fact and fiction”

Programiści i testerzy są jak oliwa i woda, nie da się ich połączyć

Pomiędzy programistami i testerami od zawsze istniały podziały typu „my i oni”, ale nie musi to być przyczyną kontrowersji. „Jest to zazwyczaj zdrowa relacja symbiotyczna, która – jeśli funkcjonuje prawidłowo – zapewnia współpracę korzystną dla obu stron, która daje w efekcie wyższą jakość produktu dostarczanego klientowi.”

wpis in progress … :]

Połączyć programistę z testerem

Czy można jasno określić różnice? Istnieje takie cóś jak dokumentacja, specyfikacja projektu – bez znajomości zapewne sporego dokumentu bywa że raportowany bug – to tak naprawdę ficzer, lub że nie raportowany jest bug bo tester czy programista myśli że to ficzer. Rzeczywiste błędy tzw. showstopper killer bugs – uniemożliwiają normalne korzystanie z systemu i są zwalczane szybko. Ponadto, myślę, że systemy śledzenia błędów takie jak Mantis web-based bugtracking system czy np Bugzilla uniemożliwiają w pełni poprawne zgłoszenie błędu.

OWASP (Open Web Application Security Project) to międzynarodowa organizacja działająca na rzecz poprawy bezpieczeństwa aplikacji internetowych. Skupia ona osoby zaangażowane w rozwój narzędzi, bibliotek czy też zbioru dobrych praktyk pomocnych w bezpiecznym tworzeniu oprogramowania.