Software.Developer's.Journal .06-2014.pdf

(28919 KB) Pobierz
Software Solutions Center
we Wrocławiu
AKCJA
Specjalisto IT! Przeprowadź się do Wrocławia
by budować swoją karierę razem z nami i odbierz…
10.000PLN
Więcej informacji na:
www.pl.capgemini-sdm.com/akcja-relokacja
Capgemini Software Solutions Center
ul. Strzegomska 42b, 53-611 Wrocław
SPIS TREŚCI
4
Testowanie eksploracyjne
– cudowny lek czy zwykłe
placebo?
Adam Roman
32
40
Polacy zwycięzcami drugiej edycji
konkursu Marathon24!
Asseco Poland
Branża IT cierpi niestety na uleganie swoistym „modom”: agile,
Scrum, BDD, TDD, ATDD... To pojęcia, które łączy jedna rzecz:
pojawiły się nagle, zrobiły błyskawiczną karierę i zostały
natychmiast zaadaptowane przez środowisko informatyków.
W sobotę i niedzielę, 29 i 30 listopada 2014 r., w Pomorskim
Parku Naukowo-Technologicznym Gdynia odbył się Wielki
Finał drugiej edycji konkursu Marathon24. Najlepsi okazali się
Polacy.
16
Code::Dive – relacja z konferencji
programistycznej
Nokia
Web Workers
5 listopada we Wrocławskim Centrum Kongresowym Przy
Hali Stulecia odbyła się pierwsza edycja „polskiego święta
programistów” Code::Dive „Beyond the cutting edge”. Tego
dnia stolica Dolnego Śląska zmieniła się w istny bastion IT, a
to za sprawą ponad 1000 programistów, którzy przybyli do
Wrocławia wysłuchać prelekcji sław świata programowania.
JavaScript to język, który został stworzony przy
założeniu, iż nie należy wprowadzać w nim wielowątkowości.
Przez długi czas sprytni programiści radzili sobie z brakiem tej
technologii korzystając z funkcji setTimeout(), setInterval(),
obiektu XMLHttpRequest oraz zdarzeń. W ten sposób
naśladowali asynchroniczność i współbieżność.
Damian Chodorek
20
Wizualizacja struktury intonacyjnej
wypowiedzeń dla celów analizy
i syntezy mowy (na materiale
języka rosyjskiego, niemieckiego i
polskiego)
Juliusz Skorek
44
Efektywne wykorzystanie źródeł
danych w aplikacjach .NET
Niniejsza praca łączy z sobą skrajne dyscypliny naukowe Z
jednej strony językoznawstwo – teorię języka – z drugiej
informatykę – jej matematyczną część. Główna ideą spinającą
te zagadnienia jest komunikacja językowa i jej jednostki. Celem
głównym w prowadzonych badań było zbadanie intonacji języka
i stworzenie teorii, która opisywałaby teorię komunikacji
językowe i w konsekwencji pomogłaby w konstrukcji ogólnej
teorii języka.
Jako programista często spotykam się ze stwierdzeniem, że
technologia Microsoft .NET Framework jest środowiskiem
zamkniętym, przeznaczonym do współpracy z jedynie
produktami sygnowanymi logiem Microsoft. Prawda jest
jednak nieco inna. Dominująca pozycja jaką bez wątpienia od
wielu lat utrzymuje marka, pozwoliła jej na stworzenie lub
lobbowanie standardów, które zostały zaimplementowane w
innych komercyjnych rozwiązaniach software’owych. To daje
szansę bezproblemową współpracę między nimi.
Wyższa Szkoła Informatyki i
Zarządzania z siedzibą w Rzeszowie
W ostatnim czasie idea wolnego oprogramowania,
po latach niedoceniania, nareszcie przeżywa swój rozkwit i
staje się przyczyną wielkiej, społecznej rewolucji. Oficjalnie
o open source mówi się od roku 1998, w którym to
Eric Raymond oraz Bruce Perens założyli Open Source
Initiative (www.macopedia.co). Warto przyjrzeć się bliżej
oprogramowaniu opartemu na licencjach open source i
wyjaśnić kilka funkcjonujących wokół niego stereotypów.
30
Przełamując mity o open source
Agata Piśniak
48
JESTEŚ BIEGŁY W PROGRAMOWANIU
W OPROGRAMOWANIU OPEN
SOURCE? MASZ SZANSĘ NA
ATRAKCYJNĄ PRACĘ
Kamila Harasik – Smolińska
Oprogramowanie open source stopniowo podbija polski
rynek. Wielu jego użytkowników uważa, że jest to świetna
alternatywa dla oprogramowania komercyjnego, którą z
powodzeniem można stosować na własny użytek. Stosunkowo
nowym trendem jest zainteresowanie sektora komercyjnego
tego typu rozwiązaniem.
Software Developer’s Journal
jest wydawany przez
NPRACA Sp. z o.o.
Redakcja:
sdjpl@sdjournal.pl
Adres korespondencyjny:
NPRACA Spółka z o.o.
ul. 3 Maja 46, 72-200 Nowogard, Polska
Oddział w Warszawie:
ul. Postępu 17 D, 02-676 Warszawa, Polska
www.sdjournal.pl
Facebook:
https://www.facebook.com/SoftwareDevelopersJournal
Redakcja dokłada wszelkich starań, by publikowane w piśmie informacje i
programy były poprawne, jednakże nie bierze odpowiedzialności za efekty
wykorzystania ich; nie gwarantuje także poprawnego działania programów
shareware, freeware i public domain.
Wszystkie znaki firmowe zawarte w piśmie są własności odpowiednich firm.
Zostały użyte wyłącznie w celach informacyjnych.
Osoby zainteresowane wspópracą prosimy o kontakt:
sdjpl@sdjournal.pl
Skład i łamanie / projekt okładki:
Digital Concept
www.digitalconcept.pl
admin@digitalconcept.pl
Testowanie eksploracyjne
cudowny lek czy zwykłe placebo?
Branża IT cierpi niestety na uleganie swoistym „modom”: agile,
Scrum, BDD, TDD, ATDD... To pojęcia, które łączy jedna rzecz:
pojawiły się nagle, zrobiły błyskawiczną karierę i zostały natychmiast
zaadaptowane przez środowisko informatyków.
Dowiesz się...
• czym jest testowanie eksploracyjne,
• jakie są wady i zalety testowania eksploracyjnego,
• jak stosować testowanie eksploracyjne w praktyce
Powinieneś wiedzieć...
• podstawowa wiedza z zakresu testowania oprogramo-
wania, procesów testowych i testowania opartego o ry-
zyko,
• podstawowa wiedza o metodykach zwinnych
B
ranża IT cierpi niestety na uleganie swoistym "mo-
dom":
agile, Scrum, BDD,TDD, ATDD...
To pojęcia, któ-
re łączy jedna rzecz: pojawiły się nagle, zrobiły bły-
skawiczną karierę i zostały natychmiast zaadaptowane przez
środowisko informatyków. Zaczęły być odmieniane przez
wszystkie możliwe przypadki w prasie branżowej, na konfe-
rencjach, spotkaniach grup zainteresowań, szkoleniach, blo-
gach tematycznych itd. W samej popularności nie ma oczy-
wiście absolutnie nic złego. Problem polega na czymś innym:
bardzo szybko okazuje się, że takie "modne" pojęcie rozu-
miane jest zupełnie inaczej przez różne osoby i tak napraw-
dę nie do końca wiadomo co naprawdę oznacza. Jego istota,
zasadniczy, oryginalny sens gubi się w mrokach różnorakich
interpretacji oraz informatycznej egzegezy tysięcy naśladow-
ców, epigonów, specjalistów i ekspertów.
Może też zdarzyć się sytuacja zupełnie odmienna – ma-
my wtedy do czynienia z czymś, co w metodologii badań hi-
storycznych nazywa się argumentum ex silentio (milczenie
Rysunek 1.
Graficzna interpretacja testowania eksploracyjnego
4
6/2014
TesTy eksploRacyjne
źródeł): wszyscy uważają technikę za oczywistą, łatwą do
wdrożenia, więc używają jej nie dokumentując ani sposobu
jej wykorzystania ani efektów, jakie przyniosła w ich projek-
tach. Dlatego z czasem następują coraz większe rozbieżności
w interpretacji tego, czym tak naprawdę metoda jest i jakie
korzyści może nam przynieść.
Nierzadko dana technika postrzegana jest tylko przez
pryzmat jakiejś jednej lub kilku jej cech charakterystycz-
nych, zapominając o całej (cennej!) reszcie. W efekcie bar-
dzo często możemy spotkać zespoły, którym wydaje się,
że są zwinne, choć każda zmiana z niewiadomych przyczyn
powoduje chaos i opóźnienia (no ale jak to? przecież je-
steśmy tacy edżajlowi?!); kierowników projektów, którzy
sądzą, że wdrożyli Scruma, bo wykorzystując cały arsenał
gróźb zmusili w końcu zespół do przeprowadzania cotygo-
dniowych spotkań (koniecznie na stojąco, bo tak przecież
mówi Święta Metodyka!); programistów, którzy proszeni
o stosowanie TDD piszą szybko byle jakie testy (toż to
zawracanie głowy!), aby móc w końcu skupić się na swojej
ulubionej czynności – prawdziwym kodowaniu.
Nie inaczej jest z testowaniem eksploracyjnym (TE). Poję-
cie to stało się ostatnimi czasy bardzo popularne i – jak in-
ne modne, rozpowszechnione w branży określenia – szybko
zaczęło "żyć własnym życiem". Efekt? Używanie wartościo-
wej techniki albo zupełnie nieświadomie, albo w niewłaściwy
sposób, tracąc szansę na uzyskanie wielu korzyści. Sprawę
komplikuje fakt, że w środowisku testerskim istnieje dosyć
gorący spór pomiędzy zwolennikami tzw. podejścia "proce-
sowego" (normy, planowanie, techniki projektowania testów
itp.) lansowanego np. przez ISTQB a "podejścia konteksto-
wego" (testowanie eksploracyjne), którego zwolennikami są
np. James Bach czy Cem Kaner. Spór ten może wywoływać u
mniej doświadczonych testerów pewną konfuzję: które po-
dejście jest lepsze? Która technika jest lepsza? I kto w ogóle
ma tu rację? W niniejszym artykule chciałbym ponownie od-
kryć właściwy, pierwotny sens TE i pokazać, że wspomniany
spór jest tak naprawdę pozorny – nie ma żadnej sprzeczno-
ści pomiędzy opisanymi wyżej metodami. Chciałbym także
spojrzeć krytycznie na pewne tezy o TE głoszone przez jego
zwolenników, z którymi nie do końca się zgadzam.
Zanim przejdziemy do konkretów, wypada wytłumaczyć
się ze stosowanej terminologii. Określenie "podejście ‘pro-
cesowe’" ujmuję w cudzysłów, ponieważ TE tak naprawdę
również jest podejściem opartym o jakiś proces. Chodzi
tu tylko o wygodne rozróżnienie pomiędzy procesem wg
ISTQB, kładącym nacisk na fazę planowania testów, a pro-
cesem TE, w którym testy nie są planowane z góry.
Układ artykułu jest następujący: najpierw zobaczymy na
czym tak naprawdę polega TE i jaka jest jego wartość nie tyl-
ko z punktu widzenia testera, ale także kierownika testów.
Spróbuję uzasadnić, że technika ta może być z powodze-
niem traktowana jako forma testowania zwinnego opartego
o ryzyko. To znaczy, że TE jest idealnym podejściem w pro-
jektach opartych np. o Scrum. Mając na uwadze fakt, że me-
todyki zwinne wciąż mają problem z zarządzaniem jakością,
wpisywanie się TE w strategię testowania opartego o ryzy-
ko jest nie do przecenienia. Potem pokażę, że niektóre tezy
podnoszone w środowisku propagatorów TE ("szkoła kon-
tekstowa"), np. że TE jest metodyką przeciwną do testowa-
nia planowanego albo że jest (lepszą) alternatywą klasyczne-
go podejścia do testowania, są co najmniej dyskusyjne bądź
metodologicznie błędne. Następnie odniosę się do sporu
Rysunek 2.
Porównanie podejścia "procesowego" i eksploracyjnego do testowania
www.sdjournal.pl
5
Zgłoś jeśli naruszono regulamin