Teopgo

Tytu oryginau: How Google Tests Software
Tumaczenie: Julia Szajkowska

ISBN: 978-83-246-8656-8
Authorized translation from the English language edition, entitled:
HOW GOOGLE TESTS SOFTWARE; ISBN 0321803027; by James A. Whittaker;
and Jason Arbon; and Jeff Carollo; published by Pearson Education, Inc,
publishing as Addison Wesley.
Copyright 2012 Pearson Education, Inc.
All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from Pearson Education, Inc.Polish language edition published by HELION S.A.
Copyright 2014.
Wszelkie prawa zastrzeone. Nieautoryzowane rozpowszechnianie caoci lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metod kserograficzn,
fotograficzn, a take kopiowanie ksiki na noniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki wystpujce w tekcie s zastrzeonymi znakami firmowymi bd towarowymi ich
wacicieli.
Autor oraz Wydawnictwo HELION dooyli wszelkich stara, by zawarte w tej ksice informacje byy
kompletne i rzetelne. Nie bierze jednak adnej odpowiedzialnoci ani za ich wykorzystanie, ani za
zwizane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION
nie ponosi rwnie adnej odpowiedzialnoci za ewentualne szkody wynike z wykorzystania informacji
zawartych w ksice.
Wydawnictwo HELION
ul. Kociuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (ksigarnia internetowa, katalog ksiek)
Drogi Czytelniku!
Jeeli chcesz oceni t ksik, zajrzyj pod adres
http://helion.pl/user/opinie/teopgo
Moesz tam wpisa swoje uwagi, spostrzeenia, recenzj.
Printed in Poland.
Kup ksik
Pole ksik
Oce ksik
Ksigarnia internetowa
Lubi to! Nasza spoeczno
Spis treci
Przedmowa Alberto Savoi 11
Przedmowa Patricka Copelanda 15
Wstp 21
O autorach 27
Rozdzia 1. Wprowadzenie do procedur testowania oprogramowania
stosowanych przez firm Google 29
Jako testy 35
Podzia rl 36
Struktura organizacyjna 39
Od raczkowania, przez chd, do biegu 41
Rodzaje testw 43
Rozdzia 2. Inynier do spraw testowania oprogramowania 47
Z ycia inyniera do spraw testowania oprogramowania 50
Praca nad kodem i testy 50
Kim waciwie jest ITO? 56
Wczesny etap projektowania 57
Struktura w zespole 59
Dokumentacja projektu 60
Interfejsy i protokoy 63
Planowanie automatyzacji 64
Testowalno 65
System pracy inyniera do spraw testowania oprogramowania przykad 69
Wykonanie testu 79
Definicje rozmiarw testw 80
Wykorzystanie testw w infrastrukturze dzielonej 83
Korzyci z rnych rodzajw testw 84
Wymagania stawiane czasom wykonywania testw 88
Certyfikowany w testach 95
Wywiad z twrcami programu Certyfikowany w testach 97
Rozmowa kwalifikacyjna z inynierem do spraw testowania oprogramowania 104
Wywiad z programist narzdzi Tedem Mao 112
Rozmowa z twrc aplikacji WebDriver Simonem Stewartem 114
Kup ksik Pole ksik
8 Testuj oprogramowanie jak Google. Metody automatyzacji
Rozdzia 3. Inynier testujcy 119
Testowanie z uwzgldnieniem potrzeb uytkownika 119
Z ycia inyniera testujcego 120
Planowanie testw 124
Ryzyko 144
ycie przypadku testowego 158
ycie bdu 164
Zatrudnianie inynierw testujcych 179
Kierowanie testami w Google 187
Testowanie w trybie utrzymania 193
Badanie jakoci za pomoc botw. Dowiadczenie 197
BITE. Nowe dowiadczenie 211
Analizy testowe Google Test Analytics 223
Prowadzenie darmowych testw 230
Testerzy zewntrzni 235
Rozmowa z inynierem testujcym Lindsay Webster 237
Rozmowa z inynierem testujcym pracujcym
przy serwisie YouTube Apple Chow 244
Rozdzia 4. Kierownik zespow inynierskich 251
Z ycia kierownika zespow inynierskich 251
Zdobywanie pracownikw i pomysw 254
Wpyw 256
Rozmowa z KZI usugi Gmail Ankitem Meht 258
Rozmowa z KZI zespou Android Hungiem Dangiem 265
Rozmowa z KZI projektu Chrome Joelem Hynoskim 270
Dyrektor testw 276
Rozmowa z dyrektorem testw w projektach Search i Geo Sheltonem Marem 277
Rozmowa z dyrektorem zespou inynierii narzdziowej Ashishem Kumarem 281
Rozmowa z dyrektorem testw w Google India Sujayem Sahnim 286
Rozmowa z kierownikiem testw Bradem Greenem 291
Rozmowa z Jamesem Whittakerem 294
Rozdzia 5. Jak poprawi testowanie w Google 303
Powane niedocignicia systemu pracy w Google 303
Przyszo inynierw do spraw testowania oprogramowania 306
Przyszo inynierw testujcych 308
Przyszo kierownikw i dyrektorw zespow testujcych 309
Przyszo infrastruktury testujcej 309
Wnioski 311
Kup ksik Pole ksik
Spis treci 9
Dodatek A Plan testowania systemu operacyjnego Chrome 313
Przegld tematw 313
Ocena ryzyka 315
Testy podstawowe w kolejnych wersjach kompilacji 315
Dzienne testy ostatniej dobrej wersji 316
Testy wersji przeznaczonej do wprowadzenia na rynek 316
Testy rczne kontra automatyczne 317
Dbao o jako programici kontra testerzy 317
Kanay dystrybucji 317
Udzia uytkownikw 317
Repozytoria przypadkw testowych 318
Panel testowania 318
Wirtualizacja 318
Wyniki 319
Praca w penym obcieniu, testy dugotrwae i stabilizacja 319
Szkielet wykonawczy (Autotest) 319
Partnerzy OEM 319
Laboratorium sprztowe 320
Automatyzacja w strukturach E2E 320
Testowanie menedera AppManager 320
Testy w przegldarce 321
Sprzt 322
Harmonogram dziaa 322
Osoby odpowiedzialne za prowadzenie testw i obszary ich dziaania 324
Powizane dokumenty 324
Dodatek B Wycieczki testowe dla Chrome 325
Wyprawa do sklepu 325
Wyprawa studenta 326
Sugerowane obszary prowadzenia bada 327
Rozmowa midzynarodowa 327
Bieg na orientacj 328
Do biaego rana 329
Rzemielnik 329
Narzdzia w Chrome 330
Kiepska okolica 330
Nieciekawe dzielnice przegldarki Chrome 330
Kup ksik Pole ksik
Ustawienia wasne 331
Sposoby modyfikowania przegldarki Chrome 331
Dodatek C Wpisy z bloga dotyczce narzdzi i kodowania 333
BITE kilka stron na temat bdw i nadmiarowej pracy 333
Wypucie boty QualityBots 336
RPF szkielet funkcji nagrywania i odtwarzania Record Playback Framework 338
Google Test Analytics teraz w wersji otwartej 341
Szczegowo 341
Szybko 341
Wymowno 342
Warto praktyczna 342
Skorowidz 347
Kup ksik Pole ksik
ROZDZIA 1
Wprowadzenie do procedur testowania
oprogramowania stosowanych
przez firm Google
James Whittaker
Jedno pytanie sysz czciej ni jakiekolwiek inne. Niezalenie od tego,
w jakim przebywam kraju czy w jakiej bior udzia konferencji, ono zawsze pojawia
si prdzej czy pniej. Nawet Nooglerzy, jak nazywamy nowych pracownikw
korporacji Google, zadaj je, gdy tylko nabior nieco praktyki w pracy. Brzmi ono:
Jak Google testuje oprogramowanie?.
Nie potrafi powiedzie, ile razy ju na nie odpowiadaem ani nawet okreli,
ile rnych wersji odpowiedzi udzieliem, wiem natomiast, e sama odpowied
zmienia si im duej pracuj dla Google, tym wicej dowiaduj si o niuansach
technik kontrolowania jakoci programw. Od dawna ju cigaa mnie wizja napisania
takiej ksiki, wic gdy Alberto, ktry zazwyczaj odgraa si, e przerobi kad ksik
dotyczc testowania oprogramowania na pieluchy dla dorosych (twierdzc, e wtedy
istnienie takich podrcznikw byoby chocia troch uzasadnione), zaproponowa,
ebym usiad do pracy, nie miaem ju adnych wtpliwoci ta ksika musiaa
powsta.
A mimo to zwlekaem. Gwny problem polega na tym, e zupenie nie nadawaem
si na autora takiego podrcznika. Przede wszystkim w samym Google pracuje
wiele bardziej ni ja obeznanych z tym tematem osb, zatem chciaem, by mogy
pierwsze zmierzy si z tym zadaniem. Druga sprawa, ktra nie pozwalaa mi podj
si pisania z czystym sumieniem, to fakt, e jako kierownik grupy testujcej
Kup ksik Pole ksik
przegldark Chrome i system Chrome OS (ktre to stanowisko przej obecnie
jeden z moich byych podwadnych) miaem wgld jedynie w niewielki fragment
rozwiza testowych stosowanych w firmie Google. Czekao mnie jeszcze wiele nauki.
Testowanie oprogramowania w Google ley w gestii wikszego, kierowanego
centralnie dziau, tak zwanej grupy wydajnoci projektowej (ang. Engineering
Productivity Group). Grupa ta obejmuje programistw, zespoy testujce oraz
zespoy odpowiedzialne za prac nad kolejnymi wersjami oprogramowania, a do
obowizkw jej czonkw naley testowanie programu na wszystkich poziomach
od poprawnoci funkcjonowania poszczeglnych moduw do sprawdzenia
testw rozpoznawczych. Zespoy testujce dysponuj szerokim wachlarzem
narzdzi i infrastruktur pozwalajc testowa dziaanie wielu znanych z sieci
rozwiza: wyszukiwarki, wywietlania reklam, dodatkowych aplikacji, serwisu
YouTube i innych, ktre kojarzy si z mark Google. Google zdoao pokona
wiele trudnoci zwizanych z tempem pracy i skal dziaania, dziki czemu mimo
rozlegej infrastruktury cigle jestemy w stanie wprowadza nowe aplikacje
z werw waciw nowym firmom. Jak zauway w przedmowie Patrick Copeland,
swj sukces Google zawdzicza przede wszystkim zespoom testujcym.
Testowanie oprogramowania w Google ley w gestii wikszego, kierowanego
centralnie dziau, tak zwanej grupy wydajnoci projektowej.
Gdy w grudniu 2010 system operacyjny Chrome OS trafi wreszcie do odbiorcw,
a kierowanie zespoem przekazaem szczliwie jednemu ze swoich podwadnych,
mogem wic wreszcie powici nieco wicej uwagi pozostaym produktom
Google. Tak rozpocza si praca nad t ksik. Zanim jednak przystpiem do
pisania, postanowiem sprbowa swoich si bardziej kameralnie, na blogu
1
, we
wpisie How Google Tests Software
2
reszta to ju historia. Sze miesicy
pniej ksika bya gotowa. Teraz wiem, e nie powinienem by zwleka tak
dugo z przystpieniem do pracy. W cigu tamtych szeciu miesicy dowiedziaem
si wicej na temat procesw testowania w Google ni przez dwa lata pracy, a ksika
uzupenia materiay szkoleniowe dla Nooglerw.
To nie jedyna pozycja powicona testowaniu oprogramowania przez wielkie
firmy. Gdy pracowaem w Microsofcie, Alan Page, BJ Rollison i Ken Johnston
napisali How We Test Software at Microsoft
3
, ktrej wiksza cz bazowaa na
dowiadczeniach wasnych autorw. Microsoft wyznacza wtedy standardy jakoci
w dziedzinie testowania oprogramowania. Polityka tej firmy sprawia, e etap testw
zyska najwyszy priorytet w oczach najlepszych inynierw wiata. Testerzy pracujcy

1
http://googletesting.blogspot.com/2011/01/how-google-tests-software.html
2
Testuj oprogramowanie jak Google przyp. tum.
3
Jak testujemy oprogramowanie w Microsofcie przyp. tum.
Kup ksik Pole ksik
Wprowadzenie do procedur testowania oprogramowania stosowanych przez firm Google 31
wczeniej dla Microsoftu byli wrcz rozchwytywani przez innych pracodawcw,
a Roger Shrerman, pierwszy przeoony grupy testujcej w Microsofcie, ciga do
Redmont wszystkich, ktrzy przejawiali zdolnoci w tej dziedzinie. To byy zote
czasy testw oprogramowania.
Wtedy firma wydaa obszern dokumentacj caego procesu.
Nie trafiem do Microsoftu na tyle wczenie, by mc uczestniczy w przygotowaniu
tej publikacji, ale dostaem drug szans. Gdy trafiem do Google, testy nad produktami
zaczynay dopiero nabiera rozpdu. Grupa wydajnoci projektowej liczya wtedy
zaledwie kilkaset osb dla porwnania: w obecnych czasach liczba ta wzrosa
do 1200. Problemy, o ktrych Pat wspomina w przedmowie, wanie odchodziy
w niepami, a firma wchodzia w etap najbardziej dynamicznego rozwoju w swoich
dziejach. Blog powicony zagadnieniom testowania oprogramowania w Google
odwiedzay setki tysicy osb miesicznie, a GTAC
4
na stae wesza do kalendarza
imprez branowych. Niedugo po moim przejciu do Google Patrick dosta awans
i sta si bezporednim przeoonym przynajmniej kilkunastu innych szefw
projektw i kierownikw dziaw. Jeli szuka rde nowej fali zotego wieku
testowania oprogramowania, to z pewnoci mona zaliczy do nich Google.
Oznacza to, e procedury testowania stosowane w korporacji Google rwnie
zasuguj na obszern relacj. Cay kopot polega na tym, e nie potrafi takowych
zdawa. Jednoczenie Google synie ze stosowania prostego i bezporedniego podejcia
do prac nad oprogramowaniem, moe wic i ja powinienem przyj t polityk.
W ksice Testuj oprogramowanie jak Google znajdziesz odpowiedzi na
pytania dotyczce tego, co to znaczy by testerem w Google czy w jaki sposb
podchodzimy do zagadnie skali, zoonoci czy powszechnego uycia
przygotowywanych u nas programw. Znajdziesz tu informacje, ktrych prno
szuka gdzie indziej, ale jeli nie zaspokoj one Twojej ciekawoci, pamitaj,
e w sieci znajdziesz mnstwo innych. Wystarczy je wygoogla!
Jednak to nie koniec tej historii, a wydaje mi si, e warto przedstawi j ca.
W kadym razie ja wreszcie dojrzaem do jej przedstawienia. Metody testowania
oprogramowania w Google mog z czasem sta si pewnego rodzaju standardem
dla innych firm, gdy coraz wiksza liczba producentw rezygnuje z zamykania
swoich produktw na dyskach komputerw, odchodzc od tego modelu na rzecz
wolnoci, jak oferuje sie. Nie spodziewaj si zatem znale w tej ksice wielu
punktw stycznych z wydawnictwem sygnowanym przez Microsoft. Podobiestwa
ograniczaj si do liczby autorw w obu przypadkach za powstanie ksiki
odpowiaday trzy osoby oraz oglnej zbienoci tematw w kadej z tych
ksiek znajdziesz opis praktyk zwizanych z testowaniem oprogramowania,
stosowanych w wielkiej firmie. Poza tymi dwoma aspektami ksiki te rni si
we wszystkim.

4
GTAC, czyli Google Test Automation Conference (https://developers.google.com/google-test-
automation-conference/), to organizowana co roku konferencja powicona zagadnieniom
testowania oprogramowania.
Kup ksik Pole ksik
Metody testowania oprogramowania w Google mog z czasem sta si pewnego
rodzaju standardem dla innych firm, gdy coraz wiksza liczba producentw rezygnuje
z zamykania swoich produktw na dyskach komputerw, odchodzc od tego modelu
na rzecz wolnoci, jak oferuje sie.
Patrick Copeland w przedmowie przygotowanej do tej ksiki opisa, w jaki
sposb narodzia si metodologia stosowana dzi w Google. Oczywicie jej pocztki,
odpowiadajce pocztkom samej firmy, stay si zrbem dla metod uywanych dzi,
ktre w naturalny sposb wyksztaciy si na tej podstawie wraz z rozwijaniem si
samego Google. Naley mie wiadomo, e Google to tygiel umysw cisych,
miejsce spotkania ludzi, ktrzy szlify w fachu inynierskim zdobywali w wielu
innych firmach. Kultywowana w nim polityka innowacyjnoci sprawia, e techniki,
ktre nie sprawdziy si w innych przedsibiorstwach, byy przez pracownikw
Google odrzucane lub modyfikowane. Z czasem, gdy szeregi testerw w Google
zaczy si rozrasta, zaczto wprowadza nowe pomysy i wdraa nieznane
dotd procedury. Te z nich, ktre sprawdziy si w praktyce w Google, wrosy na
dobre w model testowy stosowany w firmie, a pozostae jako zbdny balast
odrzucono. Testerzy pracujcy dla Google z chci dadz szans kademu pomysowi,
ale bardzo szybko odrzucaj te z rozwiza, ktre nie sprawdzaj si w specyficznych
warunkach firmy.
Google to przedsibiorstwo, w ktrym ceni si innowacyjno i szybko
dziaania i ktre synie z tego, e udostpnia swoje oprogramowanie, gdy tylko
kod nadaje si do uycia (i jednoczenie kiedy na ewentualne skutki bdw
naraa si zaledwie garstk uytkownikw), a take ze zbierania opinii na temat
funkcji oprogramowania ju wraz z pierwszymi zainteresowanymi (co zwiksza
ich liczb i pozwala lepiej oceni moliwoci programu). Prowadzenie testw
w takich warunkach musi przebiega przede wszystkim sprawnie, zatem techniki
wymagajce wczeniejszego planowania czy staego nadzoru zwyczajnie si nie
sprawdz. Zdarza si, e testowanie odbywa si jednoczenie z pracami nad
oprogramowaniem, tak e czsto trudno jest okreli, w ktrym miejscu przebiega
granica midzy tymi dwoma dziedzinami. Z kolei w innych przypadkach testy s
cakowicie niezalene od etapu programowania, wic twrcy aplikacji nie maj
nawet wiadomoci, e ich produkt podlega badaniom.
Zdarza si, e testowanie odbywa si jednoczenie z pracami nad
oprogramowaniem, tak e czsto trudno jest okreli, w ktrym miejscu przebiega
granica midzy tymi dwoma dziedzinami. Z kolei w innych przypadkach testy s
cakowicie niezalene od etapu programowania, wic twrcy aplikacji nie maj
nawet wiadomoci, e ich produkt podlega badaniom.
Kup ksik Pole ksik
Rozwj Google spowodowa oczywicie spadek tempa prac nad oprogramowaniem,
ale w stopniu ledwie zauwaalnym. Jestemy w stanie przygotowa system operacyjny
w czasie niewiele duszym ni rok, nowe wersje aplikacji klienckich, takich jak
przegldarki Chrome, pojawiaj si raz na kilka tygodni, za aplikacje internetowe
aktualizujemy codziennie a wszystko mimo to, e referencje, ktrymi szczycilimy
si na pocztku dziaania, dawno straciy ju na aktualnoci. Wydaje si, e w przypadku
tego rodowiska znacznie atwiej przyjdzie wskaza cechy, jakich brak prowadzonym
w nim testom dogmatycznoci, sztywnych ram, wielkich nakadw pracy czy czasu
ni poda te, jakimi takie testy powinny si charakteryzowa. Mimo to wanie
je postaram si okreli. Jedno mog stwierdzi z ca pewnoci: testy nie mog
stanowi czynnika hamujcego wprowadzanie innowacyjnych rozwiza czy
spowalniajcego tempo prowadzenia prac nad aplikacj. W kadym razie adna
procedura testowania nie zdoa zrobi tego dwukrotnie.
Doskonae wyniki otrzymywane dziki metodom testowania stosowanym
w Google z pewnoci nie s skutkiem maej liczby oferowanych przez firm aplikacji.
Zakres i stopie zoonoci testw prowadzonych w Google s takie same jak
w kadej innej duej firmie. Niezalenie od tego, czy bdziemy mwi o systemach
operacyjnych przeznaczonych dla urzdze indywidualnych, aplikacjach
internetowych, programach dziaajcych na urzdzeniach mobilnych, czy aplikacjach
wielostanowiskowych, rozwizaniach dla biznesu lub sieci spoecznociowych,
z pewnoci znajdziemy wrd nich towary z oferty Google. Nasze aplikacje s
ogromne i niebywale zoone, korzystaj z nich miliony uytkownikw, bywaj
te celem atakw hakerskich. Spore partie kodu s powszechnie dostpne, wiele
fragmentw stanowi sched po stosowanych dawniej rozwizaniach, a sama firma
podlega czstym kontrolom. Oferowane przez nas programy dziaaj w setkach
krajw na caym wiecie, funkcjonujc oczywicie w rnych wersjach jzykowych,
a gdyby tego byo mao, zawsze mona wspomnie o podstawowym wymogu, jaki
stawiaj im uytkownicy aplikacje Google powinny da si atwo uywa i po
prostu dziaa. Z pewnoci nie mona powiedzie, by praca testera w Google
polegaa na rozwizywaniu banalnych problemw. Nasi testerzy przypuszczalnie
musz codziennie mierzy si z kadym wyzwaniem, jakie mona sobie wyobrazi.
To, czy Google wywizuje si dobrze ze stawianych sobie zada (pewnie nie),
to kwestia dyskusyjna, natomiast z pewnoci mona powiedzie jedno stosowane
w tej firmie podejcie do zagadnienia testowania oprogramowania rni si wyranie
od procedur, ktre miaem okazj obserwowa w innych przedsibiorstwach, a sdzc
po postpujcej nieubaganie tendencji do przenoszenia oprogramowania
z komputerw stacjonarnych do chmury, wydaje si, e praktyki stosowane w Google
wkrtce stan si powszechne w tej brany. Mamy nadziej, e wiedza zawarta
w tej ksice pozwoli rzuci nieco wiata na rozwizania stosowane w Google i tym
samym doprowadzi do konstruktywnej dyskusji w temacie dziaa, jakie naleaoby
podj, by twrcy oprogramowania mogli oferowa odbiorcom solidne, niezawodne
produkty, na ktrych ci mogliby polega. Oczywicie pomysy wdraane w Google
nie s pozbawione wad, ale chcielibymy przedstawi je wiatu i podda ocenie
Kup ksik Pole ksik
midzynarodowego rodowiska zajmujcego si zagadnieniem prowadzenia testw
oprogramowania. Dziki temu bdziemy mogli dalej rozwija je i poprawia.
Reguy testowania w Google wydaj si kci z nakazami logiki w caej firmie
pracuje mniej testerw ni w niejednym przedsibiorstwie nad poszczeglnymi
projektami. Google Test to nie liczce miliony oddziay piechoty. Jestemy niewielkim
i doborowym oddziaem specjalnym, ktrego podstaw dziaania stanowi starannie
przygotowana taktyka i zaawansowane technologicznie uzbrojenie tylko one
daj nam szans powodzenia w podejmowanych misjach. Brak potnego zaplecza
ludzi zmusza nas do konkretnego okrelania priorytetw. Larry Page uj to doskonale:
Niedostatek podnosi przejrzysto. Niewane, czy mwimy tu o funkcjach
oprogramowania, czy metodach prowadzenia testw dowiadczenie nauczyo
nas, e w obydwu przypadkach najlepsze wyniki uzyskuje si, stosujc wysoce
wydajne, ale nie nazbyt oporne metody dziaania. Rwnie dziki niedostatkom
nauczylimy si ceni zasoby wykorzystywane do prowadzenia testw. Dlatego te
doceniamy kadego pracownika i staramy si, by zatrudniani w Google byskotliwi
testerzy angaowali si caymi sob w prowadzone prace. Gdy kto pyta mnie o klucz
do sukcesu, odpowiadam zazwyczaj: Nie zatrudniaj zbyt wielu osb w dziale testw.
Gdy kto pyta mnie o klucz do sukcesu, odpowiadam zazwyczaj: Nie zatrudniaj
zbyt wielu osb w dziale testw.
Jak zatem firma taka jak Google radzi sobie z tak maym zespoem testujcym?
Gdybym mia uj to najprociej, jak potrafi, powiedziabym, e w Google ciar
dbania o odpowiedni jako oprogramowania spoczywa przede wszystkim na
barkach programistw. Jako nie jest nigdy problemem tych tam, testerw.
Kady pracujcy w Google programista jest jednoczenie testerem, wic o jako dba
dosownie kolektyw (rysunek 1.1). Mwienie o stosunku zatrudnienia programistw
do testerw w Goolge ma mniej wicej taki sam sens jak rozwaanie stopnia
zanieczyszczenia atmosfery przy powierzchni Soca. Takie rozwaania nie maj
zwyczajnie sensu. Jeli jeste inynierem, musisz zajmowa si te testowaniem.
Jeli za jeste inynierem ze sowem testowanie w tytule, zdoasz nauczy czego
kolegw, ktrzy s tylko programistami.
To, e tworzymy oprogramowanie klasy wiatowej, dowodzi stanowczo,
e wdroone w Google rozwizania zasuguj na blisze poznanie. By moe niektre
z naszych pomysw sprawdz si take w innych firmach, jednak z ca pewnoci
mona stwierdzi, e cz z nich wymaga ulepszenia. W dalszej czci rozdziau
znajdziesz skrcony opis metod testowania stosowanych w Google, a w pozostaych
postaram si opisa, w jaki sposb usiujemy czy praktyki testowe z tworzeniem
kodu.
Kup ksik Pole ksik
RYSUNEK 1.1. W Google stawiamy na jako, a nie na wymylne funkcje
Jako testy
Jakoci nie da si wdroy za pomoc testw. To truizm, ale warto o tym pamita.
Niewane, czy mwimy o samochodach, czy o aplikacjach komputerowych
jeli o jako nie zadbamy ju w fazie projektu, produkt nigdy nie bdzie dobry.
Wystarczy posucha skarg na koszty tych producentw samochodw, ktrzy
musieli wprowadza poprawki do ostatecznej wersji produktu. Jeli to, nad czym
pracujesz, nie bdzie przygotowane starannie od samego pocztku, przygotuj si
na powane kopoty.
Niestety nie jest to ani tak proste, jak mogoby si wydawa, ani zawsze skuteczne.
Cho jakoci rzeczywicie nie wdraa si za pomoc testw, praktyka dowodzi,
e bez testw nie da si osign odpowiedniej jakoci. Bo jak bez sprawdzania
oceni, czy produkt jest wystarczajco dobry, by przekaza go w rce klientw?
Podejdmy do problemu jak do zagadki logicznej. Najprostsze rozwizanie
zakada rezygnacj ze stanowiska, e prace nad produktem i testowanie s od siebie
niezalene. Testowanie i opracowywanie powinny przebiega jednoczenie. Napisz
fragment kodu i sprawd, jak dziaa. Dopisz kolejny kawaek i znw przetestuj.
Testowanie nie gwarantuje jakoci. Jako osiga si, czc prac nad kodem z cig
weryfikacj wynikw naley miesza je ze sob tak dugo, a stan si jednolit
mas.
Testowanie nie gwarantuje jakoci. Jako osiga si, czc prac nad kodem z cig
weryfikacj wynikw naley miesza je ze sob tak dugo, a stan si jednolit mas.
Kup ksik Pole ksik
To wanie staramy si osign w Google poczy prac nad kodem
i testowanie go, tak by jedno nie istniao bez drugiego. Napisz co, a potem to
sprawd. Napisz nastpn cz i znowu sprawd. W takim modelu najwaniejsze
jest to, kto przeprowadza testy. Poniewa liczba faktycznych testerw w Google
jest znacznie mniejsza ni liczba programistw, to wanie na tych ostatnich
spada obowizek sprawdzania kodu. A kto lepiej poradzi sobie z ocen jakoci
zaimplementowanych rozwiza, jeli nie osoba odpowiedzialna za powstanie
kodu? Kto szybciej znajdzie bd w programie ni jego twrca? Google moe pozwoli
sobie na ograniczenie liczby weryfikatorw, poniewa zatrudnia najwyszej klasy
programistw. Jeli aplikacja zawodzi, win obarcza si wtedy przede wszystkim
programist, ktry popeni bd, a nie testera, ktry go nie odnalaz.
Oznacza to, e jako wynika gwnie z zapobiegliwoci, a nie z dziaa majcych
na celu wykrywanie bdw. Jako wynika bezporednio ze sposobu rozwijania
projektu, a nie z metod, za pomoc ktrych jest on testowany. Staralimy si stworzy
proces wielostopniowy na tyle, na ile moglimy scali testowanie z prac nad
kodem dziki czemu wszelkie bdy pojawiajce si na danym etapie prac nad
projektem mona bardzo atwo wycofa. Dziki temu nie do, e oszczdzamy
wielu przykrych niespodzianek naszym klientom, to jeszcze udao nam si znacznie
zmniejszy liczb osb niezbdnych do usuwania bdw wywoania. Oglnie
staramy si sprowadzi kwesti testowania do badania, na ile sprawdzaj si procedury
zapobiegania wystpowaniu bdw.
Polityka czenia prac nad kodem z testowaniem jest nierozerwalnie zwizana
ze sposobem mylenia preferowanym w Google. Na pytanie: A gdzie wyniki testw?
mona natkn si u nas wszdzie poczwszy od uwag na marginesach raportw,
po ciany toalet, gdzie umieszczamy plakaty przypominajce naszym programistom
o koniecznoci testowania kodu
5
. Testowanie musi by nieodzownym aspektem
tworzenia kodu, gdy dopiero maria procedur weryfikujcych i programowania
pozwala uzyska produkt odpowiedniej jakoci.
Testowanie musi by nieodzownym aspektem tworzenia kodu, gdy dopiero maria
procedur weryfikujcych i programowania pozwala uzyska produkt odpowiedniej
jakoci.
Podzia rl
Aby pozosta w zgodzie z mottem: Sam zrobie, sam rozbierz (i utrzyma ten
stan rzeczy w miar upywu czasu), poza utrzymywaniem typowego zespou do
zada programistycznych firma musi okreli dla pracownikw take zakres innych
obowizkw. Chodzi tu przede wszystkim o okrelenie czynnoci, ktre pozwol

5
http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html
Kup ksik Pole ksik
programistom skutecznie i wydajnie testowa programy. W Google zadbalimy
o to, by niektrzy z naszych inynierw mieli za zadanie nadzorowa prac innych,
dziki czemu ci drudzy osigaj lepsze wyniki w krtszym czasie. Grupa nadzorujca
bardzo czsto okrela si sama mianem testerw, ale jej podstawowym zadaniem
jest czuwanie nad utrzymaniem wydajnoci pracy. Rol testerw jest podnoszenie
wydajnoci w zespoach programistycznych, a unikanie wprowadzania kolejnych
poprawek, ktre musz pojawia si w kiepsko opracowanym kodzie, to bardzo
istotny czynnik wydajnoci. Dlatego te w dalszych rozdziaach powicimy sporo
miejsca na dokadne omwienie stosowanego w Google podziau rl. Na razie za
przedstawiam krtkie ich zestawienie.
Inynier oprogramowania (IO) to zwyczajny programista. Do jego obowizkw
naley przygotowanie kodu, ktry ostatecznie trafia do uytkownika. To programici
przygotowuj dokumentacj, okrelaj struktury danych projektu i jego architektur,
a wikszo czasu powicaj na tworzenie kodu i sprawdzanie jego poprawnoci.
Inynier oprogramowania przygotowuje ogromne iloci kodu testujcego, gwnie
w ramach pracy w systemie projektowania z uyciem testw (ang. test-driven design,
TDD), tworzy testy jednostkowe i co jeszcze wyjanimy w tym rozdziale bierze
udzia w opracowaniu maych, rednich i wielkich procedur testujcych. Inynier
oprogramowania odpowiada za jako wszystkiego, z czym ma styczno, niezalenie,
czy to oprogramowa, wyrugowa potknicia innych, czy cakowicie zmodyfikowa
kod. Tak wanie jeli inynier wprowadza zmiany w istniejcych funkcjach i przez
to funkcja przestaje przechodzi przez istniejce ju testy albo wymaga dodatkowej
weryfikacji, to inynier ma obowizek przygotowa nowe procedury sprawdzajce.
Inynier oprogramowania powica si niemal cakowicie pisaniu kodu.
Inynier do spraw testowania oprogramowania (ITO) to take stanowisko
programistyczne, przy czym osoby je piastujce maj za zadanie skupia si przede
wszystkim na kwestii testowania i oglnych zaoeniach procedur testujcych.
Do ich obowizkw naley opiniowanie projektw i badanie kodu pod ktem
speniania norm jakociowych oraz oceny ryzyka. Do ich zada naley refaktoryzacja
kodu, tak by dawa si on atwiej testowa, oraz przygotowywanie szkieletu testujcego
poszczeglne moduy i automatyzowanie procesu sprawdzania jakoci kodu. Ludzie
zatrudnieni na tego rodzaju stanowiskach to take programici, ale ich zainteresowanie
skupia si przede wszystkim na podnoszeniu jakoci produktu i prowadzeniu
weryfikacji. Kwestie dodawania nowych funkcji czy zwikszania wydajnoci s dla
nich drugorzdne. Cho wikszo czasu rwnie pochania im programowanie,
to przygotowywany przez nich kod ma przede wszystkim podnosi jako oferowanego
produktu, a nie rozwija istotne z punktu widzenia uytkownika funkcje.
Cho wikszo czasu rwnie pochania im programowanie, to przygotowywany
przez nich kod ma przede wszystkim podnosi jako oferowanego produktu, a nie
rozwija istotne z punktu widzenia uytkownika funkcje.
Kup ksik Pole ksik
Inynier testujcy (IT) to stanowisko zblione do stanowiska inyniera do spraw
testowania oprogramowania, przy czym osoby je piastujce powinny skupia si
na nieco innym aspekcie prowadzenia testw. Inynier testujcy powinien bada
produkt przede wszystkim z punktu widzenia uytkownika, a dopiero potem
zastanawia si, jak na ten sam problem spojrzy programista. Niektrzy
z zatrudnionych w Google inynierw testujcych powicaj mnstwo czasu na
przygotowanie kodu skryptw automatyzujcych czy aplikacji realizujcych rne
scenariusze uytkowania, a czasami wrcz udajcych dziaanie uytkownika.
Jednoczenie organizuj testy prowadzone przez IO czy ITO, interpretuj wyniki
i przeprowadzaj ostateczn weryfikacj, szczeglnie w kocowych fazach pracy
nad projektem, gdy wysiki wszystkich skupiaj si na przygotowaniu produktu
do wypuszczenia na rynek. Inynierowie testujcy to eksperci do spraw produktu,
doradcy do spraw jakoci i analitycy ryzyka. Wielu z nich zajmuje si aktywnie
programowaniem, lecz rwnie liczna grupa praktycznie tego nie robi.
Uwaga
Inynier testujcy sprawdza program przede wszystkim z punktu widzenia uytkownika.
Do jego zada naley przygotowanie wszystkich dziaa zwizanych z podniesieniem
jakoci produktu, interpretowanie wynikw testw, przeprowadzanie samych testw
i tworzenie kompleksowej automatyzacji testw.
Wracajc jednak do rozwaa na temat jakoci inynierowie oprogramowania
zajmuj si pewnymi aspektami dziaania aplikacji i kwesti jakoci wdraanych
rozwiza w raczej izolowanym rodowisku. Do ich obowizkw naley przygotowanie
projektu odpornego na usterki, przywracanie aplikacji do stanu sprzed pojawienia
si bdu, projektowanie z uyciem testw, tworzenie testw jednostkowych
i aktywna wsppraca z inynierami do spraw testowania oprogramowania podczas
pisania kodu testujcego funkcje badanej aplikacji.
Z kolei inynierowie do spraw testowania oprogramowania to programici
przygotowujcy funkcje testowe. Oni opracowuj szkielet pozwalajcy wyizolowa
przygotowywany kod przez symulowanie rodowiska, w jakim ma on docelowo
dziaa (tu wykorzystywane s takie narzdzia, jak stub, mock i fake metody,
ktre opisz dokadniej nieco dalej), i okrelanie kolejnoci, w jakiej kod bdzie
weryfikowany. Innymi sowy, inynier do spraw testowania oprogramowania
przygotowuje kod, dziki ktremu inynier oprogramowania bdzie mg sprawdzi
poprawno przygotowanych funkcji. Samo prowadzenie testw bardzo czsto
spada ju na IO. ITO ma za zadanie sprawdzi, czy poszczeglne funkcje w ogle
nadaj si do testowania, i dopilnowa, by IO aktywnie uczestniczy w przygotowywaniu
kodu przypadkw testowych.
Z powyszego opisu wynika wyranie, e ITO bierze pod uwag przede wszystkim
perspektyw programisty. Jego zadaniem jest zadba o jak najwysz jako
Kup ksik Pole ksik
dziaania poszczeglnych funkcji programu i jak najbardziej uatwi programistom
zweryfikowanie przygotowanego przez nich kodu. Prowadzenie testw
uwzgldniajcych punkt widzenia uytkownika to zadanie zatrudnianych przez
Google inynierw testujcych. Gdy testy na poziomie moduowym i na poziomie
funkcjonalnoci przeprowadzone przez IT oraz ITO dadz zadowalajce wyniki,
nadejdzie pora, by sprawdzi, w jaki sposb uytkownik odczuje dziaanie aplikacji
zasilanej odpowiednimi danymi. Testy wykonywane przez IT s poniekd
podwjnym sprawdzeniem sprawnoci programistw. Wszystkie wykryte przez
nich oczywiste bdy bd dowodem, e weryfikacja wykonana na wczesnym
poziomie przez programistw zostaa przeprowadzona niestarannie i w nieodpowiedni
sposb. Gdy okae si, e takie bdy s sporadyczne, IT moe zaj si podstawowym
stawianym przed nim zadaniem, czyli sprawdzeniem, czy oprogramowanie bdzie
dziaa poprawnie w typowych warunkach uytkowania, czy bdzie spenia
oczekiwania uytkownika, czy jest odpowiednio zabezpieczone, zlokalizowane,
czy jest przystpne i tak dalej. Inynier testujcy zajmuje si przede wszystkim
przeprowadzaniem testw i koordynowaniem pracy swoich kolegw oraz testerw
kontraktowych, testerw z tumu, testerw wewntrznych (tzw. dogfooderw
6
),
uytkownikw wersji beta i awangardy wrd uytkownikw. To wanie inynierowie
testujcy przekazuj czonkom zainteresowanych grup informacje o problemach
mogcych wystpi w podstawowym projekcie, opisuj im stopie skomplikowania
funkcji aplikacji i metody unikania bdw. Trzeba przyzna, e praca inyniera
testujcego nie ma koca.
Struktura organizacyjna
W wikszoci firm, z ktrymi miaem okazj wsppracowa, programici i testerzy
tworz jeden zesp pracujcy nad danym projektem i jedni, i drudzy odpowiadaj
przed tym samym szefem zespou. Jeden produkt, jeden zesp i wszyscy stoj po
jednej stronie barykady.
Niestety nigdy nie widziaem, eby ten model sprawdzi si w praktyce. Starsi
menederowie s rekrutowani najczciej spord kierownikw zespow lub
programistw bardzo rzadko z grupy testerw. Std w gorcym okresie
poprzedzajcym premier gwny nacisk kadzie si raczej na dopracowanie funkcji
aplikacji, a nie na testowanie jakoci jej jdra. W tak zorganizowanym zespole
testowanie spada na podrzdn pozycj, czego dowody znajdziemy zreszt w nie
tak odlegej przeszoci, penej wadliwych produktw i przedwczesnych wej na
rynek. Czy znajd chtnych na Service Pack1?

6
Okrelenie dogfood przyjo si w wikszoci firm informatycznych w Stanach Zjednoczonych.
Opisuje ono proces adaptowania oprogramowania przygotowywanego do wprowadzenia na
rynek wewntrz danej firmy. Wyraenie eating your own dogfood (zjadanie karmy swojego psa
przyp. tum.) ma oddawa koncepcj, e zanim sprzeda si komu wasny produkt, naley
sprawdzi jego jako na sobie.
Kup ksik Pole ksik
Uwaga
Mimo e zesp pracujcy nad danym projektem powinien by zgrany, nadzorujcy
prac wywodz si zazwyczaj z grupy kierownikw niszego szczebla lub projektantw,
rzadko za spord testerw. W gorcym okresie poprzedzajcym premier aplikacji
gwny nacisk kadzie si raczej na dopracowanie funkcji aplikacji, a nie na testowanie
jakoci jej jdra. To struktura organizacyjna sprawia, e testy zawsze bd traktowane
z mniejszym namaszczeniem ni programowanie.
Struktur organizacyjn Google tworz tak zwane obszary zainteresowania
(ang. Focus Area), czyli OZ-y. Osobny OZ obsuguje stref klienta (Chrome, Google
Toolbar i im podobne), osobny geolokalizacj (Mapy, Google Earth itp.), a jeszcze
inne zajmuj si reklamami, aplikacjami czy programami na urzdzenia mobilne.
Wszyscy inynierowie oprogramowania odpowiadaj przed kierownikiem lub
wiceprezesem danego OZ.
Inynierowie do spraw testowania oprogramowania i inynierowie testujcy
wyamuj si z tego schematu. Do testw dochodzi w niezalenej jednostce, ktrej
kompetencje przenikaj przez wszystkie obszary zainteresowania, czyli we wspomnianej
ju grupie wydajnoci projektowej. Testerzy s wypoyczani poszczeglnym zespoom
programistw i nikt nie dziwi si, gdy zgaszaj uwagi dotyczce jakoci produktu
czy zastrzeenia dotyczce tych jego funkcji, ktre nie zostay naleycie przetestowane
czy te ktre wykazuj zbyt wiele bdw, by mona byo uzna je za dopuszczalne.
Kierujemy si wasnymi priorytetami i nie zarzucimy dbania o solidno rozwiza
czy bezpieczestwo na rzecz niczego, co nie bdzie naprawd istotne. Jeli zespoowi
programujcemu zaley na skrceniu testw, musimy wiedzie o tym wczeniej,
ale nawet gdy pojawi si taka proba, zawsze mamy prawo odmwi.
Dziki temu Google moe ograniczy liczb testerw. Kierownik zespou
pracujcego nad przygotowaniem aplikacji nie moe samodzielnie zadecydowa
o obnieniu wymaga jakociowych stawianych produktowi, nie moe te zatrudni
wikszej liczby testerw, by zepchn na nich niewdziczne zadania. Programista
zajmujcy si przygotowaniem danej funkcji programu musi zmierzy si te
z tymi mniej przyjemnymi i mudnymi aspektami pracy nad aplikacj i naprawd
nie ma prawa spycha tych zada na jakiego nieszczsnego testera. O przydziale
testerw do poszczeglnych projektw decyduje kierownictwo grupy wydajnoci
projektowej. Podstaw do podejmowania decyzji s priorytet przypisany danemu
projektowi, zoono zagadnienia i potrzeby danego zespou oceniane w stosunku
do potrzeb pozostaych grup. Oczywicie i my moemy si myli zreszt czasami
tak wanie si dzieje ale mimo to zastosowane podejcie pozwala wykorzysta siy,
jakimi dysponujemy, do zaspokojenia prawdziwych, a nie wydumanych potrzeb.
Kup ksik Pole ksik
Uwaga
Przydzielaniem testerw do poszczeglnych projektw zajmuje si kierownictwo
grupy wydajnoci projektowej. Podstaw do podejmowania decyzji s priorytet
przypisany danemu projektowi, zoono zagadnienia i potrzeby danego zespou
oceniane w stosunku do potrzeb pozostaych grup. Zastosowane podejcie pozwala
wykorzysta siy, jakimi dysponujemy, do zaspokojenia prawdziwych, a nie wydumanych
potrzeb.
Takie wypoyczanie testerw sprawia te, e zadania stawiane przed inynierami
do spraw testowania oprogramowania i inynierami testujcymi cigle si zmieniaj,
dziki czemu ITO i IT nie trac zainteresowania tematem, ktry przecie zawsze
jest nowy i fascynujcy. Jednoczenie rozwizanie to zapewnia w naturalny
sposb wzmoony przepyw pomysw wewntrz firmy. Tak zwikszamy
prawdopodobiestwo ponownego wykorzystania dobrych procedur testowych
tester, ktry sprawdzi jak koncepcj w czasie pracy nad projektem z dziau
geolokacji, uyje jej zapewne take po przeniesieniu go do prac nad przegldark
Chrome. Nic tak nie przyspiesza rozprzestrzeniania si idei jak przeniesienie jej
twrcy w nowe rodowisko.
Przyjmujemy zasadniczo, e po osiemnastu miesicach tester moe (ale nie musi)
zada przeniesienia do nowego projektu bez adnych konsekwencji. Z jednej
strony oznacza to oczywicie, e projekt traci eksperta, lecz jednoczenie pamitajmy,
e w konsekwencji stosowanej polityki testerzy Google znaj si oglnie na wszystkim
i maj bogate dowiadczenie w pracy nad rnymi rodzajami aplikacji. Mona
powiedzie, e Google to firma zatrudniajca testerw, ktrzy rozumiej potrzeby
klienta, znaj moliwoci sieci i przegldarek, wiedz, czego wymaga praca
z technologiami mobilnymi, i potrafi pisa programy w wielu jzykach i na rne
platformy. A poniewa nasze aplikacje i usugi s teraz powizane ze sob cilej
ni kiedykolwiek w przeszoci, tester zmieniajcy zesp tak czy inaczej dysponuje
odpowiednim dowiadczeniem.
Od raczkowania, przez chd, do biegu
Google osiga tak zdumiewajce wyniki mimo zatrudniania mniejszej ni w innych
firmach liczby testerw, poniewa w odrnieniu od innych duych firm rzadko
usiujemy wprowadza do naszych produktw mnstwo innowacji naraz. W zasadzie
dziaamy zupenie inaczej najpierw przygotowujemy starannie jdro aplikacji
i w chwili, gdy staje si ono zdatne do uycia, staramy si udostpni je jak najszerszej
grupie odbiorcw. Nastpnie zapoznajemy si z ich uwagami i prbujemy wprowadzi
je w ycie, a gdy poprawki s gotowe, znw udostpniamy je klientom. Tak
postpilimy w przypadku aplikacji Gmail, ktra przez cztery lata funkcjonowaa
formalnie jako wersja beta. Etykietka pojawiajca si przy nazwie usugi ostrzegaa
Kup ksik Pole ksik
uytkownikw, e produkt jest cigle w fazie ulepsze. Usunlimy j dopiero, gdy
udao si nam osign zamierzony wczeniej cel serwery obsugujce rzeczywiste
konta uytkownikw przez 99,99% czasu. Podobnie postpilimy z Androidem,
udostpniajc go wycznie na telefonie G1, ktre to poczenie zyskao sobie
uznanie uytkownikw i recenzentw. Nexus, telefon nowej linii i nastpca G1,
funkcjonowa ju z now wersj systemu o bardziej rozbudowanych funkcjach.
Tu naley podkreli, e gdy klient paci za wczesn wersj towaru, musi ona by
funkcjonalna na tyle, by nie mia on poczucia, e zosta oszukany. To, e jest to
wczesna wersja, nie musi oznacza, e towar nie nadaje si do uycia.
Uwaga
Google czsto wprowadza na rynek najmniej rozbudowan dziaajc wersj
programu i dopiero z czasem rozwija j o kolejne moliwoci, zbierajc jednoczenie
wraenia uytkownikw tak tych wewntrz firmy, jak i pierwszych klientw.
Przed wykonaniem kolejnego niewielkiego kroku naprzd zawsze starannie rozwaamy
jego wpyw na jako produktu. Kada aplikacja Google przechodzi przez kilka etapw:
wersj kanarkow (ang. canary), dewelopersk, testow, beta i RC (ang. release
channel), zanim trafi w ostatecznej postaci do najszerszego grona odbiorcw.
Rozwizanie to nie niesie ze sob tak wielkiego ryzyka, jak mogoby si wydawa
na pierwszy rzut oka. W rzeczywistoci zanim produkt osignie faz beta, musi
przej kilka innych etapw, na ktrych sprawdzamy, czy jest wart przyznania mu
etykiety beta. Przegldarka Chrome nad tym projektem spdziem pierwsze
dwa lata pracy dla Google bya oferowana rnym grupom odbiorcw w rnych
kanaach dystrybucji, zanim zebralimy odpowiednio wiele opinii, by uzna, e jest
produktem godnym zaufania. Na poszczeglnych etapach rozwoju aplikacja jest
dostpna w kilku rnych kanaach dystrybucji:
kanarkowym kana ten wykorzystujemy do rozpowszechniania wczesnych,
zmieniajcych si niemal codziennie wersji oprogramowania, ktre
prawdopodobnie nie nadaj si jeszcze do zaprezentowania szerszemu gronu
odbiorcw. Te wypusty odgrywaj tak sam rol jak kanarek w kopalni
jeli aktualna wersja nie przetrwa fazy testw, stanowi to sygna, e prace nad
ni przebiegay zbyt chaotycznie i koniecznie trzeba zastanowi si nad ich
ksztatem. Wersje oferowane w kanale kanarkowym s przeznaczone wycznie
dla bardzo odpornych psychicznie uytkownikw, ktrzy s zainteresowani
przede wszystkim prowadzeniem testw. Z pewnoci nie naley proponowa
ich ludziom potrzebujcym dziaajcego w peni programu. Oglnie z kanau
tego korzystaj wycznie inynierowie (programici i testerzy) oraz kierownicy
nadzorujcy tworzenie danej aplikacji;
Kup ksik Pole ksik
Uwaga
Zesp odpowiedzialny za rozwijanie systemu Android poszed o krok dalej. Niemal
wszyscy jego czonkowie korzystaj z wypuszczanych codziennie nowych wersji
systemu. Chodzi o to, e jeli sami nie bd mogli zadzwoni do domu, nie bd
tak ochoczo przechodzi do porzdku dziennego nad bdami w kodzie.
deweloperskim z kanau tego korzystaj na co dzie programici. Za jego
porednictwem udostpnia si zazwyczaj wersje bdce wynikiem prac z caego
tygodnia, ktre sprawdziy si ju w niektrych obszarach i przeszy niektre
z testw (do tego tematu wrcimy w dalszych rozdziaach). Wszyscy pracujcy
nad danym produktem maj obowizek pobiera aplikacje udostpniane t
drog, korzysta z nich w pracy i przeprowadza testy. Jeli wersja deweloperska
aplikacji nie sprawdzi si w codziennych zdaniach, wraca do kanau kanarkowego.
Tego rodzaju wydarzenia nie daj powodw do radoci i zazwyczaj prowadz
do wzmoonych bada majcych pozwoli raz jeszcze oceni cao projektu;
testowym tym kanaem rozpowszechnia si zazwyczaj wersj, ktr mona
by nazwa mianem zwycizcy miesica, czyli tak, ktra przejdzie pozytywnie
wikszo prowadzonych na tym etapie testw i cieszy si najwikszym
uznaniem w oczach jej autorw. Z kanau testowego korzystaj wewntrzni
dogfooderzy, a prezentowana im wersja aplikacji jest zazwyczaj silnym kandydatem
na pozycj wersji beta. Na pewnym etapie prac wersja testowa staje si na tyle
stabilna, e mona uywa jej bezpiecznie wewntrz firmy, a z czasem udostpnia
take wybranym wsppracownikom zewntrznym i partnerom, ktrzy mogliby
skorzysta na wczeniejszym poznaniu nowego towaru;
beta lub RC do tego etapu docieraj stabilne wersje testowe, ktre zostay
sprawdzone ju w wewntrznym uyciu firmowym i zdoay pokona wszystkie
poprzeczki testowe stawiane przez czonkw zespou deweloperskiego. To one
jako pierwsze trafiaj do szerszego grona odbiorcw.
Stabilny rozwj od raczkowania, przez chd, a do biegu pozwala nam
przeprowadza testy ju w najwczeniejszych wersjach aplikacji i zbiera uwagi nie
tylko z prowadzonych codziennie w kadym z kanaw automatycznych testw
programowych, lecz take od ludzi, ktrzy mieli styczno z produktem.
Rodzaje testw
Google nie stosuje typowego podziau testw na testy kodowania, integracji
i systemowe. Zamiast takiego rozrnienia wprowadzamy wasn nomenklatur
testy mae, rednie i due (nie mylmy tych poj ze stosowanymi przez lotn
spoeczno przyblionymi rozmiarami ubra). Stosowane nazwy maj oddawa
zasig prowadzonych bada. Za pomoc maych testw sprawdzamy niewielkie
Kup ksik Pole ksik
wycinki kodu i tak dalej. Kada ze wspomnianych wczeniej grup inynierw moe
zajmowa si prowadzeniem dowolnego rodzaju testw; testy te mog mie
charakter tak automatyczny, jak i rczny.
Zamiast przeprowadza osobno testy kodowania, integracji i systemowe, Google
woli stosowa mae, rednie bd due testy w zalenoci od tego, jaki zakres
aplikacji jest sprawdzany za ich pomoc.
Mae testy obejmuj przede wszystkim (cho nie tylko) weryfikacj automatyczn,
ktrej celem jest sprawdzenie kodu zawartego wewntrz jednej funkcji czy w danym
module. W czasie ich trwania bada si przede wszystkim sposb dziaania kodu,
szuka bdw zapisu danych, okrela warunki ich wystpowania i wyszukuje bdy
logiczne typu off-by-one, czyli pomyki polegajce na przesuniciu o jeden wartoci
dyskretnych, bardzo czsto o charakterze brzegowym. Mae testy nie pochaniaj
wiele czasu zazwyczaj przeprowadza si je w kilka sekund. Odpowiednie funkcje
przygotowuj IO, rzadziej ITO, a IT prawie nigdy nie maj z nimi do czynienia.
Mae testy prowadzi si w rodowiskach prbnych za pomoc tak zwanych mockw
i fakew. (Mock i fake to odmiany obiektw typu stub, czyli obiekty zastpujce
rzeczywiste funkcje. Przechowuje si w nich funkcje, ktre by moe w ogle nie
zostan wykorzystane w ostatecznej wersji aplikacji, s zbyt niedopracowane,
by mona byo ich uy, czy zbyt skomplikowane, by okreli warunki, w jakich
mog wystpi w nich bdy. W dalszych rozdziaach wrc jeszcze do tego tematu).
Inynierowie testujcy nie pisz wprawdzie zbyt czsto maych testw, za to zdarza
si im uruchamia je, by okreli przyczyny wystpowania konkretnego bdu.
Mae testy maj za zadanie uzyska odpowied na pytanie: Czy ten fragment
kodu dziaa tak, jak powinien?.
rednie testy przeprowadza si najczciej automatycznie, by sprawdzi za ich
pomoc przynajmniej dwie wspdziaajce funkcje aplikacji. Na tym etapie sprawdza
si przede wszystkim relacje funkcji wywoujcych si wzajemnie albo oddziaujcych
w jaki sposb na siebie. Funkcje tego rodzaju nazywamy najbliszymi ssiadami.
Inynierowie z grupy ITO nadzoruj przygotowanie tych testw jeszcze we wczesnej
fazie pracy nad aplikacj, rwnolegle do przygotowywania poszczeglnych funkcji.
Za przygotowanie ich od strony kodu, sprawdzenie poprawnoci i przeprowadzenie
testw odpowiadaj zazwyczaj IO. W razie gdyby redni test nie da si uruchomi
lub dawa bdne wyniki, programista moe sam wprowadzi w nim poprawki.
W pniejszej fazie prac nad aplikacj rednie testy wykonuj inynierowie testujcy
czasami rcznie (jeli automatyzacja procesu byaby zbyt trudna lub zbyt kosztowna),
czasami za automatycznie. rednie testy pozwalaj szuka odpowiedzi na pytanie:
Czy ten zestaw ssiadujcych ze sob funkcji dziaa w sposb, w jaki powinien?.
Due testy obejmuj sprawdzenie wspdziaania przynajmniej trzech (a zazwyczaj
wikszej liczby) funkcji aplikacji i zawieraj scenariusze faktycznego uytkowania.
Przeprowadzenie ich zajmuje zazwyczaj co najmniej kilka godzin. Cho przy okazji
Kup ksik Pole ksik
sprawdza si oglny stopie zintegrowania poszczeglnych funkcji, to najwaniejszym
ich aspektem jest badanie zwracanych w czasie ich trwania wynikw, na podstawie
ktrych ocenia si, czy program speni oczekiwania uytkownika. W pracach nad
przygotowaniem duych testw bior udzia wszystkie grupy inynierw, a sam
test moe przebiega w dowolny sposb od penego zautomatyzowania procesw
do prowadzenia rcznie testw badawczych. Przeprowadzajc due testy, staramy
si odpowiedzie na pytanie: Czy aplikacja dziaa w sposb, jakiego oczekiwaby
uytkownik, i czy wyniki jej pracy s zadowalajce?. Do tej grupy testw zalicza
si midzy innymi przekrojowe scenariusze badajce wyniki pracy penych wersji
oprogramowania i usug.
Uwaga
Mae testy maj za zadanie zweryfikowa poprawno dziaania niewielkich fragmentw
kodu uruchamianego w sztucznie przygotowanym rodowisku. rednie testy pozwalaj
sprawdzi dziaanie wielu wspdziaajcych ze sob moduw w warunkach sztucznie
przygotowanych, ale take w faktycznym rodowisku dziaania aplikacji. Due testy
pozwalaj bada dowoln liczb moduw uruchamianych w dedykowanym im
rodowisku i z wykorzystaniem autentycznych zasobw.
Sama nomenklatura nie jest istotna. Nie musisz nazywa testw maymi,
rednimi i duymi, jeli nie masz ochoty grunt, eby zastosowane nazwy nie
wprowadzay nikogo w bd
7
. Najwaniejsze, e testerzy w Google maj jzyk,
w ktrym mog si porozumiewa i uzgadnia zakres prowadzonych prac. A jeli
ktremu bardziej rzutkiemu zamarzyoby si przeprowadzenie testw jeszcze
wyszego poziomu, w zwizku z czym wprowadziby nazw olbrzymie testy, kady
inny pracownik firmy domyliby si od razu, e chodzi o sprawdzenie dziaania
caego systemu, kadej jego funkcji, i e naley na to zarezerwowa odpowiednio
duo czasu. adne dodatkowe wyjanienia nie s ju konieczne
8
.
Wytyczne dotyczce elementw poddawanych testom i dynamiki procesu
weryfikacji zmieniaj si z projektu na projekt. Google preferuje polityk wprowadzania
na rynek czstych aktualizacji, co pozwala szybciej prezentowa kolejne wersje

7
Nazewnictwo stosowane w Google zrodzio si z autentycznej potrzeby. Okazao si, e naley
ustandaryzowa terminologi stosowan przez testerw, ktrzy pracowali przecie wczeniej
w innych firmach, gdzie posugiwano si zupenie innymi nazwami czasami byy to testy dymne,
czasami testy BVT, czasem integracyjne. Terminom tym przypisywano rne, niejednokrotnie
przeciwstawne znaczenia, uznano zatem, e Google potrzebuje wasnych okrele.
8
I rzeczywicie idea olbrzymich testw trafia do oficjalnej dokumentacji. W infrastrukturze Google
funkcjonuj na co dzie pojcia testw maych, rednich i tak dalej w ten sposb definiuje si
kolejk wykonywania zada w czasie trwania testw automatycznych. Wicej szczegw znajdziesz
w rozdziale powiconym zadaniom stawianym przed inynierami do spraw testowania.
Kup ksik Pole ksik
uytkownikom i szybciej zbiera ich odzew. W ten sposb przyspieszamy prace
nad kolejnymi zmianami. W Google staramy si rozwija tylko te aplikacje i usugi,
ktre przypady uytkownikom do gustu, i wprowadza nowe funkcje tak szybko,
jak jest to moliwe, by odbiorca nie musia dugo na nie czeka. Jednoczenie
jestemy w stanie ograniczy liczb zbdnych rozwiza na bardzo wczesnym
etapie. Oczywicie tego rodzaju model dziaania wymaga wczesnego wydania
aplikacji w rce uytkownikw i zewntrznych programistw, ale wanie dziki
niemu mamy pewno, e oferujemy ludziom dokadnie to, czego potrzebuj.
Wreszcie trzeba stwierdzi wyranie, e w poczeniu testw automatycznych
z prowadzonymi rcznie te pierwsze stoj na zdecydowanie uprzywilejowanej
pozycji. Jeli zagadnienie da si zautomatyzowa, a sam problem nie wymaga
odwoywania si do ludzkiej intuicji i zdolnoci umysowych, naley bezwzgldnie
stosowa rozwizania maszynowe. Testy rczne warto stosowa tylko tam, gdzie
osd czowieka jest absolutnie niezbdny, na przykad podczas podejmowania
decyzji dotyczcych estetyki interfejsu uytkownika czy okrelania, ktre z danych
mog narusza prawo do prywatnoci.
We wszystkich trzech opisanych wczeniej metodach testowania w poczeniu
testw automatycznych i rcznych te pierwsze sprawdzaj si znacznie lepiej. Jeli
zatem zagadnienie da si zautomatyzowa, a sam problem nie wymaga odwoywania
si do ludzkiej intuicji i zdolnoci umysowych, naley bezwzgldnie stosowa
rozwizania maszynowe.
To jedna strona medalu. Jednoczenie Google przeprowadza mnstwo testw
rcznych, zarwno skryptowych, jak i eksploracyjnych, ale nawet one przebiegaj
pod czujnym okiem zautomatyzowanych procedur. Techniki nagrywania pozwalaj
tworzy testy automatyczne na podstawie zapisw z przeprowadzanej wczeniej
rcznej weryfikacji kade przesunicie kursora i kade kliknicie jest rejestrowane,
by w kolejnych wersjach aplikacji mc wykorzysta te nagrania i dziki temu
zminimalizowa regresj prac nad programem. Takie rozwizanie pozwala testerom
pracujcym wasnorcznie nad badaniem aplikacji zaj si nowymi problemami.
Automatyzujemy te procedur przesyania raportw i organizowania wykonywanych
rcznie zada testowych
9
. Jeeli przykadowo funkcja nie przejdzie automatycznych
testw poprawnie, system wskae ostatnie z wprowadzonych w kodzie zmian,
typujc tym samym najbardziej prawdopodobnego sprawc nieszczcia, wyle
wiadomo do jej autora i sam wprowadzi do dziennika odpowiedni informacj
o wystpieniu bdu. Nieustannie podejmowane wysiki, majce na celu wprowadzi
automatyzacj rwnie w ostatnim odcinku ludzkiego umysu, stanowi swojego
rodzaju specyfikacj narzdzi testowych nowej generacji, jakie powstaj w Google.

9
Wicej na temat mechanizmw rejestrujcych i automatyzacji testw rcznych znajdziesz
w rozdziaach powiconych pracy inynierw testujcych.
Kup ksik Pole ksik
Skorowidz
#include, 99
3G, 235
A
Accepted, 173
ActionScript
ActionScript2, 246
ActionScript3, 246
addurl, 72
AddUrl, 71
addurl.pb.cc, 72
addurl.pb.h, 72
addurl.proto, 71
addurl_frontend, 74
addurl_frontend.cc, 73
addurl_frontend_test, 78, 79
addurl_frontend_test.cc, 74
AddUrlFrontend, 70, 72, 73
destruktor, 73
konfiguracja testu, 76
konstruktor, 73
AddUrlFrontendTest, 75
AddUrlReply, 71
AddUrlRequest, 71
pole uri, 71
AddUrlService, 70
definicja protokou, 70
deklaracja konstruktora kopiowania
i operatora, 72
faszywa usuga, 75
wstrzykiwanie zalenoci, 72, 73
aktualny stan aplikacji, 125
alokacja, 254
decydujce argumenty, 255
dopasowanie predyspozycji, 255
poprzednie alokacje, 255
potrzeby projektu, 255
pragnienia pracownika, 255
analiza
dwch izolowanych zmian w kodzie, 92
ryzyka, 139
WSM, 127, 128, 133
analiza ryzyka, 139
budet i czas, 139
czasowniki aplikacji, 133
dla aplikacji Google+, 139
lista waciwoci, 129
macierz, 227
moliwoci, 133
moliwoci aplikacji, 136
para waciwo - skadowa, 136, 153
przykady moliwoci, 135
przymiotniki aplikacji, 128, 129
reguy, 127
rzeczowniki systemu, 132
skadowe, 132
skadowe aplikacji, 136
stopniowanie moliwoci aplikacji, 157
tabela moliwoci, 137
waciwoci, 128
waciwoci aplikacji, 129, 130, 136, 227
waciwoci systemu, 129
wskazanie skadowych, 132
zalenoci, 92
Android, 265
filary, 267
podnoszenie wartoci, 266
zakadanie zespou, 265
API
automatyzujce, 118
aplikacja
Ads, 247
BITE
funkcja RPF, 220
polecenie Record and Play, 219
przegldanie informacji o bdach, 216
wpyw na ksztat usugi Maps, 216
zapisywanie i odtwarzanie danych, 217
Kup ksik Pole ksik
aplikacja
etapy rozwoju, 42
Google Test Analytics, 224
kanay dystrybucji, 42
kompatybilno, 272
rozwj kadej z funkcji, 306
RPF, 218
Selenium, 217
skuteczne znajdowanie bdw, 305
stabilny rozwj, 43
tryb utrzymania jakoci, 196
w stanie utrzymania
dziaania przygotowawcze, 197
wysyajca adresy URL do Google, 70
AppManager, 320
arkusz kalkulacyjny
wady, 223
As3Unit, 248
Assigned, 173
Assigned to, 170
atak
typu cross-site, 221
atrybuty
ID, 219
Attachments, 171
automatyczne testy, 46
przedwysykowe, 67
automatyczny system testujcy, 90
automatyzacja
dziaa
rady, 284
interfejsu uytkownika, 273
P0, 315
testw, 79, 83, 87, 280
Android, 267
aplikacji przegldarkowych, 117
sytuacje, 268
w strukturach E2E, 320
Autotest, 274, 319
B
badanie
jakoci za pomoc botw
ChromeBot, 206
dowiadczenie, 197
indeks, 198
pezanie, 198
pochodzenie botw, 206
ranking, 199
wyniki, 199, 202
przypadkw testowych dla systemu Chrome OS
rczne, 316
stabilnoci dziaania, 316
Banana Proxy, 248
baza bdw, 113
beta, 43
Bialik Tracy, 97
biblioteki
addurl, 72
addurl_frontend, 74
C++ AddUrlFrontend, 74
ctype, 194
dla platform systemowych, 53
funkcje nowej usugi, 55
PyAuto, 273
testowanie, 55
wspdzielone
zmiany, 93
bieg na orientacj, 328
BITE, 211, 333
GTCM, 222
i RPF
BITE Web Test Framework, 222
Flux Capacitor, 222
kukieka, 221
pocztki, 220
WTF, 222
interfejs do wprowadzania danych dotyczcych
bdu, 335
konsola nagrywania i odtwarzania dziaa
uytkownika, 334
menu dodatku, 334
prowadzenie testw rcznych i eksploracyjnych,
222
RPF, 340
skrypty, 223
system zarzdzania przypadkami testowymi, 222
warstwy, 223
biece, 223
wprowadzenie informacji o bdzie, 334
zalety, 334
Blocking, 171
bdy, 164
bardzo rzadkie, 145
Kup ksik Pole ksik
Skorowidz 349
baza bdw Buganizer, 165, 216, 217
autoryzacja logowania, 165
bdy o priorytecie P0, 166
cechy, 175
elastyczna hierarchia n-poziomowa, 165
generowanie podsumowa, 165
informacje sumaryczne, 166
odpowiedzialno za wykrycie bdw, 165
omwienie, 170
podnoszenie komfortu pracy, 165
pole formularza zgoszenia bdu, 170
procedury postpowania, 175
segregacja bdw, 175
rednia ycia bdu, 166
tworzenie list pilnych zada, 165
wyszukiwanie blokw tekstu, 165
zestaw danych, 165
zestaw ustawie domylnych, 165
baza bdw Bugs DB, 165
baza bdw Mozilla Bugzilla, 169
bd 56859, 201
bd 77261, 201
czste, 146
integracji, 67
katalogowanie, 164
logiczne
typu off-by-one, 44
minimalne, 147
na stronach internetowych, 333
narzdzia ledzenia bdw Issue Tracker, 169
niewielkie, 147
okazjonalne, 146
rzadkie, 146
wykrywanie, 164
zgaszanie, 164
znaczne, 147
ycie bdu, 164, 177
sposoby rejestracji bdw, 178
bot
projekt Bots, 209
zakad i rozwinicie na potrzeby sieci, 209
Bot Chromebot, 321
Browser Integrated Test Environment, 211
Browser Integrated Testing Environment, 333
BrowserUX, 321
buforowa skadnia protokou, 63
bufory protokow, 63
Bug, 174
Buganizer, 113
BugsDB, 113
build, 54
build system, 72
build target, 54
buzz_client_tests, 94
C
C++ AddUrlFrontend, 74
canary, 42
Capability Maturity Model, 95
CC, 171
cel kompilacji, 54
biblioteka, 54, 55
binariw, 55
integrowanie, 55
plik testu, 54, 55
celno dziaania wyszukiwarki dla zestawu
wynikw, 205
centra komunikacyjne, 286
Certyfikowany w testach, 19, 95
korzyci, 97
kryteria programu, 102
nagradzajcy system punktowy, 101
najwiksze trudnoci, 103
opis programu, 98
pomys, 97
poziomy, 96, 98
projekty spadkowe, 103
waga projektu, 100
wprowadzenie w Google, 100
wskazwki podczas wprowadzania, 104
wymagania, 96
wywiad z twrcami programu, 97
change list, 66
Changed, 171
Changelists, 171
chodzenie za socem, 291
ChomeBot, 206
Chrome, 270
aplety Java, 330
aplikacje Flash, 330
Kup ksik Pole ksik
Chrome
automatyzacja interfejsu uytkownika, 273
badanie poprawnoci produktu od strony
interfejsu, 273
BITE, 333
bdy regresji, 273
czas, 329
do biaego rana, 329
dodatki, 329
filmy na stronach, 330
jzyki, 327
karty i okna, 329
kiepska okolica, 330
kompatybilno aplikacji, 272
konsola JavaScript, 330
meneder
zada, 330
zakadek, 328
motywy, 331
narzdzia dla programistw, 328, 330
O3D, 330
odtwarzanie plikw Flash, 134
okno incognito, 328
opcje sieciowe, 327
pobrane pliki, 328
podrczny pasek nawigacji, 328
poziomy dostpu, 327
przenoszenie danych z dysku przez chmur, 327
rozdzielenie profili, 331
rozmowa midzynarodowa, 327
rozszerzenia, 330, 331
RPF, 340
rzemielnik, 329
sposoby modyfikowania przegldarki, 331
sprawdzenie przenonoci, 327
strona motyww, 328
system operacyjny, 327
testowanie, 273
ustawienia, 328, 331
wasne, 331
Web, 338
wiele instancji, 330
wycieczki testowe, 325
wyprawa
do sklepu, 325
studenta, 326
wywietlanie rda, 330
zbadanie
funkcji Kopiuj i wklej, 327
moliwoci, 327
okna przegldarki, 328
zmiany sieci, 272
Chrome OS, 58, 273
automatyzacja w strukturach E2E, 320
Autotest, 319
dbao o jako, 317
gwna przegldarka, 320
harmonogram dziaa, 322
kana dystrybucji, 317
wprowadzenie, 320
laboratorium sprztowe, 320
osoby odpowiedzialne za prowadzenie testw
i obszary ich dziaania, 324
pakiet testw rcznych, 321
panel testowania, 318
partnerzy OEM, 319
plan testowania, 313
Chrome OS jako pierwotna platforma
przegldarki, 314
dostarczanie danych, 314
macierz automatyzacji testw sprztowych, 313
moliwo testowania i efekt mnonika, 314
narzdzia i testy o otwartym kodzie, 314
ocena ryzyka, 313, 315
umoliwianie szybkich zmian, 314
powizane dokumenty, 324
praca w penym obcieniu, 319
repozytoria przypadkw testowych, 318
sprzt, 322
stabilizacja, 319
szkielet wykonawczy, 319
testowanie menedera AppManager, 320
testy
dla opcji zasilania, 322
dla problemw sprztowych, 322
dugotrwae, 319
dzienne ostatniej dobrej wersji, 316
kompatybilnoci stron, 320
podstawowe w kolejnych wersjach
kompilacji, 315
rczne eksploracyjne, 321
rczne kontra automatyczne, 317
w przegldarce, 321
wersji przeznaczonej do wprowadzenia
na rynek, 316
Kup ksik Pole ksik
Skorowidz 351
udzia uytkownikw, 317
wirtualizacja, 318
wycieczki, 321
wyniki dziaania, 319
Chrome Web Store, 219
Chromebook, 221
chromium.org, 216
cigo systemu integracji, 90
CiW, 98
CKO, 192
Cloud Code Coverage, 287
committers, 65
common_collections_util, 93
Component, 171
crawling, 88
Create an AddUrlFrontend, 76
Created, 172
cross-talk, 110
cuke, 159
Customer Issue, 174
czas wykonywania testw, 88
czasowniki aplikacji, 133
D
Dang Hung, 265
deadlock, 110
defect-driven development, 116
definicje rozmiarw testw, 80
Depends On, 171
deweloperski kana dystrybucji, 43
do biaego rana, 329
dogfooder, 39, 154
dokumentacja
projektu, 60
cele dla czonkw zespou, 63
interfejsy i protokoy, 62, 63
inynier do spraw testowania
oprogramowania, 61
kompletno, 62
moment koczenia wstpnych prac, 60
poprawno, 62
projekt, 62
recenzowanie, 61, 62
spjno, 62
testowanie, 62
rodowiska testowego, 89
wersji, 79
DOM, 207
model obiektowy, 218
dopasowanie rozmyte, 338
droid-food, 267
drzewo zasobw, 105
Duplicate, 173
due testy, 44, 45, 83, 85
mocne i sabe strony, 85
pokrycie kodu, 87
wykorzystanie zasobw, 85
zakres dziaania, 83
dwadziecia procent czasu, 51, 57, 255
dwudziestoprocentowe prototypy, 58
dynamika
dziaa, 259
zespou, 259
dyrektor testw, 276
przyszo, 309
rozmowa
z dyrektorem testw w Google, 286
z dyrektorem w projektach Search i Geo, 277
z dyrektorem zespou inynierii
narzdziowej, 281
wymagania, 277
zadania, 276
dziesiciominutowy plan testowy, 151
E
Eclipse, 218
edytor ACE, 335
efekt mnonika, 314
elementy
o dokadnej zgodnoci, 219
eliminacja zbdnych testw
wytyczne, 196
Encyklopedia testw, 89
Engineering Productivity Group, 30
F
fake, 44, 47, 55
definiowanie, 77
mae testy, 87
testy integracyjne, 63
FakeAddUrlService, 76, 77
faszywe
funkcje obliczeniowe, 74
zgoszenie, 206
Kup ksik Pole ksik
fanty, 276
Feature Request, 174
Feedback, 293, 318
cel, 293
Fix later, 173
Fixed, 173
fixit, 99
flaga, 88, 89
FlexUnit, 248
Flux Capacitor, 222
Focus Area, 40
Found In, 172
funkcje
budujce ranking, 199
faszywe, 74
HandleAddUrlFrontendRequest, 74
Instant Pages, 211
najbliszy ssiad, 44
obsugi jzyka Java, 220
obsugujce zdarzenia w aplikacjach
internetowych, 74
pauzuj i popraw, 219
pomocnicze, 74
G
glina kompilacyjny, 69
globalna inynieria testowa, 290
Gmail, 258
bdy regersywne, 260
czas dziaania aplikacji, 260
gmail_server_test, 92
Google
analiza ryzyka, 139
Checkout, 219
CKO, 192
infrastruktura testujca, 309
kierowanie testami, 187
rola kierownika zespou testowego, 188
zarzdzanie zespoami testerw, 188
kultura testowania, 287
orodki obsugujce obszary geograficzne, 286
rodzaje stanowisk kierowniczych i
dyrektorskich, 189
dyrektor testw, 190
gwny kierownik techniczny, 189
gwny technik, 189
kierownik zespow inynierskich, 189
starszy dyrektor testw, 190
wewntrzne procesy rekrutacyjne, 191
inicjatywy strategiczne, 191
negocjacje, 191
recenzje i ocena dziaania, 191
technika, 191
zdolnoci komunikacyjne, 191
zunifikowany system katalogowania bdw, 176
Google App Engine, 229
Google Desktop, 193
Google Diagnostic Utility, 288
Google Docs, 126
Google Feedback, 176, 213, 318
algorytm klastrujcy, 176
Google Groups, 164
Google India, 286
Google Search, 198, 277
granice oglnego zasigu, 278
szczelno rozwizania, 279
testowanie, 278
testy zmian konfiguracji, 281
wspczynnik zgodnoci trafie
dynamiczny, 198
statyczny, 198
Google Sites, 130
Google Talk Labs Edition, 194
Google Test, 34
Google Test Analytics, 127, 131
analizy testowe, 223
przeksztacanie listy moliwoci w przebieg
testw, 227
w wersji otwartej, 341
waenie ryzyka w projektach czonych, 227
zadania, 229
Google Test Case Manager, 159
Google Testing Blog, 333
Google+, 139
moliwoci, 140
komentarze, 142
krgi, 141
ludzie, 141
powiadomienia, 141
profil, 140
strumie, 141
usuga Hangout, 141
wpisy, 142
zdjcia, 142
Kup ksik Pole ksik
Skorowidz 353
skadowe, 140
komentarze, 140
krgi, 140
ludzie, 140
powiadomienia, 140
profil, 140
strumie, 140
wpisy, 140
zainteresowania, 140
zdjcia, 140
waciwoci, 139
ekspreswna, 140
istotna, 140
atwa w obsudze, 140
prywatna, 140
rozwijalna, 140
spoeczna, 140
Google-food, 267
Green Brad, 291
grupa wydajnoci projektowej, 30
przydzia testerw do projektw, 40
przyszo, 303
GTA
czstotliwo wystpowania bdw, 145
bdy bardzo rzadkie, 145
bdy czste, 146
bdy okazjonalne, 146
bdy rzadkie, 146
GTCM, 159
Google App Engine, 164
interfejs programistyczny, 164
JSON, 164
liczby, 161
mechanizmy wewntrzne, 164
meneder przypadkw testowych, 162
stopie pokrycia testami, 162
H
Hajdarabad, 286
HandleAddUrlFrontendRequest, 73, 74
Harvester, 88
historia uytkownika, 138, 139, 153, 155
przygotowanie, 155
hooks, 247
http_reply, 73
http_request, 73
HUD, 212, 318
HYD, 287
Hynoski Joel, 270
I
infrastruktura
Amazon EC2, 205
badajca wartoci parametrw
charakteryzujcych dziaanie aplikacji, 290
dzielona
system testowania, 83
wykorzystanie testw, 83
kompilujca, 282
obliczeniowa
system integracji cigej, 91
SkyTap, 205
testowa, 47, 83
testujca, 282
kierunek rozwoju, 310
Matrix, 218
przyszo, 309
zewntrzna, 47
inicjatywa wasna pracownikw, 57
innowacje testowe i eksperymenty, 232
GTAC, 232
koncepcje, 233
przebieg eksperymentw, 235
Instant Pages, 211
integracja ciga, 284
interfejsy, 63
DOM, 194
TestScribe, 222
Internal Cleanup, 174
inynier do spraw testowania oprogramowania,
37, 38, 47, 49, 50
definicje rozmiarw testw, 80
dokumentacja projektu, 60
recenzja, 61
doczanie do zespou, 60
dwudziestoprocentowy projekt, 58
interfejs i protokoy, 63
kod buforowy, 63
kompilacja celw testw, 55
korzyci z rnych rodzajw testw, 84
odpowiedzialno za jako produktu, 65
planowanie automatyzacji, 64
taktyka, 64
Kup ksik Pole ksik
inynier do spraw testowania oprogramowania
praca, 50
nad cudzym kodem, 110
nad kodem, 50
predyspozycje do wykonywania zada ITO, 181
przyszo, 306
rola, 61
rozmowa kwalifikacyjna, 104
dopasowanie do kultury firmy, 111
kandydat doskonay, 111
ocena kandydatw, 106, 109, 110
ocena sposobu szukania rozwizania, 105
osoba przeprowadzajca rozmow, 112
przykad implementacji, 108
znaczenie pyta, 108
struktura w zespole, 59
system pracy
przykad, 70
wykonanie testu, 79
szersza perspektywa, 59, 61
rednie testy, 82
testowalno aplikacji, 65
testy, 50
funkcjonalne, 110
integracyjne, 64
strukturalne, 110
w strukturze organizacyjnej, 40
wczesny etap projektowania, 57
wsppraca z programistami, 56
wykorzystanie testw w infrastrukturze
dzielonej, 83
wymagania, 56
wywiad z programist narzdzi, 112
zadania, 56
inynier niezaleny, 309
inynier oprogramowania, 37, 38, 49, 56, 120
odpowiedzialno za jako produktu, 65
przykad aplikacji, 70
przyszo, 307
inynier testujcy, 38, 39, 49, 65, 119
awans, 252
dobr, 121
okrelanie poziomu ryzyka
wskazwki, 153
pocztkowy etap pracy, 121
predyspozycje do wykonywania zada IT, 182
przyszo, 308
rozmowa z kandydatem na stanowisko ITO, 179
wymagania, 122, 123
zaangaowanie w projekt, 120
zadania, 120
zakres obowizkw, 120, 122
zatrudnianie, 179
scenariusze rozmw z kandydatami, 179
szukanie rozwizania poredniego, 180
zmniejszenie wymaga
programistycznych, 179
inynieria testowania, 279
IO, 37, 49
Issue Tracker, 169
IT, 22, 38, 49, 119
ITO, 22, 37, 49, 119
a IT
predyspozycje do wykonywania zada IT, 182
predyspozycje do wykonywania zada
ITO, 181
rnice, 181
J
jako
a testy, 35
aplikacji, 304
inynierowie oprogramowania, 38
substytut, 303
systemu Chrome OS, 314
udzia uytkownikw, 317
w fazie projektu, 35
zapobiegliwo, 36
jednorodna platforma programistyczna, 53
jednorodno, 54
jzyk
specyfikacji wersji budowanej, 54
K
kana
droidw, 267
dystrybucji, 42
beta, 43
Chrome OS, 317
deweloperski, 43
kanarkowy, 42
Kup ksik Pole ksik
Skorowidz 355
RC, 43
testowy, 43
kanarkowy kana dystrybucji, 42
kierownik produktu, 306
kierownik projektu, 60
dokumentacja projektu, 60
kierownik testw
przyszo, 309
kierownik zespow inynierskich, 251
aktywne uczestnictwo w dziaaniach, 257
alokacja, 254
decydujce argumenty, 255
awans, 252
kompletowanie zespow, 261
nowe projekty, 255
odpowiednia dynamika dziaa, 259
odpowiedzialno, 257
optymalizowanie dziaa, 253
organizacja pracy zespou, 267
poznanie swoich ludzi, 253
poznanie swojego produktu, 252
puapki, 263
rola, 251
rozmowa
z Jamesem Whittakerem, 294
z kierownikiem testw, 291
z KZI projektu Chrome, 270
z KZI usugi Gmail, 258
rady dla kierownikw, 259
z KZI zespou Android, 265
swobodny przepyw pracownikw, 254
techniczna strona pracy, 261
wpyw, 256
wsppraca midzyzespoowa, 257
zadania, 252, 257
zakadanie zespou, 265
zasady testowania, 262
zdobywanie pracownikw i pomysw, 254
klasy
AddUrlFrontend, 72, 73
kod
buforowy, 63
testowy, 47
testw, 79
kodowanie
wpisy z bloga, 333
kolejki wysyania, 67, 68, 69, 290
kolejkowanie kodu, 67
kolejno testowania, 89
kompatybilno
aplikacji, 272
witryn, 316
kompilacje
cige, 67, 69, 290
przykady zalenoci wewntrz kompilacji, 92
kompilator, 54
bufora protokou, 72
konflikty, 89
KP, 60, 306
kukieka, 221
kultura pracy, 58
Kumar Ashish, 281
KZI, 251
L
laboratorium sprztowe, 320
Last modified, 172
library build target, 54
lista
celw i wynikw, 98
moliwoci, 138
akcja, 138
grupa moliwoci, 138
sposb formuowania, 138
zmian, 66, 78
dugo, 66
punkty kontrolne, 66
zotych, 68
LZ, 66
atwa automatyzacja, 23
czenie testw, 271
M
macierz automatyzacji testw sprztowych
Chrome OS, 313
mae testy, 44, 45, 80, 85
izolacja kodu, 81
konieczne symulacje, 81
Kup ksik Pole ksik
mae testy
pokrycie kodu, 87
zakres dziaania, 81
Mao Ted, 112
mapowanie, 107
MapReduce, 107
Mar Shelton, 277
Matrix, 113, 218
mechanizm
20%, 255
nasuchujcy, 247
Mehta Ankit, 258
memory leak, 110
metoda
AddUrl, 71
automatyzowania testw, 65
dopasowania rozmytego, 338, 339
rozwijania przez bdy, 116
WSM, 341
szczegowo, 341
szybko, 341
warto praktyczna, 342
wymowno, 342
mierniki ilociowe, 292
minimalizowanie ryzyka, 153
Mission Control, 307
modszy specjalista, 307
mock, 44, 47
mae testy, 87
testy integracyjne, 63
model
chodzenia za socem, 291
dojrzaego potencjau, 95
DOM
atrybuty rodzicw i dzieci, 219
Mondrian, 66
Mozilla Bugzilla, 169
moliwo testowania, 314
N
nadmiarowa praca, 333
nagroda koleeska, 53
najbliszy ssiad, 44
narzdzia
a oprogramowanie, 305
Autotest, 274
budowania i wykonywania testw, 79
diagnostyczne, 289
Google Diagnostic Utility, 288
HUD, 318
kontrolne, 69
lokalizujce, 283
o otwartym kodzie
Chrome OS, 314
oceniania stopnia pokrycia projektu testami, 288
pomiarowanie, widoczno i raportowanie, 283
programistyczne, 282
QualityBots, 336
RPF, 338
Selenium, 115
tworzenie, 285
w Chrome, 330
wpisy z bloga, 333
wykorzystujce mechanizm sprzenia
zwrotnego, 290
rdowe, 282
niwiarz, 88
Native Driver, 310
New, 173
Norwitz Neal, 97
Not feasible, 172
Not repetable, 173
Notes, 172
O
O due, 109
obliczenia w chmurze, 95
Obsolete, 173
obszary zainteresowania, 40
ocena ryzyka, 144, 315
Chrome OS, 313, 315
cele, 315
czstotliwo wystpowania bdw, 145
bdy bardzo rzadkie, 145
bdy czste, 146
bdy okazjonalne, 146
bdy rzadkie, 146
czynniki, 144
konsultacje, 148
dyrektorzy i wiceprezesi, 149
handlowcy, 149
kierownicy projektw, 149
programici, 148
zalety, 149
Kup ksik Pole ksik
Skorowidz 357
Test Analytics, 344
uwagi, 153
minimalizowanie ryzyka, 153
wpyw bdw na komfort pracy, 147
bd niewielki, 147
bd znaczny, 147
maksymalny, 147
minimalny, 147
zasig bdw, 145
ocenianie
jakoci caego internetu, 205
kodu, 65
ODW, 316
odznaki certyfikacji w testach, 95
off-by-one, 44
ograniczenia rodzajw testw, 85
ograniczenie ryzyka
stopie ograniczenia ryzyka, 150
ogromne testy, 83, 85
zakres dziaania, 83
okno incognito, 328
opracowywanie kodu
inynier do spraw testowania
oprogramowania, 50
organizowanie wykonywanych rcznie zada
testowych, 46
osoba kierujca pracami nad projektem, 60
osobliwo, 206
otwarta baza kodu, 52
otwarto kodu, 314
OZ, 40
P
Page View, 137
pakiet
automatyzujcy, 64
regresyjny, 55
testujcy, 64
panel testowania, 318
PAT, 69
peer bonus, 53
plan testowania, 124
dziesiciominutowy, 151
historia wprowadzania, 126
przypadki testowe, 128
system weryfikacji kodu, 125
systemu operacyjnego Chrome, 313
Test Analytics, 341
testy, 128
wymagania, 126
planowanie automatyzacji, 64
sposb przekazywania informacji o jakoci
kolejnych kompilacji, 65
szkielet automatyzujcy, 64
pliki
.jar, 221
addurl.pb.cc, 72
addurl.pb.h, 72
addurl.proto, 71
addurl_frontend.cc, 73
addurl_frontend_test, 78
addurl_frontend_test.cc, 74
AddUrlFrontend, 72
binarny, 55
common_collections_util, 93
testu, 55
youtube_client, 94
pocztek prac, 59
podleganie testom, 136
podzia rl, 36
inynier
do spraw testowania oprogramowania, 37
oprogramowania, 37
testujcy, 38
pokrycie kodu, 137, 288
pole formularza zgoszenia bdu, 170
Blokowanie, 171
Do wiadomoci, 171
Listy zmian, 171
Mierzone w wersj, 174
Odbiorca, 170
Ostatnie zmiany, 172
Postanowienia, 172
Priorytet, 172
Rodzaj, 174
Skadowa, 171
Status, 173
Streszczenie, 174
Szkodliwo, 173
Utworzono, 172
Uwagi, 172
Weryfikator, 174
Zaleny, 171
Zaczniki, 171
Kup ksik Pole ksik
pole formularza zgoszenia bdu
Zgoszone przez, 172
Zmiany, 171
Znaleziono w, 172
Zweryfikowana wersja, 174
pomiarowanie, widoczno i raportowanie, 283
pomniejsze projekty, 51
poprawianie testowania, 303
odpowiedzialno za prowadzenie testw, 307
przyszo
infrastruktury testujcej, 309
inynierw do spraw testowania
oprogramowania, 306
inynierw testujcych, 308
kierownikw i dyrektorw zespow
testujcych, 309
system pracy, 303
wnioski, 311
poziom jakoci, 199
poznanie
swoich ludzi, 253
swojego produktu, 252, 307
praca nad kodem, 50, 60
biblioteki, 52
dla platform systemowych, 53
budowanie nowych wersji kompilacji, 54
jedno repozytorium, 50
jzyk specyfikacji wersji budowanej, 54
kompilator, 54
nowe rozwizania, 52
ostrzejsze testy, 53
praktyki, 52
rozbienoci wynikajce ze rodowisk pracy, 53
sprawdzanie poprawnoci, 53
uzgodnienie interfejsw, 55
wsplny kod, 52
cechy, 52
zalenoci, 52
Priority, 172
procedury testowania, 29
Certyfikowany w testach, 95
innowacje produktw, 41
jako testy, 35
kultura pracy, 58
czenie pracy nad kodem i testowanie, 36
ograniczenie liczby pracownikw, 253
plan automatyzowania procesw testowych, 64
pynne i czste zmienianie zespow, 254
podzia rl, 36
pracownicy a liczba usug, 55
proces przygotowywania kodu, 65
prostota i jednorodno, 54
rodzaje testw, 43
struktura organizacyjna, 39
swobodne zmienianie zespow, 276
takie same rodowisko pracy i zestaw
narzdzi, 69
typowe przypadki, 71
uywanie wsplnych fragmentw kodu, 52
wprowadzanie czstych aktualizacji, 45
zunifikowany system budowania nowych
wersji kompilacji, 54
proces
pisania aplikacji
narzdzia, 51
repozytorium, 50
uzgodnienie interfejsw, 55
zoone usugi, 55
przygotowywania kodu, 65, 66
testowania
narzdzia nad oprogramowanie, 305
niedogodnoci, 304
rozdzielenie rl programistw i testerw, 304
Process, 174
profil ryzyka, 122
program
automatycznego testowania, 69
wyzwa testowych, 95
programista, 37
kontakt z uytkownikiem, 308
pracujcy nad funkcjami aplikacji, 49
testw, 49
uytkowy, 48, 49
zaangaowanie w kwestie testowania, 95
programowanie
w sytuacji idealnej, 47
kod testowy, 48
projekt, 62
automatyzacji stron korzystajcych
z JavaScript, 221
BITE, 211
dokadny opis bdu, 216
doczanie adresu URLdo raportu
o bdzie, 215
Kup ksik Pole ksik
Skorowidz 359
formularz, 214
informacje o systemie operacyjnym
i przegldarce, 215
kod HTML niepoprawnego fragmentu
strony, 214
przycisk Bug It, 214
rozwizywanie problemw, 212
segregowanie bdw, 214
zapis dziaa podjtych przez testera, 214
zgaszanie bdw, 213
zrzut ekranu, 214
BITE Web Test Framework, 222
ryzyko, 121
UX, 232
zaleny
zmiany, 94
zwrot z inwestycji, 121
projektanci testw, 309
projektowanie
w sytuacji idealnej
potrzeby uytkownika, 48
z uyciem testw, 37
prostota, 54
proto_library, 72
protokoy, 63
JSON, 164
SOAP, 164
prowadzenie darmowych testw, 230
schemat, 230
ocena bdw, 231
planowanie za pomoc GTA, 230
pokrycie testami, 230
segregowanie bdw i ich usuwanie, 231
testy eksploracyjne, 231
wdroenie nowej wersji i powrt do kroku 1,
231
zgaszanie bdw, 231
uywanie botw, 232
w sieci, 231
warunki, 230
przegld wydajnoci projektowej, 285
przegldarka
Chrome
Chrome Labs, 147
mechanizm automatycznej aktualizacji, 147
przycisk Odwie, 147
szkielet automatyzujcy SiteCompat, 209
Firefox, 208
WebKit, 206
przekadanie moliwoci na testy
wskazwki, 139
przesyanie raportw, 46
przewodnik po stylu programowania w C++, 66
przygotowanie testw, 79
przypadek
testowy, 124, 128, 139, 158
arkusz kalkulacyjny, 158
dokumentacja, 159
Google Test Case Manager, 159
powstawanie, 158
przygotowanie, 158
regresywny
automatyzacja, 217
Test Scribe, 159
zarzdzanie, 158
uytkowania, 138, 153
przyszo testw, 303
przyznawanie awansw, 257
PyAuto, 273
Python App Engine, 233
Q
QualityBots, 336
Amazon EC2, 336
frontend narzdzia, 336
interfejs, 336
panel kontrolny, 337
przykadowe wyniki uruchomienia, 337
R
raport
z testu pokrycia, 87
w chmurze, 88
zbiorczy, 251
RC, 43
recenzja kodu, 65
recenzowanie dokumentacji, 62
Record Playback Framework, 338
redukcja, 107
reguy
kompilowania
proto_library, 72
przedwysykowe, 66
przygotowywania kompilacji, 92
Kup ksik Pole ksik
release channel, 42
Remote Procedure Call, 71
Reported by, 172
repozytorium, 51
Issue Tracker, 169
kodw rdowych, 51
ostrzejsze testy, 53
Resolution, 172
roczne oceny pracownikw, 257
rodzaje testw, 43, 84
cele i ograniczenia czasu wykonywania, 85
ograniczenia, 85
rozmiar testu, 80, 84
korzyci z rnych rozmiarw testw, 84
rozmowa
kwalifikacyjna
na stanowisko inyniera testujcego, 183
z inynierem do spraw testowania
oprogramowania, 104
z dyrektorem testw w Google India Sujayem
Sahnim, 286
z dyrektorem testw w projektach Search
i Geo Sheltonem Marem, 277
z dyrektorem zespou inynierii narzdziowej
Ashishem Kumarem, 281
z inynierem testujcym Lindsay Webster, 237
baza danych bdw, 239
moment zakoczenia testw, 242
ocena stanu projektu, 238
okrelenie najwaniejszych skadowych
programu, 239
sprawdzanie skadowych aplikacji, 239
testowanie Google Sites, 240
testy automatyczne, 238
testy jednostkowe, 238
usuwanie usterek, 242
zestaw testw, 239
zrozumienie oglnej koncepcji, 238
z inynierem testujcym pracujcym przy
serwisie YouTube Apple Chow, 244
algorytmy losujce zawarto serwisu
YouTube, 249
bd arkusza stylw CSS, 248
gwny tester w Google, 246
koszty utrzymania i naprawiania testw, 250
najwikszy bd, 248
ocena procesu weryfikacji kandydatw
na stanowiska IT i ITO, 244
praktyki testowe stosowane w Google, 245
Selenium, 247
testowanie aplikacji Flash serwisu YouTube,
248
testy eksploracyjne, 246
z Jamesem Whittakerem, 294
z kierownikiem testw Bradem Greenem, 291
z KZI projektu Chrome Joelem Hynoskim, 270
z KZI usugi Gmail Ankitem Meht, 258
z KZI zespou Android Hungiem Dangiem, 265
z twrc aplikacji WebDriver, 114
rozszerzenie
bazy znanych bdw, 318
Google Feedback, 318
rozwizanie lunego wykonania, 219
RPC, 71
RPF, 218, 338
dziaanie na stronach internetowych, 340
ocena jakoci, 338
wyniki testowania, 339
Rufer Russ, 97
rywalizacja, 293
ryzyko, 144
ocena, 144
szacowanie na podstawie czstotliwoci
wystpowania bdw i ich zasigu, 145
zmniejszanie, 149
rzemielnik, 329
S
Sahni Sujay, 286
scenariusze przekrojowe, 122
Search, 277
Selenium, 115, 208, 217
serwery
VPN, 205
sesja przegldarki, 113
Severity, 173
shardowanie, 107
Sharing, 137
silnik WebKit, 169, 201
SiteCompat, 209
skrypty
automatyzujce WebDrive, 198
cigej kompilacji, 68
Kup ksik Pole ksik
Skorowidz 361
specyfikacja wersji testu, 79
sprawdzanie
dziaania pojedynczych moduw kodu, 80
dziaania wszystkich funkcji jako caoci, 83
jakoci dziaania, 289
stopnia zintegrowania, 81
wzajemnego oddziaywania ograniczonej
liczby moduw aplikacji, 81
stan zielony, 67
Status, 173
status oczytanych, 66
Stewart Simon, 114
stopie
oczytania, 66
ograniczenia ryzyka, 150
pokrycia kodu, 288
zintegrowania, 81
street-food, 267
Striebeck Mark, 97
struktura
organizacyjna, 39
nadzorujcy prac, 40
obszary zainteresowania, 40
wypoyczanie testerw, 41
w zespole, 59
kierownik projektu, 60
zespou, 251
Summary, 174
swobodne zmienianie zespow, 276
swobodny przepyw pracownikw, 254
symulacyjne implementacje interfejsw, 55
system
BITE UX, 222
budowania, 72
nowych wersji kompilacji, 54
Chrome, 220
Chrome OS, 219
funkcje pocze sieciowych, 236
integracji cigej, 90, 95
analiza zalenoci, 91
przerwanie testu, 91
zwyky, 91
kompilacji cigej, 68
ochrona, 68
kompilacji jednoczesnych, 92
kontroli wersji
lista zotych zmian, 68
Linux, 220
pracy
w Google, 303
testowania, 83
dowolna kolejno wykonywania, 89
uruchamiany z testowaniem, 47
szersza perspektywa, 61
szkielet
automatyzujcy, 64
automatyzujcy SiteCompat, 209
Record and Play, 219
Record and Playback, 218
Selenium, 220
testowy, 65
WebDrive, 220
sztuczny system, 64
cieka XPath, 199

parametry, 218, 219
cieka zalenoci, 93
rednie testy, 44, 45, 81, 85
infrastruktura, 82
pokrycie kodu, 87
symulowanie zewntrznych usug, 82
zakres dziaania, 82
T
tabela moliwoci, 137
para podgld strony - dzielenie, 138
podgld strony, 137
wartoci liczbowe, 137
tablica testw jednostkowych, 67, 69
tajne projekty, 310
Targeted To, 174
TDD, 37
techniki nagrywania, 46
Test Analytics, 131, 341, 342
kreator, 342
ocena ryzyka, 153
odnoniki do baz danych bdw
i przypadkw testowych, 344
okrelanie waciwoci projektu, 342
tabela oceny ryzyka, 343
Kup ksik Pole ksik
Test Analytics
Test Results, 344
wywietlanie
moliwoci projektu, 343
ocen ryzyka w tabeli zawierajcej spis
waciwoci i skadowych projektu, 343
test harness, 47
Test Scribe, 159
SOAP, 164
TEST_F, 76
test-driven design, 37
testerzy, 37
dobrowolni, 308
kontekst wystpienia bdu, 212
praca podczas przygotowywania aplikacji, 56
przydzia do projektw, 40
w Google, 297, 304
wewntrzni, 39, 154, 305
wpyw na ksztat produktu, 256
wypoyczanie, 41
zewntrzni, 235
testowalno, 65
testowanie oprogramowania
a jako oprogramowania, 35
a prace nad produktem, 35
cel, 303
cele testowanego systemu, 280
czynnik hamujcy, 33
dbanie o jako oprogramowania, 34
inicjatywa wasna pracownikw, 57
jedno repozytorium, 51
jednorodna platforma programistyczna, 53
may zesp testujcy, 34
ograniczenie liczby pracownikw, 253
podwjne sprawdzenie sprawnoci
programistw, 39
pokrycie kodu, 87
relacje funkcji, 44
rozwizania dostpne w chmurze, 310
scenariusze
faktycznego uytkowania, 44
przekrojowe, 122
sposoby, 32
stabilny rozwj aplikacji, 43
testowanie wieloosobowe, 291
w Google, 30, 303
w tempie i na skal Google, 90
wskazwki do przygotowania narzdzia, 114
wyniki Google, 33
z poziomu sieci, 310
z punktu widzenia uytkownika, 38
z uwzgldnieniem potrzeb uytkownika, 119
zapobieganie wystpowaniu bdw, 36
zautomatyzowane procedury, 46
zesp, 50
zmiany w Google, 292
zwikszenie wykorzystania dobrych procedur, 41
Testowanie w toalecie, 99
testowanie w trybie utrzymania, 193
przykad Google Desktop, 193
testowy kana dystrybucji, 43
testy
automatyczne, 46, 65, 264, 267
cele i ograniczenia czasu wykonywania, 85
cuke, 159
czue na wprowadzone zmiany, 93
dla listy zmian, 66
dokumentacja, 269
dostarczanie danych, 314
due, 44, 83, 122
ograniczenie, 85
pokrycie kodu, 87
zakres dziaania, 83
dymne, 194
dzienne
ostatniej dobrej wersji, 316
eksploracyjne, 137, 153, 156, 198, 204, 268
funkcjonalne, 110
globalne, 83
infrastruktura zewntrzna, 47
integracyjne, 81
na wczesnym etapie prac, 64
jako funkcja programu, 55, 56
jednostkowe, 80
tablica, 67
jzyk testw, 310
konflikty, 89
korzyci z rnych rodzajw testw, 84
likwidacja przywizania do konkretnych
zasobw, 89
Kup ksik Pole ksik
Skorowidz 363
logika testw, 217
mae, 44, 80, 122
izolacja kodu, 81
konieczne symulacje, 81
ograniczenie czasu, 85
pokrycie kodu, 87
w rodowiskach prbnych, 44
zakres dziaania, 81
niedeterministyczne, 86
niezaleno, 88
o otwartym kodzie
Chrome OS, 314
obcienia, 264
odpowiedzialno za prowadzenie, 307
ogromne, 83
zakres dziaania, 83
optymalizacja liczby testw po zmianie, 94
pierwszy przebieg testw, 208
podstawowe
w kolejnych wersjach kompilacji, 315
pokrycia, 87
prowadzenie darmowych testw, 230
przekrojowe scenariusze, 45
przygotowanie, 79
przyszych funkcji, 47
regresywne, 153, 198, 204
rczne, 46, 153, 204, 280
kontra automatyczne, 317
rozwaga, 268
zautomatyzowane procedury, 46
rozmiary, 80
sens stosowania, 79
specyfikacja wersji, 79
strukturalne, 110
systemowe, 83
rednie, 44, 81, 122
infrastruktura, 82
pokrycie kodu, 87
symulowanie zewntrznych usug, 82
zakres dziaania, 82
testowanie w trybie utrzymania, 193
w fazie eksperymentalnej, 58
w przegldarce, 321
wersji przeznaczonej do wprowadzenia
na rynek, 316
wewntrzne, 305
wielokrotne, 139
wieloosobowe, 156, 204
korzyci, 156
trudnoci, 157
wykorzystanie
w infrastrukturze dzielonej, 83
zasobw, 85
wymagania stawiane czasom wykonywania, 88
ToTT, 99
tworzenie
kodu, 66
oprogramowania, 304
proces tworzenia, 304
Type, 174
U
udzia uytkownikw
Chrome OS, 317
udzielajcy si, 65
uruchomienie
pod penym obcieniem, 316
usuga
zdalnego wywoania procedury, 71
UX, 313
uytkownik
z grupy dogfooder, 154
V
Verified, 174
Verified In, 174
Verifier, 174
Verifier assigned, 173
Vevo, 246
VPN, 205
W
warto testowania, 305
warunek
kolejnoci testowania, 89
niezalenoci testw, 88
Kup ksik Pole ksik
Wave, 116
wczesna wersja towaru, 42
dwudziestoprocentowy prototyp, 58
eksperymentowanie, 58
testerzy, 58
zachowawczo, 58
WebDrive, 198
WebDriver, 114, 208
WebKit, 169
wersja
beta, 42, 43
deweloperska, 43
kanarkowa, 42, 210
kompilacji, 54
testowa, 43
weryfikacja
automatyczna, 44
bdw o priorytecie P0, 316
rozwijanej aplikacji, 128
scenariuszy, 316
Wi-Fi, 235
Will not fix, 173
wirtualizacja, 318
Works as intended, 173
wpisy z bloga, 333
wpyw, 256
roczne oceny pracownikw, 257
wprowadzanie czstych aktualizacji, 45
wrapper, 107
WSM, 341
wsplny kod, 52
cechy, 52
funkcje a rnice midzy platformami, 53
nowe rozwizania, 52
rozbienoci wynikajce ze rodowisk pracy, 53
sprawdzanie poprawnoci, 53
zalenoci, 52
wspdzielona biblioteka
zmiany, 93
wsppraca midzyzespoowa, 257
wstrzykiwanie
bdw, 63
skryptu JavaScript, 207
wszechstronna automatyzacja, 64
WTF, 222
wycieczki testowe dla Chrome, 325
sugerowane obszary prowadzenia bada, 328
zastosowanie, 328
do biaego rana, 329
nieciekawe dzielnice przegldarki, 330
zastosowanie, 327
rzemielnik, 329
narzdzia w Chrome, 330
zastosowanie, 329
ustawienia wasne, 331
sposoby modyfikowania przegldarki, 331
wyprawa do sklepu, 325
zastosowanie, 326
wyprawa studenta, 326
zastosowanie, 326
wykonywanie testu, 79
infrastruktura, 79
losowo, 89
system Google, 84
rodowisko, 88
wykrywanie opnie w dziaaniu wersji
produkcyjnej, 290
wymagania testowe projektw, 88
wyprawa
do sklepu, 325
studenta, 326
wywiad
z programist narzdzi, 112
z twrcami programu Certyfikowany w
testach, 97
Y
YouTube, 246
Ads, 247
Watch, 246
youtube_client, 94
Kup ksik Pole ksik
Skorowidz 365
Z
zachowawczo, 58
zalenoci
cieka, 93
wewntrz kompilacji, 92
zamraanie kodu, 67
zdalne programowanie w parach, 284
zdobywanie pracownikw i pomysw, 254
zesp
GEO, 216
inynierii narzdziowej, 282
grupy narzdzi, 282
ocena projektu, 283
projekty eksperymentalne, 283
testujcy, 30, 34
Chrome OS, 317
fanty, 276
kod, 51
podzia rl, 36
poza zespoem programistw, 305
wsppraca, 278
zadania, 314
wydajnoci projektowej, 286
zestaw moliwoci
przeksztacanie w histori uytkownika, 138
zewntrzna maszyna wirtualna, 208
zoone usugi, 55
zmiany
odmiana regresywna, 203
w projekcie zalenym, 94
we wspdzielonej bibliotece, 93
zmienianie zespow, 254
zmniejszanie ryzyka, 149
procedury, 150
kod wartowniczy, 150
narzdzia, 150
okrelenie bezpiecznej cieki
postpowania, 150
przypadki testw regresywnych, 150
testy, 150
znacznik
IFRAME, 203
o zblionej zgodnoci, 219
niwiarz, 88
ycie bdu, 164
Kup ksik Pole ksik
Kup ksik Pole ksik

Teopgo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Teopgo

Uploaded by

Copyright:

Available Formats

Tytu oryginau: How Google Tests Software

Tumaczenie: Julia Szajkowska

cieka XPath, 199

You might also like