Planowanie jakości

Obecny rynek, nie tylko usług IT, przykłada dużą wagę do jakości. O jakości mówi się głośno, akcentując jej znaczenie w osiągnięciu satysfakcji klienta oraz sukcesu produktu. Oceniając produkty, stwierdzamy „to jest (nie jest) dobrej jakości”, „oczekuję wyższej jakości” itp. Intuicyjnie rozumiemy znaczenie pojęcia „jakość”, choć nierzadko mamy problemy z podaniem definicji tego terminu. Zanim przejdziemy do planowania jakości w projekcie, warto zdefiniować samo pojęcie jakości.

Istnieje wiele definicji jakości, wśród których najbardziej popularne są następujące:

  • „Jakość to stopień, w jakim zbiór inherentnych właściwości spełnia wymagania.” wg ISO 9000:2001.
  • „Jakość jest to pewien stopień doskonałości.” Platon.
  • „Jakość to zgodność z wymaganiami.” Crosby.

Definicje Platona oraz Crosby’ego wydają się prostsze, w definicji ISO wątpliwości może budzić użycie słowa „inherentny”. „Słownik wyrazów obcych i zwrotów obcojęzycznych“ Kopalińskiego  definiuje to słowo jako „tkwiący w czymś w istocie, strukturze, zasadniczym charakterze czegoś, w naturze, w ustalonych obyczajach; nieodłączny od”. Inherencja oznacza cechę nierozerwalnie związaną z danym pojęciem; cechę, która przesądza o istocie i naturze produktu, bez której produkt nie byłby tym, czym jest.

 

Więcej na stronie IT.PWN.pl >>

Testowanie CRUD

CRUD to czarnoskrzynkowa technika projektowania testów związana z przetwarzaniem danych. Polega na tworzeniu przypadków testowych na podstawie śledzenia cyklu życia danych w systemie. W artykule opisana została podstawowa wersja metody, a także jej rozszerzenia, ponieważ w rzeczywistych projektach najprostsze podejście CRUD może okazać się niewystarczające. Zapraszamy do lektury rozdziału z książki „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”, która trafi do Państwa rąk już w maju.

Opis metody

Akronim CRUD pochodzi od czterech angielskich słów: create, read, update oraz delete, czyli: stwórz, czytaj, uaktualnij, skasuj. Technika testowania CRUD dotyczy danych. Jest szczególnie pomocna w systemach bazodanowych oraz w aplikacjach, których istotną funkcjonalnością jest przetwarzanie danych. Operacje CRUD spotkać można prawie we wszystkich systemach. Na portalu społecznościowym możemy stworzyć swoje konto, dodać inną osobę do znajomych, usunąć ją z kontaktów, odczytać listę znajomych, zmodyfikować swoje dane itp. W każdej bazie danych podstawowe operacje to CREATE/INSERT, SELECT, UPDATE, DELETE.

Metoda CRUD polega na śledzeniu cyklu życia jakiejś danej, od momentu jej stworzenia do usunięcia. Jest to w pewnym sensie czarnoskrzynkowy odpowiednik białoskrzynkowej metody testowania przepływu danych. W metodologii TMap [117] technika ta nazywa się testowaniem cyklu danych (ang. data cycle test).

Systematyczne podejście CRUD wymaga stworzenia tzw. macierzy CRUD (ang. CRUD matrix), a następnie wyprowadzenia na jej podstawie przypadków testowych. Macierz CRUD może być elementem projektu systemu (i wtedy nie musimy jej sami tworzyć) lub może być wyprowadzona na podstawie specyfikacji funkcjonalnej. Określa ona, w których miejscach systemu jakie operacje na danych są możliwe do wykonania. W wierszach macierzy występują dane (np. poszczególne zmienne, obiekty itd.), natomiast cztery kolumny odpowiadają czterem podstawowym operacjom: C, R, U i D. W poszczególnych polach macierzy umieszcza się elementy systemu (np. ekrany), w których można wykonać określoną operację na określonej danej. Przykład macierzy CRUD jest pokazany na rys.

macierzC

Rysunek 1. Macierz CRUD

Zmienna id może być stworzona w miejscu E1. Miejscem może być np. ekran tworzenia nowego użytkownika. Zmienna id może być odczytana w dwóch miejscach: E2 oraz E3 i skasowana w E1. Zmiennej id nie da się aktualizować (bo np. jest unikalnym, niemodyfikowalnym kluczem). Zarówno imię, jak i nazwisko mogą być stworzone w E2 oraz odczytane i aktualizowane w E4. Zmienna wiek może być stworzona w E3 i aktualizowana w E4. Zmiennych nazwisko, imię i wiek nie można skasować (bo np. podlegają archiwizacji). 

Mając stworzoną macierz CRUD, możemy przystąpić do tworzenia przypadków testowych. W najprostszej formie są one po prostu przekształconą macierzą CRUD, w której z każdym miejscem w systemie związany jest jeden przypadek testowy. Przypadki dla macierzy z rys.1. zostały pokazane w tabeli Tabela 8.1.

Tabela 8.1. Przypadki testowe wyprowadzone z macierzy CRUD

 

PT1

PT2

PT3

PT4

Warunek wstępny

E1

E2

E3

E4

Akcja 1

Stwórz id

Stwórz nazwisko

Stwórz wiek

Odczytaj nazwisko

Akcja 2

Usuń id

Stwórz imię

Odczytaj id

Odczytaj imię

Akcja 3

 

Odczytaj id

 

Aktualizuj nazwisko

Akcja 4

 

 

 

Aktualizuj imię

Akcja 5

 

 

 

Aktualizuj wiek

 

Przypadki testowe opisują czynności do wykonania w każdym z miejsc systemu. Na przykład PT3 polega na tym, że gdy znajdujemy się na ekranie E3, to najpierw tworzymy zmienną wiek, a następnie odczytujemy id

W tabeli nie opisaliśmy oczekiwanych wyników, gdyż w podejściu CRUD zwykle są one definiowane w naturalny sposób: jeśli akcja polega na stworzeniu obiektu, oczekiwanym wynikiem jest stworzenie tego obiektu itd.

Rozszerzenie metody

W poprzednim podrozdziale opisaliśmy bardzo prostą wersję metody CRUD. W rzeczywistych projektach takie podejście może nie wystarczać. Można rozważać następujące rozszerzenia CRUD:

  • uwzględnienie kolejności wykonywania operacji;
  • uwzględnienie związków ilościowych pomiędzy operacjami a danymi;
  • rozważenie tzw. pytań reporterskich w stosunku do operacji (kto, co, gdzie, kiedy, dlaczego, jak, jak dużo?).

Pierwsze rozszerzenie uwzględnia kolejność wykonywania operacji w ramach danego przypadku testowego. Na przykład dla przypadku PT2 z tabeli Tabela 8.1 możemy najpierw stworzyć imię, potem odczytać id, a na końcu stworzyć nazwisko. Każdy przypadek można zatem rozbić na kilka „podprzypadków” testowych, zawierających ten sam zbiór operacji, ale w różnej kolejności. Takie podejście może jednak spowodować eksplozję liczby testów[1].

W drugim rozszerzeniu każda operacja może być wykonana na kilka sposobów, z uwzględnieniem relacji ilościowych pomiędzy operacjami a obiektami. Sposoby te są opisane w tabeli Tabela 8.2.

Tabela 8.2. Różne realizacje możliwych operacji CRUD

Operacja

Możliwe realizacje

Create

  • Stwórz jedną, nową instancję danej
  • Stwórz instancję danej będącą duplikatem innej danej
  • Stwórz więcej niż jeden element naraz (jeśli to możliwe)

Read

  • Odczytaj jeden element
  • Odczytaj więcej niż jeden element
  • Odczytaj element, który nie istnieje
  • Odczytaj elementy w określonej ilości lub formacie (np. posortowane, przefiltrowane, pasujące do określonego wzorca, wszystkie, zadaną liczbę rekordów itp.)

Update

  • Aktualizuj jeden element
  • Aktualizuj więcej niż jeden element
  • Aktualizuj elementy pasujące do danego wzorca
  • Aktualizuj nieistniejący element

Delete

  • Usuń jeden istniejący element
  • Usuń więcej niż jeden element
  • Usuń elementy pasujące do danego wzorca
  • Usuń nieistniejący element

W podejściu trzecim poza samym faktem wykorzystywania operacji testujemy również warunki, w jakich to się odbywa. W szczególności:

  • Kto. Jaki użytkownik może wykonać daną operację? Jakie musi mieć uprawnienia?
  • Co. Jaki typ operacji jest możliwy? Czy oprócz operacji poprawnych jest dopuszczane wymuszenie operacji niepoprawnej? Co ze znakami specjalnymi, pustymi wartościami pól, długimi łańcuchami znaków itd.?
  • Kiedy. Kiedy dana operacja może zostać wykonana? Jaki jest skutek operacji żądanych w czasie niedostępności systemu?
  • Dlaczego. Jaki jest cel wykonania danej operacji? Czy można wykonać operację w złej wierze (np. kwestie bezpieczeństwa)?
  • Jak. W jaki sposób są wykonywane operacje? Czy przez polecenia z klawiatury, plik wsadowy, wybór operacji z graficznego interfejsu użytkownika?

[1] Dla przypadku zawierającego  akcji liczba możliwych ustawień tych operacji wynosi

SJSI wymienia certyfikaty uczestnikom Testwarez

Jesteś certyfikowanym testerem z SJSI i chciałbyś sprawić, żeby Twój certyfikat nabrał nowego wyglądu? Czas na zmiany!

Dla uczestników konferencji Testwarez, którzy zdawali egzamin organizowany przez SJSI przed marcem 2016, organizacja zaproponowała wymianę certyfikatu na ten z nowym wzorem (http://sjsi.org/nowy-wyglad-certyfikatow-istqb) !

Pamiętajcie, że dla osób, które polubią Nas na facebooku:
Stowarzyszenie Jakości Systemów Informatycznych
( https://pl-pl.facebook.com/SjsiOrg/) i udostępnią Naszego posta z logo Testwarez na swoim profilu (https://www.facebook.com/SjsiOrg/photos/a.539403516080554.115058.193869890633920/1187136781307221/?type=3), przewidujemy możliwość wymiany certyfikatu bez ponoszenia jakichkolwiek opłat!

Nie czekajcie i nie zastanawiajcie się – w końcu taka konferencja i związane z Nią bonusy dla Was zdarzają się tylko raz w roku.

Zgłoszenia przyjmujemy na adres: Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie obsługi JavaScript.

W tytule zgłoszenia koniecznie wpiszcie: wymiana certyfikatu – imię i nazwisko.

W treści podajcie proszę datę wydania certyfikatu i poziom egzaminu + dodatkowo link do swojego profilu na facebooku (jeśli skorzystaliście z warunków promocji, o której mowa powyżej).
Akcja trwa do końca dnia 15 września 2016r.

Gotowe certyfikaty będziecie mogli odebrać przy stoisku SJSI w trakcie konferencji TW 2016!

Nasz Książkowir recenzuje "Zawód Tester"

Zawód testera interesuje mnie od wielu lat. Najchętniej testowałabym oczywiście gry komputerowe, na przykład te produkcji Blizzarda. To byłby wymarzony dla mnie zawód. Niestety nie znam nikogo, kto zajmowałby się tym. Moja siostra pracuje jako tester, ale ona zajmuje się jakimiś nudnymi programami ubezpieczeniowymi czy księgowymi, a to z pewnością nie dla mnie, zanudziłabym się na śmierć. Za to testowanie gier długo nie miałabym dość. Postanowiłam poczytać trochę o tym zawodzie, żeby wiedzieć, czy mam do niego jakieś predyspozycje.

Książka Zawód tester Radosława Smilgina to świetny początek dla kogoś, kto zastanawia się nad pracą testera oprogramowania. Przede wszystkim zawiera bardzo dużo wiadomości podstawowych na temat rodzajów testów, sposobów ich wykonywania i narzędzi stosowanych przez testerów. Pisze też o tym, jak te teoretyczne informacje wyglądają w praktyce. Podaje przykłady testów, jakie wykonywane są w przypadku konkretnych rodzajów oprogramowania.

[...]

Czytaj całość >>

Propozycja startegii ewolucyjnej ewolucyjnego generowania struktury danych opartych o poziome drzewa danych dla potrzeb testów

Celem artykułu jest prezentacja definicji matematycznego modelu obiektu, który w informatyce znany jest jako TreeList oraz wykorzystanie tego modelu do zaprojektowania algorytmu ewolucyjnego, którego zadaniem jest generowanie struktur opartych na obiekcie TreeList. Pierwszy rozdział wprowadza czytelnika w problem, jakim jest prezentacja danych za pomocą wspomnianego obiektu TreeList. Drugi rozdział opisuje problem testowania struktur danych opartych o TreeList. Rozdział trzeci natomiast prezentuje matematyczny model obiektu TreeList oraz miary, które można wykorzystać w celu określenia użyteczności struktur utworzonych za pomocą wspomnianych obiektów oraz w strategii ewolucyjnej, która generuje te struktury dla potrzeby ich testowania. Ostatni rozdział zawiera krótkie podsumowanie oraz plany przyszłych badań związanych z zaprezentowanym w artykule algorytmem.

Marek ŻUKOWICZ, Michał MARKIEWICZ

Opublikowano w Management Systems in Production Engineering

 

Artykuł po polsku >>

Artykuł po angielsku >>

testerzy.pl na katowickim Business Runie 2016

Już w niedzielę startuje katowicki Business Run, a w nim startujemy i my.

To już trzeci raz, jak łączymy przyjemne z ...potrzebnym i dzięki dobrej zabawie pomagamy tym, którzy potrzebują wsparcia.

Pakiety startowe już w biurze. Trzymajcie za nas kciuki!

 

 

 

Scrum Guide - Przewodnik po Scrumie 2016

Zmiany w Scrum Guide może nie są na pierwszy rzut oka znaczące, ale są kluczowe dla wielu członków zespołu. Możemy zobaczyć uzasadnienie dla zmian przedstawione przez samych autorów Kena Schwabera i Jeffa Sutherlanda.

 

 

Dlaczego zmiany są takie ważne w opinii Tomka Włodarka - tłumacza polskiej wersji przewodnika - "Czytając The New New Product Development Game Takeuchiego i Nonaki potwierdziłem, że o sukcesie zespołu nie stanowi dobór narzędzi czy procesu, a przede wszystkim nastawienie. Nastawienie pozwalające zespołowi przeć do przodu i poszukiwać nowych sposobów osiągania celów wbrew, a może dzięki napotykanym trudnościom. Nastawienie, które poprzez zaufanie pozwala działać samoorganizacji i oddolnej inteligencji.

Wartości - zaangażowanie, otwartość, odwaga, skupienie, poszanowanie - dają Scrumowi grunt. Wartości powodują, że praktyki nabierają znaczenia i stają się emanacją idei a nie ideą czy celem samym w sobie. Co ciekawe, mimo, że każdy z nas inaczej interpretuje te słowa, mogą one z powodzeniem stanowić podstawę działania każdego zespołu, wytyczać ramy interakcji pomiędzy członkami zespołu, oraz pomiędzy zespołem a jego otoczeniem. Dlatego tak bardzo cieszy mnie każda dyskusja o wartościach, tym razem prowokowana przez zapisy dokumentu będącego oficjalną wykładnią Scruma."

Zakres zmian względem wersji 2013.

Została dodana sekcja poświęcona Wartościom Scruma. Gdy Zespół Scrumowy przyjmie wartości zaangażowania, odwagi, skupienia, otwartości i poszanowania i postępuje zgodnie z nimi, do życia powoływane są filary Scruma – przejrzystość, inspekcja i adaptacja, tworząc atmosferę zaufania pomiędzy wszystkimi współpracującymi osobami. Członkowie Zespołu Scrumowego odkrywają te wartości i uczą się ich pracując z wydarzeniami, rolami i artefaktami Scruma. Powodzenie w wykorzystaniu Scruma zależy od biegłości postępowania zgodnie z tymi pięcioma wartościami. Wszyscy osobiście zobowiązują się osiągać cele Zespołu Scrumowego. Członkowie Zespołu Scrumowego mają odwagę postępować właściwie i przezwyciężać trudności. Wszyscy skupiają się na pracy w Sprincie i celach Zespołu Scrumowego. Zespół Scrumowy i jego interesariusze zgadzają się pozostawać otwartymi na wszystkie aspekty wykonywanej pracy i związane z nią wyzwania. Członkowie Zespołu Scrumowego wzajemnie respektują swoje prawo do bycia niezależnymi, kompetentnymi ludźmi.

 

Nowa wersja Scrum Guide >>

 

 

Obrazek z Pixabay >>

Czy trzeba testować produkty?

Jeśli sam nie lubisz testować swoich produktów, prawdopodobnie twoi klienci również nie będą lubili ich testować.

~Anonim

Za TechWell.