Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN

Podobne dokumenty
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Faza Określania Wymagań

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Priorytetyzacja przypadków testowych za pomocą macierzy

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym RedCart (plugin dostępny w wersji ecommerce)

Meandry komunikacji Biznes-IT

Wymagania, specyfikacja i projektowanie

Metodyka projektowania komputerowych systemów sterowania

emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce)

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Shoper (plugin dostępny w wersji ecommerce)

Strategia testów mająca doprowadzić do osiągnięcia pożądanych celów

Inżynieria wymagań. Inżynieria wymagań 1/1

Cele przedsięwzięcia

Zagadnienia (1/3) Inżynieria Oprogramowania

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento 2 (plugin dostępny w wersji ecommerce)

Inżynieria oprogramowania II

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce)

Testujemy dedykowanymi zasobami (ang. agile testers)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

Testowanie oprogramowania

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Plan testów do Internetowego Serwisu Oferowania i Wyszukiwania Usług Transportowych

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Wymagania pozafunkcjonalne

Behavior Driven Development (BDD)

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym WooCommerce (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym IAI-Shop (plugin dostępny w wersji ecommerce)

Procesowa specyfikacja systemów IT

Analityk i współczesna analiza

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Od pomysłu do podpisania umowy. Izabela Adamska

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Jak opisać wymagania zamawiającego wybrane elementy

1. INFORMACJE O DOKUMENCIE 2. WPROWADZENIE

Zarządzanie sprzedażą w programie bs4

Podręcznik użytkownika Publikujący aplikacji Wykaz2

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Sky-Shop (plugin dostępny w wersji ecommerce)

Płatności CashBill - Kody

Modelowanie i analiza systemów informatycznych

Wymagania pozafunkcjonalne - projektowanie interfejsu użytkownika

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym SoteShop 7 (plugin dostępny w wersji ecommerce)

020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym RedCart (plugin dostępny w wersji ecommerce)

Maciej Oleksy Zenon Matuszyk

Podręcznik użytkownika Wprowadzający aplikacji Wykaz2

Praktyka testowania dla początkujących testerów

REFERAT PRACY DYPLOMOWEJ

Dokumentacja użytkownika systemu

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Wersja programu

OTWARCIE RACHUNKU BROKERSKIEGO ONLINE (Potwierdzenie przelewem) oraz ZŁOŻENIE ZAPISU W SYSTEMIE BANKOWOŚCI INTERNETOWEJ

Testowanie oprogramowania

Postępowania regulaminowe / do euro

Inżynieria oprogramowania wykład IV Faza określenia wymagań

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Programowanie obiektowe

Konsolidacja FP- Depozyty

INFORMACJA I informacje@pkobp.pl, I INFOLINIA I opłata jak za połączenie lokalne

Jakość w procesie wytwarzania oprogramowania

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento 2 (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Shoper (plugin dostępny w wersji ecommerce)

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Overlord - Plan testów

Nowoczesne aplikacje mobilne i ich rola w podnoszeniu jakości danych

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Wprowadzenie do Behaviordriven

ZAPYTANIE OFERTOWE. Wsparcie projektów celowych

Usługa Moje faktury w ING BankOnLine

9 Zakup [ Zakup ] Zakup

Programowanie zespołowe

Aplikacje WWW - lab 5

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

DLA SEKTORA INFORMATYCZNEGO W POLSCE

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Agenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia

Instrukcja obsługi platformy B2B

REGULAMIN SKLEPU INTERNETOWEGO z dnia 11 lutego 2017

Analiza antyplagiatowa prac dyplomowych w Uniwersyteciee Zielonogórskim w modułach StudNet, PracNet systemu Dziekanat oraz w systemie OSA.

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Model jakości McCalla

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

emszmal 3: Automatyczne księgowanie płatności w programie EasyUploader (plugin dostępny w wersji ecommerce)

Zarządzanie zadaniami w projektach informatycznych na przykładzie systemu Trac. Integracja z Eclipse.

B A N K S P Ó Ł D Z I E L C Z Y W G R Y B O W I E REGULAMIN

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

B A N K S P Ó Ł D Z I E L C Z Y W L I M A N O W E J

Tom 6 Opis oprogramowania

Specyfikacja Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.

Instrukcja dla użytkownika korzystającego z Usługi Moje faktury

Transkrypt:

Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN

Poznajmy Prowadzących Uczestników I oczekiwania.

Agenda Wymagania Różne poziomy wymagań Kryteria jakości dla wymagań Specyfikacje http://edu.ittraining.pl/szkolenie/tworzenie_i_ocena_specyfikacji_wymaga n_funkcjonalnych

Wymaganie Co to jest wymaganie? Rozważmy przykład: wymagania na kota Kot ma składać się z głowy i korpusu Kot musi mieć 4 odnóża Kot musi mieć 2 oczu Kot powinien mieć ogon

Wymagania Projekt kota na postawie wymagań:

Wymagania Projekt kota po uszczegółowieniu wymagań:

Wymagania Co dostał klient:

Wymagania Co chciał klient: Błędy w procesie to koszt:

Zadanie Definiowanie wymagań

Wymagania W czym leży problem? Jakość wymagań Wymagania stanowią element kontraktu na usługę/produkt Żeby wykonać usługę/produkt, trzeba dokładnie wiedzieć, CO chcemy osiągnąć

Wymagania 1. Warunek lub umiejętność wymagana przez interesariusza po to, by rozwiązać określony problem lub osiągnąć cel. 2. Warunek lub umiejętność, która musi być spełniona przez system lub komponent systemu, aby wypełnić założenia umowy, standardu, specyfikacji lub innego formalnego 3. Udokumentowana reprezentacja warunku lub umiejętności jak w (1) lub (2)

Wymagania

Wymagania Funkcjonalne Produktowe Niefunkcjonalne Wymaganie Techniczne Ograniczenia Biznesowe

Wymagania Niezawodność Dojrzałość Odporność na błędy Zdolność do odtworzenia Użyteczność Łatwość zrozumienia Łatwość nauki. Operatywność Atrakcyjność Wydajność Wykorzystanie czasu. Wykorzystanie zasobów Utrzymywalność Łatwość analizy Łatwość wprowadzania zmian. Stabilność Łatwość testowania Przenaszalność Łatwość adaptacji Możliwość współistnienia Łatwość instalacji Łatwość zastąpienia Dopasowania Dokładność Funkcjonalność Interoperacyjność Bezpieczeństwo

Wymagania Atrybuty wymagań nadają kontekst Projekt Sklep internetowy ID BRQ 001 Nazwa Użytkownik musi być w stanie dokonać wyszukiwania produktu w serwisie Priorytet Wysoki Krytyczność Średnia Ryzyko Umożliwienie wyszukiwania przy użyciu zbyt wielu kryteriów wyszukiwania może opóźniać działanie systemu Źródło Dział Marketingu Typ Wymaganie funkcjonalne Status Proponowane Planowana Faza 1 iteracja realizacji Poziom Średni skomplikowan ia Autor Jan Nowak Właściciel Karol Kowalski

Kryteria jakości Poprawne wymaganie musi odpowiednio przekazywać potrzebę interesariusza czy inne wyższego rzędu wymaganie. Punktem odniesienia do sprawdzenia poprawności wymagania jest jego źródło (na przykład sprawdzenie, czy konkretne wymaganie interesariusza odpowiednio odzwierciedla wymaganie biznesowe, z którego wzięło początek). Konieczne wymaganie powinno dokumentować to, czego klient (lub inni interesariusze) naprawdę potrzebują, aby spełnić konkretną potrzebę czy cel biznesowy, czy też standard lub inne wymaganie zewnętrzne. Innymi słowy, implementacja wymagania musi dostarczać jakiś potencjał wartości dla interesariuszy. Wymaganie jest wtedy konieczne, kiedy jego brak w produkcie powoduje odczuwalną i wpływającą na kompletność lub/i jakość lukę. Wykonalne wymaganie musi być możliwe do zaimplementowania zgodnie ze znanymi możliwościami i/lub ograniczeniami produktu, projektu oraz otoczenia. Jednoznaczne opis wymagania musi być taki, by istniała możliwość tylko jednej interpretacji. Wymaganie, które odbiorcy rozumieją na inne sposoby, nie jest jednoznaczne, a tym samym nie będzie nigdy testowalne ani możliwe do implementacji. Weryfikowalne inaczej testowalne. Wymaganie musi być możliwe do przetestowania i jednoznacznego i mierzalnego określenia, czy zostało poprawnie zaimplementowane.

Kryteria jakości Spriorytetyzowane wymagania nie są równe pod względem znaczenia dla interesariuszy. By być w stanie określić ważność danego wymagania, należy przypisać mu odpowiedni priorytet. Jednostkowe stwierdzenie wymagania (opis) nie może zawierać wielu wymagań. Przy opracowywaniu treści wymagań należy upewnić się, że opisujemy pojedyncze wymaganie. Zgodne wymaganie nie stoi w sprzeczności z innymi wymaganiami, lub powiązaną dokumentacją. Zrozumiałe wymaganie jest zrozumiałe wtedy, gdy jego przekaz i znaczenie są jasne dla odbiorcy. Skróty myślowe, specjalistyczne terminy i skróty, nigdzie niewyjaśnione czy rozwinięte, powodują, iż czytelnik może mieć trudności w prawidłowym (czyli z godnym z intencją autora) zrozumieniu wymagania, co w dalszej kolejności może powodować problemy wynikające z różnej interpretacji treści wymagania. Abstrakcyjne inaczej niezależne od sposobu implementacji. Wymaganie powinno opisywać Co chcemy osiągnąć a nie Jak to zrobić. Innymi słowy, wymaganie nie powinno implikować ani narzucać sposób implementacji. Umieszczanie w opisie wymagania informacji wskazujących na sposób rozwiązania jest jednym z najczęstszych błędów popełnianych w dokumentacji wymagań, ponieważ myślenie w rozwiązaniach jest w wielu przypadkach prostsze i bardziej intuicyjne, niż posługiwanie się abstrakcyjnymi wyobrażeniami.

Kryteria jakości Dobry opis wymagania: Prostota opis wymagania nie może zawierać złożonych warunków i struktur; to będzie przedmiotem dalszej analizy. Spójność terminologia używana w dokumentacji wymagań jest spójna i ma to samo znaczenie w różnych częściach dokumentacji (przykład słowo klient użyte w dokumentacji zawsze znaczy to samo i określa docelowego Klienta z punktu widzenia organizacji zamawiającej produkt IT). Zrozumiałość powinno być zrozumiałe zarówno dla eksperta dziedzinowego, testera, programisty, jak i dowolnej innej osoby z grupy udziałowców. Zwięzłość tekst wymagań powinien być w miarę możliwości krótki i powinien opisywać wyłącznie zakres danego wymagania.

Kryteria jakości Wymaganie System ma być intuicyjny. System powinien wyświetlać stronę Wyników wyszukiwania z przyciskami Następny i Poprzedni znajdującymi się na dole ekranu. Problemy Wymaganie jest: niejednoznaczne, a w konsekwencji nietestowane i niewykonalne. Wszystkie problemy wynikają z tego, że określenie intuicyjny nie jest mierzalne (a więc nie będzie również ani wykonalne bo jak zrealizować coś, czego nie rozumiemy, ani testowalne) Taki opis wymagania determinuje sposób implementacji. Wymaganie zależy więc od implementacji. System ma działać na dowolnej przeglądarce IE. Wymaganie jest niejednoznaczne co oznacza dowolna przeglądarka IE? Wersje już niewspierane lub, co gorsza, przyszłe, również? W takiej postaci wymaganie staje się dodatkowo niewykonalne i nietestowane.

Kryteria jakości Dla każdego wymagania: Czy wymaganie jest prawidłowe? Czy wymaganie jest wykonalne? Czy wymaganie jest mierzalne? Czy wymaganie jest testowalne? Czy wymaganie jest pojedyncze? Czy wymaganie jest zrozumiałe? Czy wymaganie posiada priorytet? Czy wymaganie jest jednoznaczne?

Kryteria jakości Przykład czy wszystko ok? System ma umożliwiać zakup biletów w komunikacji lotniczej. Zakup biletu wymaga określenia odpowiedniego połączenia lotniczego i podania danych pasażera. System umożliwia wyszukiwanie połączeń lotniczych

Kryteria akceptacji Oprócz kryteriów jakości kryteria akceptacji Standardy, czy warunki wymagane, by spełnić oczekiwania jakościowe interesariuszy i uzyskać akceptację finalnego produktu. Kryteria nałożone na określony obiekt, które musza być spełnione, by zamawiający zaakceptował i przyjął ów obiekt.

Kryteria akceptacji System ma umożliwiać zakup biletów w komunikacji lotniczej. Zakup biletu wymaga określenia odpowiedniego połączenia lotniczego i podania danych pasażera. System umożliwia wyszukiwanie połączeń lotniczych. Kryteria akceptacji dla wymagania związanego z wyszukiwaniem połączeń lotniczych: System umożliwia wyszukiwanie połączeń lotniczych przy użyciu wybranych kryteriów wyszukiwania. W przypadku braku połączeń spełniających kryteria użytkownika, system komunikuje brak wyników wyszukiwania a użytkownik może zmodyfikować kryteria wyszukiwania i wykonać procedurę wyszukiwania od nowa. W przypadku awarii wyszukiwania połączeń lotniczych, system komunikuje użytkownikowi błąd o odpowiedniej treści. Wyszukiwanie danych i wyświetlenie wyników wyszukiwania nie trwa dłużej, niż 30 sekund.

Specyfikacja wymagań Różne formy: User story Przypadki użycia IEEE 830

Specyfikacja wymagań ID Tytuł Status Opis Ograniczenia Uzasadnienie Priorytet Referencje Wpływy Kryteria akceptacji Komentarze

Specyfikacja wymagań Id FR001 Tytuł Wyszukiwanie książki Krótki opis System umożliwia użytkownikowi wyszukiwanie książki za pomocą wybranych kryteriów wyszukiwania. Przebieg podstawowy 1. Użytkownik wybiera funkcję wyszukiwania książki 2. System wyświetla formularz wyszukiwania książki (SCR_001_1). 3. Użytkownik wprowadza kryteria wyszukiwania i potwierdza żądanie wyszukiwania 4. System wyświetla wyniki wyszukiwania (SRC_001_2). Przebieg alternatywny *a. Użytkownik przerywa operację. *a.1 System kieruje użytkownika na główną stronę aplikacji. 3a. Użytkownik wykonuje wyszukiwanie bez wprowadzenia minimalnych kryteriów wyszukiwania. 3a.1 System wyświetla komunikat błędu (ER_001) 3a.2 Powrót do kroku 2 przebiegu podstawowego. Właściciel 4a. Nie znaleziono wyników. System wyświetla komunikat informacyjny (ER_002). 4a.1 Powrót do kroku 2 przebiegu podstawowego. John Doe

Traceability Wymagani a biznesowe

Macierz śledzenia wymagań Projekt: Bankowość Traceability Kierownik projektu: Opis projektu: J.D. ID Potrzeba klienta Wymagani e funkcjonaln e 001 Umożliwienie wykonania kluczowych transakcji bankowych FR01 Realizacja wpłaty gotówki FR02 Realizacja wypłatz gotówki FR03 Realizacja przelewu środków pieniężnych FR04 Wyszukiwan ie klienta FR05 Zarządzanie danymi klienta FR06 Obliczanie prowizji FR07 Drukowanie raportów przepływu gotówki Status W trakci e Nr. Przypadku testowego TC01 Realizacja wpłaty gotówki TC 02 Realizacja wypłatz gotówki TC 03 Realizacja przelewu środków pieniężnych TC 04 Wyszukiwanie klienta TC 05 Zarządzanie danymi klienta TC 06 Obliczanie prowizji TC 07 Drukowanie raportów przepływu gotówki Testo wane w Wyda nie #1 Zaimple mentow ane w Wydani e #1

Modele Modele to reprezentacja wymagań je też się testuje. Czy są kompletne? Czy nie są sprzeczne? Czy wymagania tak zamodelowane mają sens?

Modele

Potestujmy więc http://edu.ittraining.pl/szkolenie/tworzenie_i_ocena_specyfikacji_wymaga n_funkcjonalnych