Testowanie aplikacji [internetowych]

http://msdn.microsoft.com/en-us/library/ms182613(VS.80).aspx

Smoke testing is done by developers before the build is released or by testers before accepting a build for further testing. Microsoft claims[1] that next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.

In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.

In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a “shallow and wide” approach to the application. The tester “touches” all areas of the application without getting too deep, looking for answers to basic questions like, “Can I launch the test item at all?”, “Does it open to a window?”, “Do the buttons on the window do things?”. The purpose is to determine whether or not the application is so badly broken that testing functionality in a more detailed way is unnecessary. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself. This is sometimes referred to as “rattle” testing – as in “if I shake it does it rattle?”

http://www.junit.org/

Czy w firmie, w której pracujesz jest dział testerów? Jeżeli jesteś z Polski, to jest bardzo duże prawdopodobieństwo, że takiego działu nie masz. Co dziwniejsze jeszcze, że im większa i poważniejsza firma, tym mniejsze szanse na istnienie działu testerów! A to dziwne!

Poniżej prezentuję 5 najbardziej prawdopodobnych powodów, dla którego w firmie, w której pracujesz nie ma działu testerów, razem z komentarzem. Powody i uzasadnienia pochodzą w dużej mierze ze świetnego artykułu Joela Spolskyego (Top Five (Wrong) Reasons You Don’t Have Testers).

Więc zaczynamy.

1. Błedy w oprogramowaniu wynikają z lenistwa programistów.

“Zatrudnienie testerów w naszej firmie spowoduje, że programiści przestaną sami testować to co tworzą i w kodzie będzie więcej błędów” – Mogło by się wydawać… Błędy w oprogramowaniu (bugi) powstają w kodzie w związku z tym, że programista ich z jakiegoś powodu nie zauważył. Programista to też człowiek, a nie ma ludzi nieomylnych. Najczęściej wystarczy, aby druga osoba spojrzała na kod/produkt aby wyłapać większość błędów. Często zdarzają się sytuacje w których coś, działające na 100% u programisty nie działa u testera. Podczas konfrontacji okazuje się, że testerka podczas rejestracji w przykładowym systemie wybierała inną płeć niż programista co w efekcie implikowało różnice.

2. Moje oprogramowanie jest dostępne on-line. Mogę naprawiać błędy od ręki.

Mogłoby się wydawać… Prawdą jest, że wprowadzanie poprawek w systemach będących on-line jest z jednej strony nieco łatwiejsze niż w przypadku aplikacji desktopowych, jednak z drugiej jest znacznie trudniejsze, ponieważ działamy na żyjącym organizmie, w momencie kiedy wprowadzamy poprawki, użytkownicy korzystają z naszej aplikacji, używają naszego serwisu. Takie poprawki “na szybko”, najczęściej wykluczają przeprowadzenie testów regresywnych i bardzo często prowadzą do stworzenia kolejnych błędów. Błędy takie są widoczne od razu dla użytkowników, co zmniejsza ich satysfakcję i prowadzi do punktu następnego:

3. Użytkownicy przetestują mi oprogramowanie.

Nie powinno się tak nawet nikomu wydawać… Z takim podejściem nie wróżę sukcesu. Jeżeli coś użytkownikowi przestaje działać – idzie do konkurencji – to w najlepszym przypadku. W gorszym, idzie do konkurencji i zaczyna rozpowiadać o naszej firmie brzydkie rzeczy, co powoduje zmniejszenie przypływu nowych użytkowników, bądź utratę większej ilości aktualnych. W jeszcze gorszym przypadku, użytkownik podczas korzystania z naszej aplikacji traci swoje dane (jakąś swoją pracę), lub jego dane osobowe zostają np. przypadkowo wysłane mailem do 100000 innych użytkowników co prowadzi do sprawy w sądzie i innych kłopotów – a tego nie chcemy. Specjalnym przypadkiem są tutaj beta-użytkownicy – jednak jest to specjalnie wyselekcjonowana grupa użytkowników, którzy świadomie podejmują pracę na niefinalnej wersji oprogramowania.

4. Nikt z odpowiednimi kwalifikacjami nie chce pracować jako tester.

Nie jest to do końca prawdą. Z jednej strony trudno jest o dobrego testera. Z drugiej jednak testy funkcjonalne nie wymagają wysokich kwalifikacji. Najlepszymi testerami funkcjonalności, są ludzie nie związani bezpośrednio z IT, warto pomyśleć o zatrudnieniu studentów kierunków humanistycznych, którzy są w stanie znaleźć bardzo dużo problemów w tworzonym przez nas oprogramowaniu.

Jest prawdą natomiast, że trudno o pracowników potrafiących uruchamiać i przeprowadzać testy jednostkowe oraz inne testy wymagające znajomości specjalistycznego oprogramowania, platform i języków skryptowych. Z drugiej strony jednak sam znam kilku dobrych testerów, którzy bardzo chętnie będą kontynuować swoją karierę jako testerzy.

Ostatni z powodów, najpopularniejszy i najbardziej bzdurny:

5. Nie stać mnie na testerów.

I jednocześnie najłatwiejszy do obalenia. Testerami w firmie mogą być praktykanci, studenci odbywający praktyki oraz np. uczniowie szkół ponadpodstawowych za niewielkie pieniądze. Ile testerzy by nie kosztowali – zawsze są tańsi niż programiści (mówimy o testerach funkcjonalności, a nie np. specjalistów od przeprowadzania testów użyteczności). Nie opłaca się, aby programiści poświęcali swój czas na testowanie, skoro w tym czasie mogą poprawiać błędy, oraz rozwijać oprogramowanie.

W początkowym stadium “zespołu testowego” warto prowadzić rekrutację, mimo kompletu testerów, i szybko wymieniać tych, którzy nie nadają się na testerów. Poza tym średnio tester pracuje na swoim stanowisku ok. 3-4 miesięcy, więc rotacja w takim zespole jest spora.

Nie warto jednak proponować swoim przyszłym programistom stanowisko testera na czas “wdrożenia”, ponieważ mogą znudzić się zadaniami testowymi i możemy stracić dobrego programistę.

Dodatkową opcją są agencje pracy tymczasowej i pracy dla młodzieży (np. http://www.timework.pl), gdzie za niewielkie pieniądze można zatrudnić młodych ludzi do prostych prac.

O testach korytarzowych. Jak, z kim, po co?

I nie chodzi o polityczny test korytarzowy: http://rafalziemkiewicz.salon24.pl/7857,index.html