t e s t o w a n i e j e s t ł a t w e
|
|
- Małgorzata Komorowska
- 6 lat temu
- Przeglądów:
Transkrypt
1 testerzy.pl Podstawą tego tekstu jest Foundation Level Syllabus wydany przez ISTQB. Zarządzanie Zarządzanie testami Organizacja testów Niezależność organizacyjna testów Efektywność w znajdowaniu defektów może zostać poprawiona dzięki niezależnej grupie testowej. Wyróżniamy następujące typy niezależności: - niezależny tester wewnątrz grup programistów - niezależna grupa testowa lub po prostu grupa wewnątrz organizacji, raportująca do kierownika projektu lub zarządu - niezależność testera od organizacji biznesowej, społeczności użytkowników czy działu IT - specjalista testów niezależny od testerów takich jak testerzy użyteczności, bezpieczeństwa czy certyfikacji (certyfikujący produkt zgodnie ze standardami i regulacjami) - niezależny tester spoza organizacji. Dla potrzeb skomplikowanych i rozbudowanych projektów najlepsze jest stosowanie testowania na każdym poziomie przez niezależną grupę testową. Programiści mogą uczestniczyć w procesie testowym, szczególnie na niskich poziomach, ale ich brak obiektywności często skutkuje ich niską skutecznością. Niezależny tester może mieć umiejętności wymagane i zdefiniowane w procesie testowym, ale nade wszystko koniecznie powinien on mieć mandat do wykonania wszystkich zadań związanych z przypisanymi mu obowiązkami nadany mu przez kierownictwo. Korzyści płynące z niezależności to: - postrzeganie różnych defektów w sposób bezstronny - weryfikacja założeń wprowadzanych przez ludzi zajmujących się specyfikacją i implementacją systemu. Istnieją również negatywne aspekty: - izolacja od programistów (w przypadku pełnej niezależności) - niezależny tester może być zwężeniem a przez to opóźniać projekt jako jego ostatni punkt kontrolny - programiści przestają przejmować się jakością wiedząc, że ktoś i tak ich sprawdzi (ewentualnie zaproponuje poprawki). Zadanie testowe są wykonywane przez ludzi o określonych rolach, ale mogą one być również wykonywane przez ludzi na innych stanowiskach jak np. kierownik projektu, kierownik jakości, programista, ekspert biznesowy lub pracownicy IT. Zadania lidera i testera Zadanie i obowiązki ludzi na tych dwóch kluczowych stanowiskach zależą od projektu i sytuacji wokół produktu. Zależą również od ludzi na konkretnych stanowiskach i struktury samej organizacji.
2 Czasami liderzy testowi nazywani są kierownikami testów lub koordynatorami testów. Zadania lidera mogą być wykonywane przez kierownika projektu, kierownika programistycznego, kierownika ds. zapewnienia jakości lub kierownika grupy testowej. W dużych projektach zazwyczaj rozróżniamy dwa stanowiska: lider i kierownik testów. Lider zazwyczaj planuje, monitoruje i kontroluje czynności testowe. Zadania lidera grupy testowej: - planowanie i koordynacja strategii wraz z kierownikiem projektu i innymi udziałowcami - pisanie i przegląd strategii testów dla projektów oraz polityki testowej dla organizacji - stosowanie perspektywy testów dla innych aktywności testowych takich jak planowanie integracji - planowanie testów - rozważanie kontekstu i rozumienie ryzyka - włączając w to wybór metod testowych, szacowanie czasu, wysiłku i kosztów testowania; zdobywanie zasobów, definiowanie poziomów testowych, cykli, metodologii i celów oraz planowanie zarządzania przypadkami - inicjowanie, specyfikacja, przygotowanie, implementacja i wykonanie testów oraz późniejsze ich monitorowanie i kontrola - korekty planowania oparte na wcześniejszych planach w odniesieniu do postępu testów (czasami udokumentowanych w statusie) oraz podjęcie niezbędnych czynności dla kompensacji problemów - dla ułatwienia śledzenia wersji ustanowienie adekwatnego zarządzania konfiguracją dla narzędzi testowych - decydowanie, co powinno być zautomatyzowane, do jakiego stopnia oraz jak powinno to być przeprowadzone - zaproponowanie dopasowanych miar dla pomiarów postępu testowego oraz szacowania jakości testowania oraz jakości produktu - decydowanie o implementacji środowiska testowego - rozpisanie na osi czasu testów - pisanie raportów podsumowujących testy, opartych na informacjach zebranych podczas testowania. Typowe zadania testera: - przegląd i własny wkład w plany testów - analiza, przegląd i ocena wymagań użytkowników, specyfikacji i modeli pod kątem testowalności - tworzenie specyfikacji testowej - ustanowienie środowiska testowego (często koordynacja z administratorem systemu i sieci) - przygotowanie i zdefiniowanie danych testowych - implementowanie testów na wszystkich poziomach testowych, wykonanie i zapisywanie wyników testów, ocena wyników i dokumentacja różnic w stosunku do oczekiwanego rezultatu - użycie narzędzi administrowania, zarządzania i monitorowania testów - automatyzacja testów (wspierana programistami lub ekspertami od automatyzacji testów) - pomiar wydajności komponentów systemu (gdy wymagane) - przegląd i sprawdzenie testów napisanych przez innych. Ludzie pracujący nad analizą, projektowaniem i automatyzacją testów mogą być specjalistami w tych zadaniach. W zależności od poziomu testowego oraz ryzyka powiązanego z produktem i projektem, różni ludzie mogą przyjmować zadania testerów, zachowując ciągle niezależność. Typowo testerzy na poziomie komponentu lub integracji będą programistami, testerzy na poziomie testów akceptacyjnych będą ekspertami biznesowymi i użytkownikami, a testerzy operacyjnych testów akceptacyjnych będą po prostu operatorami. Planowanie i estymacja testów Planowanie testów Ta część podejmuje się zdefiniować cel planowania testów wewnątrz projektu tworzenia oprogramowania, implementacji i potrzeb serwisowych. Planowanie może być udokumentowane w projektowym lub głównym planie testów lub oddzielnym planie testów stworzonym specjalnie dla poszczególnych poziomów testowych, takich jak testowanie systemu i testowanie akceptacyjne. Dokładne wskazówki jak planować testy można znaleźć w "Standard for Software Test Documentation" (IEEE 829).
3 Na planowanie wpływa polityka testów organizacji, zakres testowanie, cele, ryzyko, ramy, ważność, testowalność i dostępność zasobów. Czym bardziej planowanie projektu i testów jest zaawansowane tym więcej informacji jest dostępnych i więcej szczegółów może zostać dołączonych do planów. Planowanie testów jest ciągłą czynnością wykonywaną w ciągu trwania cyklu życia projektu. Informacja zwrotna z czynności testowych jest użyta do rozpoznania ryzyka tak by planowanie mogło być dopasowane do rzeczywistych warunków. Czynności związane z planowaniem testów obejmują: - zdefiniowanie ogólnej metody testowej (strategia testów), włączając w to definiowanie poziomów testowych oraz kryteriów rozpoczęcia i zakończenia testów - integracja i koordynacja czynności testowych w ramach cyklu tworzenia oprogramowania: zakupu, dostarczenia, rozwoju, operacji i serwisu - dokonywanie decyzji o tym, co należy testować, kto ma wykonywać każdą z czynności testowych, kiedy i jak czynności testowe powinny być wykonane, jak wyniki testów będą analizowane i kiedy przerwać testowanie (kryterium wyjścia) - przypisanie zasobów dla różnych, zdefiniowanych zadań - definiowanie ilości, poziomu dokładności, struktury i wzorców dokumentacji testowej - wybór miar dla monitorowania i kontrolowania przygotowania testów, rozwiązywania problemu defektów oraz oceny ryzyka - ustanawianie poziomu dokładności dla procedur testowych w celu dostarczenia wystarczającej informacji do wsparcia reprodukowanych czynności przygotowania i wykonania testów Kryterium zakończenie testów Celem definiowania kryterium zakończenia testów jest określenie, kiedy przerwać testowanie, na różnych poziomach lub kiedy zestaw testów zostanie wyczerpany. Kryterium wyjścia zawiera: - dokładne metryki takie jak pokrycie kodu, funkcjonalności lub ryzyka - kalkulacja ilości defektów w stosunku do tych, możliwych do wystąpienia lub miary niezawodności - koszty - pozostałe ryzyko, takiej jak pozostawione defekty, niepełne pokrycie testów w określonym obszarze - rozpiska planów w czasie, takich jak data dostarczenia produktu na rynek. Ocena testów Dwie metody oceny wysiłku testowego: - ocena wysiłku testowego oparta na metrykach poprzedniego lub podobnego projektu lub oparte na znanych, typowych wartościach - ocena zadań dokonana przez właściciela tych zadań lub przez eksperta. Kiedy wysiłek zostanie już oceniony, zasoby mogą zostać określone oraz można przygotować plan działań. Wysiłek testowy zależy od różnych czynników takich jak: - parametry produktu: jakość specyfikacji i innych informacji użytych dla modeli testowych, rozmiar produktu, złożoność obszaru problemu, wymagań niezawodności i bezpieczeństwa, wymagań względem dokumentacji - parametry procesu rozwoju oprogramowania: stabilność organizacji, użyte narzędzia, procesy testowe, umiejętności ludzi zaangażowanych w projekt oraz presja czasu - wynik testowania: ilość znalezionych defektów i ilość wymaganych poprawek Strategie testów Jedna z metod klasyfikacji strategii testów jest oparte na okresie czasu, w którym największe nawał pracy w projektowaniu testów się rozpoczyna: - metoda prewencji, gdzie testy projektowane są jak najwcześniej - metoda reaktywna, gdzie testy projektowane są po wyprodukowaniu oprogramowania lub systemu. Do typowych metod lub strategii zaliczamy:
4 - analityczne metody oparte na ryzyku testowym gdzie testowanie jest ukierunkowane na obszary najbardziej narażone na ryzyko wystąpienia błędów - metody oparte na modelu takie jak testowanie stochastyczne z użyciem informacji statystycznych o kalkulacji problemów występujących po wystąpieniu defektów - metodologiczne takie jak oparte na konsekwencjach błędów (włączając w to zgadywanie błędów), oparte na punktach kontrolnych, oparte na jakości parametrów - metody zgodne z procesami i standardami, takie jak te opisane przez standardy przemysłowe lub różne metodologie Agile - metody dynamiczne, takie jak wyczerpujące testowanie gdzie testowanie jest bardziej konsekwencją zdarzeń poprzednio zaplanowanych i gdzie wykonywanie i ocenianie są równoległymi zadaniami - metody konsultatywne, kierowane wcześniejszą radą, przy pomocy przewodnika technologicznego i/lub obszarem biznesowych ekspertyz wykonanych poza zespołem testowym - metody regresywne takie jak ponowne użycie materiałów testowych, automatyzacji testów regresji oraz standardów testowych. Różne metody mogą być ze sobą łączone np. dynamiczne metody oparte na ryzyku. Wybór strategii powinien być poprzedzony rozważaniem kontekstu: - ryzyka wystąpienia konsekwencji błędów w projekcie, niebezpieczeństwo dla produktu i ryzyko narażenia bezpieczeństwa użytkownika, środowiska lub firmy - umiejętności i doświadczenie ludzi w zaproponowanych technikach, narzędziach i metodach - cele zdolności testowania i misja zespołu testowego - aspekty regulujące takie jak wewnętrzne i zewnętrzne regulacje dla procesu tworzenia oprogramowania - natura produktu i biznesu.
5 Monitorowanie i kontrola postępów w testowaniu Monitorowanie postępu testów Celem monitorowania testowania jest otrzymywanie informacji i zdobywanie jasności o czynnościach testowych. Efekt monitorowania może być zbierany ręcznie lub automatycznie i może być użyty dla pomiaru kryterium zakończenie testów takich jak pokrycie. Miary mogą być użyte do oceny postępu w odniesieniu do tego, co zostało zaplanowane i zabudżetowane. Najczęściej metryki testowe zawierają: - procent wykonanej pracy w przygotowaniu przypadków testowych (lub procent zaplanowanych przypadków testowych już przygotowanych) - procent pracy wykonanej do przygotowania środowiska testowego - wykonanie przypadków testowych (np. liczba wykonanych/niewykonanych przypadków testowych i ilość przypadków testowych, które "przeszły"/"nie przeszły") - informacje o defektach (np. ilość defektów, ilość defektów znalezionych i naprawionych, ocena konsekwencji błędów, wyniki retestów) - pokrycia wymagań, ryzyka lub kodu - daty kamieni milowych testowania - koszty testowania, włączając w to koszty porównane z korzyściami płynącymi ze znajdowania następnych defektów lub przeprowadzania następnych testów. Raportowanie Raportowanie testowe jest postrzegane jako zbieranie informacji o wysiłku w testowaniu: - co stało się podczas testowania, np. daty, kiedy kryterium zakończenia testów zostanie osiągnięte - przeanalizowanie informacji i metryk do wsparcia rekomendacji i decyzji o przyszłych działaniach takich jak ocena pozostałych defektów, ekonomiczne korzyści z kontynuacji testów, pozostałe ryzyko i poziom niezawodności testowanego oprogramowania. Metryki powinny być zbierane podczas i na koniec każdego poziomu testowego dla oceny: - poziomu jakości w odniesieniu do celów założonych dla danego poziomy testowego - efektywności testowania w odniesieniu do celów - adekwatności obranej metody testowej. Kontrola Kontrola opisuje wszystkie działania korygujące i naprowadzające powzięte jako rezultat informacji i metryk zebranych i zaraportowanych. Czynności mogą pokrywać czynności testowe i mogą wpływać na inne czynności w cyklu tworzenia oprogramowania. Przykłady kontroli testów: - zmiana priorytetów testów w przypadku, gdy pojawi się ryzyko - zmiana planu testów zgodnie z dostępnością środowiska testowego - zestaw kryteriów jakości wymagających naprawy, które muszą zostać przetestowane przez programistę, zanim zostaną zaakceptowane do integracji.
6 Zarządzanie konfiguracją Celem zarządzania konfiguracją jest ustanowienie i serwisowanie integralności produktów (komponentów, danych i dokumentacji) programistycznych lub systemów w czasie trwania projektu i cyklu tworzenia oprogramowania. Dla testowania, zarządzanie konfiguracją obejmuje zapewnienie, że: - wszystkie elementy środowiska narzędziowego testów zostały zidentyfikowane, ich wersje podlegają kontroli, zmiany są śledzone w całym czasie trwania procesu - wszystkie zidentyfikowane dokumenty i elementy oprogramowanie znajdują odniesienie (w sposób bezsprzeczny) w dokumentacji testowej. Zarządzanie konfiguracją pomaga testerowi zidentyfikować (i zreprodukować) testowane elementy, dokumenty testowe, testy i narzędzia wspierające testowanie. Podczas planowania, procedury i infrastruktury (narzędzi) zarządzania konfiguracją powinno być wybrane, udokumentowane i zaimplementowane.
7 Ryzyko Ryzyko można definiować jako przypadek, niebezpieczeństwo, możliwość lub sytuację występującą w projekcie z niepożądanymi konsekwencjami - potencjalny problem. Poziom ryzyka będzie określony prawdopodobieństwem wystąpienia zdarzenia i jego wypływem (możliwości uszkodzeń). Ryzyko w projekcie Ryzyko projektowe jest ryzykiem otaczającym zdolność projektu do dostarczenia określonych dla niego celów. Wyróżniamy: - czynniki dostawcy: - niemożność dostarczenia produktu/podzespołu przez zewnętrzną grupę - czynniki kontraktowe - czynniki organizacyjne: - brak umiejętności i ludzi - czynniki osobiste i treningi - czynniki polityczne takie jak problem z komunikacją, niemożność uczenia się na własnych błędach - niepoprawny odbiór lub oczekiwania względem testowania (np. brak doceniania wartości błędów znalezionych podczas testowania) - czynniki techniczne - problem ze zdefiniowaniem właściwych wymagań - zakres wymagań, który może zostać osiągnięty dla istniejących ram - jakość projektów, kodu i testów. Kiedy kierownik testów analizuje, zarządza i przeciwdziała ryzyku, wypełnia założenia zarządzania projektem. Norma IEEE 829 wymusza zawarcie w test planie informacji o potencjalnym ryzyku i jego konsekwencjach. Ryzyko produktu Potencjalne obszary występowania awarii (powodujące przyszłe niebezpieczeństwa) w oprogramowaniu lub systemie nazywane są ryzykiem produktu, gdyż są ryzykiem w odniesieniu do jakości produktu. Wyróżniamy następujące ryzyko produktu: - oprogramowanie dostarczone na rynek zawierające defekty powodujące awarie - potencjalne zagrożenia zranienia osoby lub wprowadzenie niebezpieczeństwa uszkodzeń wewnątrz organizacji - słabe parametry oprogramowania (np. funkcjonalność, bezpieczeństwo, niezawodność, użyteczność i wydajność) - oprogramowanie, które nie zachowuje się tak jak powinno (nie spełnia swoich założeń). Pojęcia ryzyka używa się dla zdecydowania gdzie zacząć testowanie i gdzie przetestować bardziej dogłębnie; testowanie jest używane do zredukowania ryzyka występowania niepożądanych efektów lub do zredukowania wpływu tych efektów. Ryzyko produktu jest specjalnym typem ryzyka do wsparcia sukcesy projektu. Testowanie jako kontrola ryzyka dostarcza informacji zwrotnej o pozostałym ryzyku poprzez miarę efektywności usuwania krytycznych błędów i planom ich zapobiegania. Metoda testowa oparta na ryzyku zawiera szanse (użyte od najwcześniejszych etapów projektu) przeciwdziałania błędom zanim się pojawią, a przez to zredukowania poziomu ryzyka. Zawiera ona identyfikację ryzyka produktu i zawarcie informacji o nim w planowaniu testów, specyfikacji i podczas przygotowania i wykonywania testów. Ryzyko to możemy użyć by określić: - używane techniki testowe - zakres testów - ważność poszczególnych testów w celu znalezieniu najbardziej krytycznych błędów we wczesnej fazie - czy czynności pozatestowe mogące zostać zaprzęgnięte by zredukować ryzyko (np. dostarczenie treningów dla niedoświadczonych architektów).
8 Testowanie oparte na ryzyku podsumowuje zebraną wiedzą i pokazuje udziałowcom ryzyko i poziom potrzebny do jego wyeliminowania. Dla zapewnienia, że szanse na awarie produktu są minimalne, czynności zarządzania ryzykiem dostarczają wsparcia w postaci: - oceny (regularnie powtarzanej), co może pójść źle (ryzyko) - określenia, z jakim ryzykiem i o jakiej ważności będziemy mieli do czynienia - wprowadzenia akcji do przeciwdziałania ryzyka. Dodatkowo, testowanie może wspierać identyfikację nowego ryzyka, może pomagać określić ryzyko, jakie można zredukować oraz może obniżyć niepewność w występowaniu ryzyka.
9 Zarządzanie przypadkami Jednym z celów testowania jest znajdywanie defektów, różnica między aktualnym i oczekiwanym wynikiem muszą zostać zakwalifikowane jako przypadki. Przypadek powinien być śledzony od momentu jego odkrycia aż po przedstawienie dla niego rozwiązania. W celu zarządzania przypadkami organizacja powinna ustanowić proces i zasady klasyfikacji przypadków. Przypadek może zostać dostrzeżony podczas czynności programistycznych, przeglądów, testowania lub użycia oprogramowania. Może być odniesiony do kodu lub do systemu, ale również do dokumentacji programistycznej, dokumentów testowych lub informacji dla użytkownika jak np. "Pomoc". Cele raportów o przypadkach: - dostarczyć programistom i innym uczestnikom informację zwrotną o problemach, aby wspomóc identyfikacją, izolacją i korekcją, gdy jest to konieczne - dostarczyć liderom testów narzędzi do śledzenia jakości systemu będącego testowanym i postępu w testowaniu - dostarczać pomysły dla poprawy procesu testowego. Tester lub osoba dokonująca przeglądu zazwyczaj zapisują następujące informacje o przypadkach: - data wykrycia, część organizacji gdzie został znaleziony przypadek, autor, potwierdzenie i status - zakres, negatywne konsekwencje i priorytet przypadku - referencje, zawierające, jaki przypadek testowy pozwolił wykryć problem. Szczegóły raportu o przypadku zawiera: - oczekiwany i aktualny rezultat - data, kiedy przypadek został wykryty - identyfikacja i konfiguracja oprogramowania lub systemu - cykl życia oprogramowania, w którym przypadek został zaobserwowany - opis anomalia dla wsparcia znalezienia rozwiązania - poziom wpływu na zainteresowanych udziałowców - negatywny wpływ na system - pilność/priorytet naprawy - status przypadku (np. otwarty, duplikat, czeka na naprawę, naprawiony - oczekujący na potwierdzenie, zamknięty) - konkluzje i rekomendacje - czynniki zewnętrzne, jak inne obszary mogące być zainfekowane zmianą wprowadzoną dla naprawy przypadku - historia zmian, jako sekwencja działań podjętych, przez członków zespołu projektowego, dla wyizolowania i naprawienia przypadku.
10 Modele tworzenia oprogramowania Testowanie nie jest czynnością wykonywaną w izolacji, jest powiązane z tworzeniem oprogramowania. Różne cykle tworzenia oprogramowania wymagają różnych metod testowych. Wodospad Model wodospadu w pełni oddaje pierwsze projekty informatyczne. Jest to prosta próba przedstawienia czynności w projekcie, gdzie dwie najważniejsze fazy: projektowanie i weryfikacja, następują po sobie. W uproszczeniu najpierw tworzony jest system lub oprogramowanie a dopiero potem następują testy. Model V Różne modele V testowe zostały opisane, ale można wyróżnić cztery poziomy testowe, powiązane z czterema poziomami rozwoju oprogramowania. Te poziomy to: - testy komponentów - testy integracji - testy systemu - testy potwierdzające. Czytaj więcej w artykule na stronie Model iteratywny Rozwój oprogramowania oparty na metodach iteratywnych jest procesem ustalania wymagań, projektowania, budowania i testowania systemu, wykonane przez podzielenie całego procesu na jego mniejsze elementy. Wyróżniamy dwa główne nurty: inkrementacji, czyli wzrostu poprzez dodawania małych cząstek oraz ewolucyjny, czyli stopniowy. Przykłady: procesy prototypowe, szybki rozwój aplikacji (ang. RAD), zunifikowany process firmy Rational (RUP), model Agile. Efekt iteracji może być testowany na różnych poziomach rozwoju oprogramowania. Elementy dodane do procesu wcześniej, tworzą cały system, który również musi zostać przetestowany. Szczególnie ważne jest testowanie regresyjne po każdej iteracji. Weryfikacja i walidacja może również być włączona w każdą inkrementacją. Testowanie w modelu cyklu życia W modelu cyklu życia, możemy wyróżnić parametry dobrego testowania: - dla każdej czynności programistycznej możemy wyróżnić odpowiadającą jej czynność testową - każdy poziom testowy ma cele specyficzne dla niego - analiza i projekt testów dla konkretnego poziomu powinien rozpoczynać się wraz z odpowiadającym mu poziomem programistycznym - tester powinien być zaangażowany w przegląd dokumentów od momentu pojawienia się ich pierwszych szkiców. Poziomy testowe mogą być łączone i reorganizowane w zależności od natury projektu lub architektury systemu. Przykładowo: integracja komercyjnego oprogramowania prosto z półki sklepowej z systemem, klient kupujący taki produkt sam wykonuje testy integracji w systemie (np. integracja z infrastrukturą i innymi systemami) i testy akceptacyjne (funkcjonalne i niefunkcjonalne)
11 Metodologie Agile - czyli metoda ułatwionego ruchu, bardziej dotyczy deweloperów, którym coraz bliżej do testerów XP - ekstremalne programowanie Test Driven Developmnet - czyli rozwój oprogramowania kierowany poprzez testy jest niesamowitym połączeniem testowania i programowania. Jest to zupełnie nowe podejście do tematu projektowania i zarządzania, który przestaje wreszcie tworzyć sztuczne granice między testerami i programistami. Drużyny tworzone w projektach łączą jednych i drugich w celu osiągnięcia właściwej jakość oprogramowania na czas. Ekspert tej techniki Jack Gansleyy powiedział/napisał: "Testowania i integracja nie są już osobnymi kamieniami milowymi projektu". TTD łączy w sobie dwie techniki testowania: - jednostki (unit) - testy białej skrzynki pisane i wykonywane przez programistów - akceptacji - testy czarnoskrzynkowe dla każdej części produktu tworzone przez ludzi związanych z zapewnieniem mu jak najwyższej jakości. Podstawowe hasło tej metody to: Testy na początku! Cykl testowania zintegrowany z programowaniem jest dość prosty: 1) Dodaj test 2) Wykonaj test i obserwuj przypadki negatywne 3) Dokonaj zmian 4) Wykonaj testy i obserwuj przypadki pozytywne 5) Przeanalizuj duplikaty i usuń RUP - zunifikowany proces firmy Rational RAD - szybki rozwój aplikacji Prototyping testowanie prototypów
Rozdział 5: Zarządzanie testowaniem. Pytanie 1
Pytanie 1 Dlaczego niezależne testowanie jest ważne: A) Niezależne testowanie jest w zasadzie tańsze niż testowanie własnej pracy B) Niezależne testowanie jest bardziej efektywne w znajdywaniu defektów
Bardziej szczegółowoMaciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoTestujemy dedykowanymi zasobami (ang. agile testers)
Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania
Bardziej szczegółowoUsługa: Testowanie wydajności oprogramowania
Usługa: Testowanie wydajności oprogramowania testerzy.pl przeprowadzają kompleksowe testowanie wydajności różnych systemów informatycznych. Testowanie wydajności to próba obciążenia serwera, bazy danych
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoZarządzanie testowaniem wspierane narzędziem HP Quality Center
Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe
Bardziej szczegółowoPYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoStrategia testów mająca doprowadzić do osiągnięcia pożądanych celów
Dokumentacja testowa. Plan testów [ang. Test Plan] Plan testów jest jednym z podstawowych dokumentów w procesie testowym. Przedstawiamy wzór planu testów. testerzy.pl Zapraszamy do dyskusji o planie testów
Bardziej szczegółowoAutor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski
Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoTestowanie i walidacja oprogramowania
i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja
Bardziej szczegółowoFeature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
Bardziej szczegółowoStudia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW
01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO
Bardziej szczegółowoTestowanie oprogramowania. Piotr Ciskowski
Testowanie oprogramowania Piotr Ciskowski TESTOWANIE testowanie o proces eksperymentalnego badania programu lub jego komponentu o próbne wykonanie w znanych warunkach o rejestrowanie wyników o ocena właściwości
Bardziej szczegółowoUsługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Bardziej szczegółowoSzczegółowy plan szkolenia
Szczegółowy plan szkolenia ISTQB Advanced Level Syllabus Test Manager (version 2012) (19 October 2012) Harmonogram zajęć (5 dni szkoleniowych: 9:00 17:00) Dzień 1. 0. Wprowadzenie do syllabusa poziom zaawansowany
Bardziej szczegółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie x 1 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoDlaczego testowanie jest ważne?
Testowanie Dlaczego testowanie jest ważne? Oprogramowanie które nie działa poprawnie może doprowadzić do: straty czasu, pieniędzy utraty reputacji uszkodzeń ciała a nawet śmierci Definicja błędu Oprogramowanie
Bardziej szczegółowoTestowanie oprogramowania
Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój
Bardziej szczegółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
Bardziej szczegółowoPraktyka testowania dla początkujących testerów
Praktyka testowania dla początkujących testerów Warsztaty stanowią 100% praktykę testowania i skupiają się zwłaszcza na tych aspektach, które przydatne są w codziennej pracy testera. Przeznaczone są dla
Bardziej szczegółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoNajwyżej ocenione raporty dla Mr Buggy 4
Najwyżej ocenione raporty dla Mr Buggy 4 Uwagi Komisji: 1. Żaden z raportów nie otrzymał maksymalnej liczby punktów. 2. Poniżej prezentowane są oryginalne wersje raportów z usuniętymi danymi mogącymi identyfikować
Bardziej szczegółowoPriorytetyzacja przypadków testowych za pomocą macierzy
Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
Bardziej szczegółowo<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą
Bardziej szczegółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Bardziej szczegółowoGłówne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)
Extreme programming Główne założenia XP Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Praktyki Planowanie: Planowanie releasu Planowanie iteracji
Bardziej szczegółowo1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.
1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology
Bardziej szczegółowoPiotr Ślęzak. Gdzie się podziała jakość
Piotr Ślęzak Gdzie się podziała jakość Działamy na styku Biznesu i IT Analiza biznesowa Kontrola jakości Doradztwo Projekty Szkolenia ForProgress spółka z ograniczoną odpowiedzialnością sp.k. kontakt@forprogress.com.pl
Bardziej szczegółowoBezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora
Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania
Bardziej szczegółowoZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.
ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. Na szkolenie zapraszamy: testerów kierowników działów testowych analityków systemowych
Bardziej szczegółowoŚCIEŻKA: Zarządzanie projektami
ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom
Bardziej szczegółowoUsprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.
Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja
Bardziej szczegółowoCertified IT Manager Training (CITM ) Dni: 3. Opis:
Kod szkolenia: Tytuł szkolenia: HK333S Certified IT Manager Training (CITM ) Dni: 3 Opis: Jest to trzydniowe szkolenie przeznaczone dla kierowników działów informatycznych oraz osób, które ubiegają się
Bardziej szczegółowoISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania
ISO 9000/9001 Jarosław Kuchta Jakość Oprogramowania Co to jest ISO International Organization for Standardization największa międzynarodowa organizacja opracowująca standardy 13700 standardów zrzesza narodowe
Bardziej szczegółowoZarządzanie projektami. Wykład 2 Zarządzanie projektem
Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów
Bardziej szczegółowoPLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji
Bardziej szczegółowoAUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7
AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli
Bardziej szczegółowoEgzamin ITIL Foundation
Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.
Bardziej szczegółowoOpis Kompetencji Portfel Interim Menedżerowie i Eksperci
Opis Kompetencji Portfel Interim Menedżerowie i Eksperci Warszawa, kwiecień 2012 r. Carrywater Group S.A. www.carrywater.com Al. Jerozolimskie 65/79, 00-697 Warszawa, Centrum LIM, piętro XIV, lok. 14.07
Bardziej szczegółowoProgramowanie zespołowe
Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof
Bardziej szczegółowoProjekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011
Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo
Bardziej szczegółowoOptymalizacja Automatycznych Testów Regresywnych
Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoDLA SEKTORA INFORMATYCZNEGO W POLSCE
DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej
Bardziej szczegółowo1
Wprowadzenie 0.1 Postanowienia ogólne Wprowadzenie 0.1 Postanowienia ogólne Wprowadzenie 0.1 Postanowienia ogólne 0.2 Podejście procesowe 0.2 Zasady zarządzania jakością 0.2 Zasady zarządzania jakością
Bardziej szczegółowoAcceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki
Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja
Bardziej szczegółowoWZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends
Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji dr inż. Bolesław Szomański Wydział Zarządzania Politechnika Warszawska b.szomański@wz.pw.edu.pl Plan Prezentacji
Bardziej szczegółowoZwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow)
Program szkolenia: Zwinna współpraca programistów i testerów z wykorzystaniem BDD i Spec Informacje: Nazwa: Kod: Kategoria: Grupa docelowa: Czas trwania: Forma: Zwinna współpraca programistów i testerów
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków
Bardziej szczegółowoISO 9001:2015 przegląd wymagań
ISO 9001:2015 przegląd wymagań dr Inż. Tomasz Greber (www.greber.com.pl) Normy systemowe - historia MIL-Q-9858 (1959 r.) ANSI-N 45-2 (1971 r.) BS 4891 (1972 r.) PN-N 18001 ISO 14001 BS 5750 (1979 r.) EN
Bardziej szczegółowoTester oprogramowania 2014/15 Tematy prac dyplomowych
Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven
Bardziej szczegółowot e s t o w a n i e j e s t ł a t w e
testerzy.pl Podstawą tego rozdziału jest Foundation Level Syllabus wydany przez ISTQB. Poziomy testowania Dla każdego poziomu testowania możemy wyróżnić: - ogólny cel - odnośnik do tworzenia przypadków
Bardziej szczegółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoKrzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014
1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)
Bardziej szczegółowoSzkolenie: Automatyzacja testowania
Szkolenie: Automatyzacja testowania Wiele osób rozpoczyna swoją przygodę z automatyzacją od nauki jednego narzędzia. Niniejsze szkolenie pokazuje wielowymiarowość automatyzacji jako złożonego procesu,
Bardziej szczegółowoTestowanie oprogramowania. Testowanie oprogramowania 1/34
Testowanie oprogramowania Testowanie oprogramowania 1/34 Testowanie oprogramowania 2/34 Cele testowania testowanie polega na uruchamianiu oprogramowania w celu wykrycia błędów, dobry test to taki, który
Bardziej szczegółowoMSF. Microsoft Solution Framework
MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie
Bardziej szczegółowoSkuteczne zarządzanie projektami IT w otoczeniu uczelnianym. Piotr Ogonowski
Skuteczne zarządzanie projektami IT w otoczeniu uczelnianym Piotr Ogonowski Agenda Najważniejsze elementy organizacji projektowej Agile czy klasycznie? Jak wdrożyć podejście projektowe na Uczelni? Kluczowe
Bardziej szczegółowoRyzyko w świetle nowych norm ISO 9001:2015 i 14001:2015
Ryzyko w świetle nowych norm ISO 9001:2015 i 14001:2015 Rafał Śmiłowski_04.2016 Harmonogram zmian 2 Najważniejsze zmiany oraz obszary Przywództwo Większy nacisk na top menedżerów do udziału w systemie
Bardziej szczegółowoSpis treści. Przedmowa Karolina Zmitrowicz, Adam Roman. Część I. Organizacja i procesy 1
Testowanie oprogramowania w praktyce : studium przypadków 2.0 / redakcja naukowa Adam Roman, Karolina Zmitrowicz ; Wojciech Anzel [i 11 pozostałych]. Warszawa, 2018 Spis treści Przedmowa Karolina Zmitrowicz,
Bardziej szczegółowoCzęść I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA
CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia
Bardziej szczegółowoInżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.
Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.
Bardziej szczegółowoWstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań
Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec
Bardziej szczegółowoTeam Prevent Poland Sp. z o.o. Graficzna prezentacja struktury ISO 9001:2015 i IATF 16949:2016
Graficzna prezentacja struktury ISO 9001:2015 i 16949:2016 Struktura ISO 9001:2015 ISO 9001:2015 4. Kontekst organizacji 5. Przywództwo 6. Planowanie 7. Wsparcie 8. Działania operacyjne 9. Ocena efektów
Bardziej szczegółowoZARZĄDZANIE RYZYKIEM W LABORATORIUM BADAWCZYM W ASPEKCIE NOWELIZACJI NORMY PN-EN ISO/ IEC 17025:
ZARZĄDZANIE RYZYKIEM W LABORATORIUM BADAWCZYM W ASPEKCIE NOWELIZACJI NORMY PN-EN ISO/ IEC 17025:2018-02 DR INŻ. AGNIESZKA WIŚNIEWSKA DOCTUS SZKOLENIA I DORADZTWO e-mail: biuro@doctus.edu.pl tel. +48 514
Bardziej szczegółowoAL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2
AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2 1. Definicja projektu: cechy projektu, przyczyny porażek projektów, czynniki sukcesu projektów, cele projektu, produkty projektu, cykl życia
Bardziej szczegółowoSzablon Planu Testów Akceptacyjnych
Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia
Bardziej szczegółowoWarsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni
Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi
Bardziej szczegółowo!!!!!!!!!!! PORTFOLIO: Analiza zachowań użytkowników serwisów internetowych. Autorzy: Marek Zachara
PORTFOLIO: Analiza zachowań użytkowników serwisów internetowych Autorzy: Marek Zachara Opis merytoryczny Cel naukowy (jaki problem wnioskodawca podejmuje się rozwiązać, co jest jego istotą, co uzasadnia
Bardziej szczegółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz
Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie. x 3 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoInżynieria Programowania Zarządzanie projektem
Inżynieria Programowania Zarządzanie projektem Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 12 października 2015 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4
Bardziej szczegółowoZarządzanie projektami a zarządzanie ryzykiem
Ewa Szczepańska Zarządzanie projektami a zarządzanie ryzykiem Warszawa, dnia 9 kwietnia 2013 r. Agenda Definicje Wytyczne dla zarządzania projektami Wytyczne dla zarządzania ryzykiem Miejsce ryzyka w zarządzaniu
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoWprowadzenie do systemów informacyjnych
Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj
Bardziej szczegółowoWykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą
Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca
Bardziej szczegółowoWszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.
Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym
Bardziej szczegółowoLeszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.
Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration
Bardziej szczegółowoMetodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV
Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie
Bardziej szczegółowoDni: 3. Opis: Adresaci szkolenia
Kod szkolenia: Tytuł szkolenia: ISTQB/TTA ISTQB - Technical Test Analyst Dni: 3 Opis: Adresaci szkolenia Szkolenie jest skierowane do testerów posiadających certyfikat ISTQB Certified Tester przynajmniej
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny
Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoSYSTEMY INFORMATYCZNE ćwiczenia praktyczne
SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego
Bardziej szczegółowoJak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style
Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów
Bardziej szczegółowoIO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................
Bardziej szczegółowoNarzędzia informatyczne wspierające przedsięwzięcia e-commerce
Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza
Bardziej szczegółowoPoniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.
ZARZĄDZANIE PROJEKTAMI JAK ZAKOŃCZYĆ PROJEKT Z SUKCESEM Beata Kozyra 2018 2 dni Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji. Każdy projekt musi mieć cel, który można zmierzyć,
Bardziej szczegółowoProjektowanie Infrastruktury Sieciowej v2 2012/09/01
Projektowanie Infrastruktury Sieciowej v2 2012/09/01 www.netcontractor.pl Wstęp Era nowych technologii umożliwiła praktycznie nieograniczone możliwości komunikacji niezależenie od miejsca i czasu. Dziś
Bardziej szczegółowoZarządzanie projektami. Porównanie podstawowych metodyk
Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled
Bardziej szczegółowoStudia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW
01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe ZARZĄDZANIE SERWISEM IT PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe ZARZĄDZANIE SERWISEM IT Semestr 1 Moduły
Bardziej szczegółowoZarządzanie projektami w otoczeniu uczelnianym. Piotr Ogonowski
Zarządzanie projektami w otoczeniu uczelnianym Piotr Ogonowski 1 Agenda Kluczowe elementy organizacji projektowej Jak wdrożyć organizację projektową na uczelni? Dobre praktyki z wdrożeń W czym pomoże nam
Bardziej szczegółowoWybór ZSI. Zakup standardowego systemu. System pisany na zamówienie
Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę
Bardziej szczegółowoMałopolska Agencja Rozwoju Regionalnego S.A.
Małopolska Agencja Rozwoju Regionalnego S.A. Przestrzeń Twojego sukcesu! Projekt Określone w czasie działanie podejmowane w celu stworzenia niepowtarzalnego produktu lub usługi Projekt - cechy słuŝy realizacji
Bardziej szczegółowoSzkolenie: Dobry Kierownik Testów
Szkolenie: Dobry Kierownik Testów Nawet najlepsi testerzy nie będą pracować wydajnie jeśli ich zespołem nie będzie kierował odpowiednio do tego przygotowany lider. To właśnie na barkach menedżera spoczywa
Bardziej szczegółowo