Testowanie oprogramowania w praktyce

Adam Roman, Karolina Zmitrowicz

Uzyskaj dostęp

Zakup książkę

ISBN/ISSN:

978-83-01-19754-4

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2017

Liczba stron:

256

XML:ISBN/ISSN:

ONIX MARC21

Bibliografia:

Roman, Adam; Zmitrowicz, Karolina. Testowanie oprogramowania w praktyce. Red. . Warszawa: Wydawnictwo Naukowe PWN, 2017, 256 s. ISBN 978-83-01-19754-4

Bibliografia refWorks:

RT Book, Whole

SR Electronic(1)

A1 Roman, A.

A1 Zmitrowicz, K.

T1 Testowanie oprogramowania w praktyce

PB Wydawnictwo Naukowe PWN

PP Warszawa

YR 2017

SN 978-83-01-19754-4

Bibliografia BibTex:

@Book{ 187407, author = "Roman, Adam and Zmitrowicz, Karolina", editor = "", title = "Testowanie oprogramowania w praktyce", publisher = "Wydawnictwo Naukowe PWN", year = "2017", address = "Warszawa", isbn = "978-83-01-19754-4" }

Bibliografia endNote:

TY - BOOK

AU - Roman, Adam

AU - Zmitrowicz, Karolina

ED -

TI - Testowanie oprogramowania w praktyce

PB - Wydawnictwo Naukowe PWN

CY - Warszawa

PY - 2017

SN - 978-83-01-19754-4

ER -

Netografia (standard APA):

Roman, Adam; Zmitrowicz, Karolina. Testowanie oprogramowania w praktyce [baza danych online] Warszawa: Wydawnictwo Naukowe PWN, 2017 [dostęp: 22 07 2024]. Dostęp w Ibuk Libra: https://libra.ibuk.pl/reader/testowanie-oprogramowania-w-praktyce-adam-roman-karolina-187407.

testowanie oprogramowania, oprogramowanie, inżynieria jakości, testowanie, projekty testowe, testowanie sprzętu, testowanie infrastruktury

Drugi tom niezwykle życzliwie przyjętej przez Czytelników serii Testowanie oprogramowania w praktyce to kontynuacja idei opisywania przez praktyków – dla praktyków – rzeczywistych wyzwań zawodowych w dziedzinie inżynierii jakości oprog...

Więcej

ISBN/ISSN:

978-83-01-19754-4

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2017

Liczba stron:

256

XML:ISBN/ISSN:

ONIX MARC21

Przedmowa 12
Karolina Zmitrowicz, Adam Roman12
Część I. Organizacja i procesy16
1. Połączenie dwóch światów. Zmiany w organizacji zarządzania kontrolą jakości w warunkach połączenia firm18
Adam Romanowicz18
1.1. Wstęp18
1.2. Opis przypadku19
1.2.1. Cele przejęcia firm19
1.2.2. Charakterystyka firm kupujących20
1.2.3. Charakterystyka firm kupowanych20
1.2.4. Główne wyzwania z punktu widzenia firmy kupującej20
1.2.5. Główne wyzwania z punktu widzenia firmy kupowanej20
1.2.6. Główne wyzwania z punktu widzenia przejmowanych klientów21
1.2.7. Główne wyzwania z punktu widzenia architekta systemu21
1.2.8. Główne wyzwania z punktu widzenia inżynierii testów21
1.3. Skalowanie systemu22
1.3.1. Cel22
1.3.2. Opis problemów22
1.3.3. Faza 0 – stan testów niefunkcjonalnych po przejęciu firmy22
1.3.4. Faza 0 – wyniki23
1.3.5. Faza 0 – wnioski23
1.3.6. Faza 1 – pierwsze podejście do wprowadzenia skutecznych praktyk inżynieryjnych23
1.3.7. Faza 1 – wyniki24
1.3.10. Faza 2 – wyniki25
1.3.8. Faza 1 – wnioski25
1.3.9. Faza 2 – dalszy rozwój testów obciążeniowych25
1.3.11. Faza 2 – wnioski26
1.3.12. Faza 3 – dalszy rozwój i wnioski26
1.3.13. Wnioski końcowe26
1.4. Zarządzanie błędami28
1.4.1. Opis przypadku28
1.4.2. Perspektywa firmy kupionej28
1.4.3. Perspektywa firmy kupującej29
1.4.4. Podjęte kroki wewnątrz organizacji29
1.4.5. Perspektywa klienta29
1.4.6. Podjęte kroki dotyczące współpracy z klientem30
1.4.7. Wnioski30
1.5. Wartość testów eksploracyjnych31
1.5.1. Połączenie dwóch podejść32
1.5.2. Wnioski32
1.6. Nowy tryb pracy z klientem w obszarze testów33
1.6.1. Opis problemu33
1.6.2. Cel33
1.6.3. Podjęte działania33
1.6.4. Wnioski34
1.7. Zakończenie procesu przejęcia firmy35
1.7.1. Opis problemu35
1.7.2. Zatrzymanie się w połowie drogi35
1.7.3. Jak skutecznie zakończyć proces przejęcia firmy36
O autorze37
2. Trudna współpraca z klientem38
Bartłomiej Prędki, Karolina Zmitrowicz38
2.1. Wstęp38
2.2. Punkt widzenia dostawcy oprogramowania39
2.3. Rodzaje testów przeprowadzanych przez klienta40
2.4. Wady i zalety przeprowadzania testów przez zespół klienta42
2.4.1. Wady42
2.4.2. Zalety44
2.5. Zasady współpracy z zespołem klienta45
2.6. Studium przypadku47
2.6.1. Podejście do testów47
2.6.2. Środowiska testowe48
2.6.3. Organizacja pracy zespołów testerskich50
2.6.4. Wyniki54
2.7. Podsumowanie55
O autorach56
3. Zabezpieczenie środków budżetowych na rozbudowę zespołu testowego58
Maciej Chmielarz58
3.1. Wyzwanie58
3.2. Budżet nie jest z gumy59
3.3. Testowanie nie jest oczywiste59
3.4. Dobre praktyki nie przekonują61
3.5. Zastosowanie nie jest jasne62
3.6. Jest rola do spełnienia63
3.7. Efekt końcowy65
O autorze66
Część II. Testowanie systemów specyficznych68
4. Powiedz to głośno – jak skutecznie wprowadzić użyteczne usprawnienia w aplikacji70
Aleksandra Pirek, Aleksandra Sasin70
4.1. Charakterystyka projektu i problemu do rozwiązania70
4.2. Problemy, przed którymi stanęłyśmy73
4.2.1. Od czego wszystko się zaczęło73
4.2.2. Wiecznie chodzi o czas73
4.2.3. Budżet?74
4.2.4. Zespół74
4.3. Nasza historia75
4.3.1. Aplikacja webowa75
4.3.2. Stara aplikacja mobilna75
4.3.3. Nowa aplikacja mobilna – Android76
4.3.4. Raporty i wykresy76
4.4. Podejścia, techniki i technologie77
4.4.1. UX (ang. user experience) a użyteczność (ang. usability)77
4.4.2. Techniki testowania użyteczności78
4.5. Przebieg badania użyteczności79
4.5.1. Przygotowanie do testów – plan79
4.5.2. Lista kontrolna80
4.5.3. Zdefiniowanie person – rzecz z pogranicza projektowania i testów użyteczności83
4.5.4. Rekrutacja użytkowników88
4.5.5. Przygotowanie scenariuszy testowych93
4.5.6. Komunikacja mailowa96
4.5.7. Oświadczenia97
4.5.8. Przygotowanie obserwatorów98
4.5.9. Think Aloud (powiedz to głośno) – sesja z użytkownikiem98
4.5.10. Role w testach użyteczności100
4.5.11. Zebranie informacji zwrotnej po zakończonej sesji - ankiety101
4.5.12. Wnioski i zalecenia105
4.5.13. Spotkanie z biznesem108
4.6. Nasze rozwiązanie111
4.5.14. Wprowadzenie zmian111
4.6.1. Testy użyteczności aplikacji webowej112
4.6.2. Testy użyteczności aplikacji mobilnej113
4.6.3. Testy użyteczności na prototypach i makietach115
4.7. Wynik podjętych działań116
4.8. Aplikacja webowa118
4.9. Aplikacja mobilna118
4.10. Raporty i wykresy120
4.11. Podsumowanie121
O autorkach126
5. Umysł testujący: studium przypadków mobilnych128
Aleksandra Kornecka128
5.1. Wstęp – dlaczego powstał ten rozdział i dlaczego warto go przeczytać128
5.2. Charakterystyka projektów mobilnych oraz częste typowe problemy spotykane w takich projektach132
5.3. Podejście, które odpowiada na problemy oraz pomaga zapewnić jakość projektu mobilnego144
5.4. Teoria Marra – przetwarzanie informacji wzrokowej145
5.5. Teoria Gestalt – sposób postrzegania elementów widoku147
5.6. Teoria Jamesa J. Gibsona – oferty (afordancje) błędów ukryte w aplikacji148
5.7. Znajomość gestów natywnych dla danego systemu149
5.8. Wynik kognitywistycznego podejścia do testowania152
5.9. Wnioski i rekomendacje153
5.10. Aneks – testerska pomocnicza lista kontrolna154
O autorce156
Część III. Testowanie sprzętu i infrastruktury158
6. Testowanie sprzętu 160
Adam Stankiewicz160
6.1. Wprowadzenie160
6.2. Koncept, dokumentacja, przygotowania do testowania161
6.3. Poziomy testów163
6.3.1. Testowanie modułowe163
6.3.2. Testowanie początkowe – smoke test164
6.3.3. Testowanie integracyjne165
6.3.4. Testowanie weryfikacyjne169
6.3.5. Testowanie długoterminowe176
6.3.6. Testowanie równoległe integracyjno-weryfikacyjne179
6.4. Typy testów180
6.4.1. Testy manualne180
6.4.2. Testy automatyczne181
6.5. Techniki testowania182
6.5.1. Techniki oparte na specyfikacji (czarnoskrzynkowe)182
6.5.2. Techniki oparte na strukturze (białoskrzynkowe)183
6.5.3. Techniki oparte na usterkach183
6.6. Rodzaje testów184
6.5.4. Techniki oparte na doświadczeniu184
6.6.1. Testy wydajnościowe184
6.6.2. Testy obciążeniowe185
6.6.3. Testy przeciążające185
6.7. Proces testowy186
6.7.1. Planowanie testów186
6.7.2. Zarządzanie testami187
6.7.3. Kryterium zakończenie testów i ich ocena188
6.8. Wnioski189
6.7.4. Testowanie kolejnych wersji sprzętu189
O autorze193
7. Testowanie nowej technologii sieci komórkowej194
Ewa Marchewka, Wojciech Anzel194
7.1. Opis przypadku194
7.2. Problemy komunikacyjne i kulturowe195
7.2.1. Problemy z przekazywaniem wiedzy – szkolenie nowego zespołu195
7.2.2. Problemy podczas współpracy w wielonarodowościowym zespole: różnice kulturowe197
7.3. Problemy procesowe200
7.3.1. Proces dostarczania oprogramowania201
7.3.2. Zmiana produktu i narzędzi201
7.3.3. Współpraca z bliźniaczą organizacją202
7.3.4. Rola testera w zespole202
7.4. Problemy młodej organizacji i produktu204
7.4.1. Nowy zespół204
7.4.2. Problemy ze sprzętem205
7.4.3. Optymalizowanie testów w środku wydania206
7.4.4. Automatyzacja testów207
7.5. Analiza końcowa209
7.5.1. Jakość produktu209
7.5.2. Wnioski co do automatyzacji210
7.5.3. Czynnik ludzki210
7.5.4. Niedojrzałość sprzętu210
7.6. Podsumowanie211
O autorach212
Część IV. Metody i techniki214
8. BDD i Continous Integration w projekcie – korzyści, problemy i rozwiązania216
Rafał Nazwalski216
8.1. Wstęp216
8.2. Charakterystyka projektu – dlaczego Behavour Driven Development?216
8.3. Korzyści z BDD i CI219
8.4. Problemy z wdrożeniem BDD. Rola utrzymania testów222
8.5. Sposoby powrotu na właściwy tor230
8.6. Wnioski231
O autorze233
9. Automat do automatów, czyli jak wygenerować kod w kilka sekund 234
Natalia Krawczyk-Grzegorzewicz234
9.1. Wprowadzenie234
9.2. Automatyzacja tworzenia kodu235
9.3. Podsumowanie253
O autorce255

1.POŁĄCZENIEDWÓCHŚWIATÓW.ZMIANYWORGANIZACJIZARZĄDZANIAKONTROLĄ...

wykorzystywanydosprawdzeniasystemuponaprawiebłędów.Kosztinwestycjiwpierw-

sząfazębyłporównywalnyzkosztemwykonaniatestówopisanychwfazie0.

1.3.8.Faza1–wnioski

Zewzględunapresjęczasuorazograniczeniasystemuzdecydowanosięnarozwiąza-

nieniedokońcastabilneitrudnewutrzymaniu,jednakstosunkowotanie.Ostatecz-

nieróżnicamiędzykosztemnapisaniatestówaichutrzymaniembyłanatyleduża,

żełatwiejbyłousunąćproblematycznetestyizastąpićjenowymi,zamiastinwestować

wichpoprawianie.

Szybkoznalezionopoważnebłędy,coumożliwiłosprawnerozpoczęciepracnadana-

liząipoprawąsystemuwceluskalowaniago.Pookresie3–6miesięcytestytenieznaj-

dowałyjużnowychbłędówisłużyłygłówniesprawdzaniu,czystansystemusięnie

pogarsza.Zewzględunawspomnianewcześniejwadytegorozwiązania,jakipostęp

wzmianacharchitektonicznychsystemu,którepozwoliłynazmianępodejścia,postano-

wionozrezygnowaćzdalszegorozwojutychtestów.Nieoznaczato,żeichwykonywanie

byłobłędem.Zuwaginawszystkieokolicznościbyłotonajlepszerozwiązaniewdanym

czasieiwarunkachorazprzyniosłoefektywiększeniżspodziewane.Natomiastzpew-

nościąnienależyrozważaćtegopodejściajakoostatecznego.

1.3.9.Faza2–dalszyrozwójtestówobciążeniowych

Gdyuzyskanopierwszepomyślnerezultatywrozdzieleniuwarstw(wciążniepełne)oraz

utworzonoserwisyumożliwiającedostępdosystemuponiżejwarstwyGUI,pojawiły

sięnowemożliwości.Przedewszystkimdałotomożliwośćodrzuceniaciężkiegoidro-

giegonarzędzia,jakimjestLoadRunner,narzeczwłasnejplatformyprogramistycznej

(ang.framework),którawykorzystywaławszystkiedostępneinterfejsywceluwykona-

niatestów.Efektjednoczesnychtestównawieluinstancjachuzyskanoprzeznapisanie

agentanawzórtegozLoadRunnera,ztąróżnicą,żewewnętrznerozwiązaniebyło

wpełnikompatybilnezplatformąprogramistyczną.

1.3.10.Faza2–wyniki

Inwestycjawstworzeniewłasnegorozwiązaniawpełnikompatybilnegoztestowanym

systememzaowocowałapowstaniemelastycznegorozwiązaniazdużympotencjałem

dalszegorozwoju.Dałotomożliwośćwykorzystaniategonarzędziadotestowaniasys-

temównapisanychwtejsamejtechnologii.Głównąwadąbyłpoczątkowykosztstwo-

rzeniasamejplatformyorazkosztnapisaniatestówzpodziałemnawarstwywcelu

obniżeniakosztówpóźniejszegoutrzymania.Rozwiązanietojestcałyczasskutecznie

Brak wyników

Testowanie oprogramowania w praktyce

Treść książki

Znajdź bibliotekę blisko siebie, i uzyskaj dostęp do ebooka w systemie IBUK Libra