#1: S艂贸w kilka o testach bia艂o i czarnoskrzynkowych.
Kilka dni temu Anna Kalemba i Adam Lochno, moi znajomi, opublikowali bardzo ciekawy artyku艂 traktuj膮cy o testach bia艂oskrzynkowych oraz czarnoskrzynkowych. Materia艂 dost臋pny jest w j臋zyku angielskim, ale nie powinni艣cie mie膰 problem贸w ze zrozumieniem. Przy okazji po膰wiczycie troszk臋 bran偶owe s艂ownictwo 馃槈
#2: Sprostowanie poprzedniego wydania QA Weekly
Dwa tygodnie temu opublikowa艂em materia艂, w kt贸rym wspomnia艂em, 偶e programi艣ci nie powinni testowa膰. By艂 to du偶y skr贸t my艣lowy, na kt贸ry zwr贸ci艂a mi uwag臋 Urszula, jedna z aktywnych czytelniczek newslettera. Bardzo Ci dzi臋kuj臋 za ten feedback!
Tymczasem chcia艂bym sprostowa膰 - chodzi艂o mi oczywi艣cie o zapewnianie jako艣ci. Programista powinien testowa膰 sw贸j produkt (g艂贸wnie kod) - poprzez code review, testy integracyjne oraz jednostkowe, analiz臋 regresji, kwestii biznesowych, logiki czy zgodno艣ci z wymaganiami. I to my, jako Quality Assurance, powinni艣my zadba膰 o to, aby by艂o to wykonywane. Pami臋tajmy jednak, 偶e nie powinni艣my ogranicza膰 si臋 wy艂膮cznie do tego - rola QA jest na tyle wa偶na, 偶e potrafimy zapewni膰 jako艣膰 na szerokim obszarze, nie tylko skupiaj膮c si臋 na jednej funkcjonalno艣ci. Zadbajmy o odpowiedni poziom wydajno艣ci, bezpiecze艅stwa, przeanalizujmy logik臋 biznesow膮 i sprawd藕my czy wszystko ma r臋ce i nogi, wykonuj膮c dodatkowo testy funkcjonalne. Przypilnujmy, by programi艣ci zweryfikowali sw贸j produkt, jednocze艣nie waliduj膮c go z wymaganiami klienta oraz dokumentacj膮. Nad jako艣ci膮 powinien czuwa膰 ca艂y zesp贸艂, ale to QA zazwyczaj ma najwi臋ksze do艣wiadczenie w zapewnianiu jako艣ci (nierzadko r贸wnie偶 w testowaniu).
Urszula zwr贸ci艂a mi r贸wnie偶 uwag臋 na inny wpis - o tym jak zg艂osi膰 defekt. Pisa艂em tam o standardach (opis, wersja, platforma, priorytet, wa偶no艣膰, warunki wst臋pne, kroki do odtworzenia, aktualny i oczekiwany stan, uwagi). Czytelniczka s艂usznie zauwa偶y艂a, 偶e zabrak艂o tu ID, tytu艂, data zg艂oszenia czy autora. S膮 to pola, kt贸re zazwyczaj s膮 automatycznie generowane podczas zg艂aszania defektu w bug-trackerze. Jednak nie zawsze mamy do niego dost臋p, zw艂aszcza gdy przygotowujemy si臋 do pierwszej pracy. Zapomnia艂em o tych kwestiach, prostuj臋 zatem, bowiem warto je uwzgl臋dni膰, np. tworz膮c bug report w Excelu.
I na koniec - podane kwoty (koszty naprawy defektu) w poprzednim QA Weekly (w sekcji "jak przekona膰 klienta") by艂y przyk艂adowe. Tu r贸wnie偶 zabrak艂o tego s艂owa - nie zawsze i nie w ka偶dym projekcie koszty b臋d膮 takie same. Inne b臋d膮 w przypadku drobnej strony informacyjnej z jednym formularzem kontaktowym, inne w bankach, a jeszcze inne w social mediach.
Dzi臋kuj臋 Ci bardzo, Urszulo, za cenny feedback (oraz mi艂e s艂owa, kt贸re tam pad艂y). Jak wida膰 - cz艂owiek uczy si臋 najlepiej na w艂asnych b艂臋dach, a nikt nie jest nieomylny 馃檪
Zach臋cam r贸wnie偶 innych do dzielenia si臋 swoimi wra偶eniami - wystarczy odpisa膰 na dowolnego otrzymanego ode mnie maila.
|