what are iq oq pq 3 q s software validation process
Wprowadzenie do IQ-OQ-PQ:
IQ, OQ i PQ stanowią 3Q procesu walidacji oprogramowania.
Jako testerzy wszyscy wiemy, że zespół programistyczny opracowuje oprogramowanie we własnym zakresie zgodnie ze specyfikacją wymagań oprogramowania (SRS), specyfikacją funkcjonalną, a później zespół testowy weryfikuje implementację na różnych poziomach testowania w różnych środowiskach testowych, od najprostszych do high end, który w ten sposób powiela środowisko produkcyjne.
Dzięki takiemu podejściu SDLC, zespół programistyczny zmywa ręce, przekazując gotowe oprogramowanie (opracowane i zweryfikowane) zespołowi operacyjnemu. Co więcej, to zespół operacyjny (ogólnie nazywany zespołem operacyjnym) zajmuje się wdrażaniem go w środowisku produkcyjnym i przygotowaniem do użycia przez użytkowników końcowych.
Oto prawdziwe wyzwanie dla Zespołu Operacyjnego, aby oprogramowanie działało w środowisku produkcyjnym, ponieważ podczas faz rozwoju oprogramowania, rozwój i weryfikacja odbywały się w symulowanym środowisku, rzadko zbliżonym do środowiska na żywo, tylko w przypadku dostępności danych i konfiguracji środowiska produkcyjnego.
W tym miejscu pojawia się walidacja oprogramowania. Po zakończeniu weryfikacji i podpisaniu oprogramowania przez zespół ds. Programu / produktu, zespół operacyjny przeprowadzi szereg działań przed zaakceptowaniem oprogramowania do wdrożenia w produkcji, aby udowodnić, że oprogramowanie zachowuje się zgodnie z oczekiwaniami, co to nic innego jak czynności walidacyjne.
Czego się nauczysz:
Weryfikacja a walidacja
W tym miejscu jasno zrozumiemy różnicę między działaniami „Weryfikacja” i „Walidacja”. ' Weryfikacja ”Polega na ocenie oprogramowania pod kątem danego zestawu wymagań i specyfikacji, która jest wykonywana na miejscu w witrynie rozwoju oprogramowania przez programistów i testerów.
Natomiast ' Uprawomocnienie ”To zestaw kontroli jakości, które są przeprowadzane przez klientów zewnętrznych, właścicieli, sprzedawców dostarczanego im produktu w celu sprawdzenia przydatności produktu przed przyjęciem lub zakupem produktu. Działania walidacyjne są przeważnie prowadzone w zakładzie produkcyjnym.
Stąd w przypadku tworzenia aplikacji to zespół operacyjny wykonuje czynności walidacyjne dla oprogramowania.
Przeczytaj także:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Fazy procesu walidacji
Ogólnie rzecz biorąc, proces walidacji dowolnego produktu odnosi się do pełnego cyklu życia produktu od jego opracowania, przez użytkowanie i konserwację. Dlatego proces walidacji jest podzielony na 5 faz.
5 faz procesu walidacji to:
To pięciofazowe podejście do procesu walidacji jest stosowane w wielu branżach, takich jak produkcja, medycyna, farmacja itp. W tym przypadku klient końcowy przeprowadzi walidację przed zakupem maszyn, sprzętu lub produktu.
Elementy działań walidacyjnych oprogramowania mają na celu udowodnienie, że „oprogramowanie jest gotowe do spożycia przez użytkowników”, a przede wszystkim zweryfikowanie pomyślnej instalacji oprogramowania, a następnie jego funkcjonalności i operatywności.
Podejście 3Q: IQ-OQ-PQ
Jednak w kontekście oprogramowania Podejście 3Q, IQ-OQ-PQ jest realizowany w ramach walidacji i zostanie przeprowadzony przez zespół operacyjny, który jest ostatecznie odpowiedzialny za wdrożenie oprogramowania do produkcji.
Poniżej przedstawiono schemat przebiegu procesu walidacji:
Szablon, plan i wszelkie inne dokumenty, które są wkładane do przeprowadzenia 3Q, zostaną opracowane przez zespół ds. Oprogramowania dla ich oprogramowania i obejmują szczegółowe podejście, zadania / czynności / testy do przeprowadzenia w ramach tych kwalifikacji wraz z z wynikami testu.
Raporty podsumowujące zostaną przekazane zespołowi operacyjnemu podczas przekazywania oprogramowania wraz z plikami binarnymi i innymi produktami.
Na wysokim poziomie
Ogólnie rzecz biorąc, celem przeprowadzenia IQ, OQ i PQ jest zapewnienie, że oprogramowanie może zostać pomyślnie wdrożone, a wszystkie funkcje mogą być używane bez żadnych wąskich gardeł.
W idealnym przypadku IQ, OQ i PQ są sekwencyjnymi czynnościami, które należy wykonać w kolejności. Dopóki instalacja nie zostanie zakończona, funkcjonalność oprogramowania nie może zostać zweryfikowana, a pomiar wydajności nie ma sensu, chyba że funkcjonalność zostanie udowodniona. Czasami ze względu na ograniczenia czasowe, PQ może rozpocząć się równolegle do OQ, po ustaleniu kluczowych aspektów OQ.
Teraz przyjrzyjmy się szczegółowo każdej z tych 3 faz.
Kwalifikacja instalacyjna (IQ)
Kwalifikacja instalacyjna zwana również 'ILORAZ INTELIGENCJI' , to proces sprawdzania, czy dostarczone oprogramowanie (pliki binarne, skrypty itp.) można pomyślnie zainstalować w określonym środowisku z określonymi konfiguracjami oraz w celu sprawdzenia, w jaki sposób te kroki instalacji są zapisane w dokumencie o nazwie „Podręcznik instalacji”.
Następujące elementy są dostarczane przez zespół programistów wraz z dostarczonym pakietem oprogramowania i są używane przez zespół operacyjny do przeprowadzania IQ.
1) Dokument „Podręcznik instalacji”, który dokumentuje kroki instalacji w wybranych środowiskach.
dwa) Dokument „Przewodnik po konfiguracji” umożliwiający skonfigurowanie oprogramowania. Czasami ten dokument staje się częścią samego dokumentu Podręcznik instalacji.
3) Pakiet oprogramowania i skrypty instalacyjne, najlepiej skrypty automatyczne.
Faza kwalifikacji instalacji oprogramowania jest uważana za najważniejszą i zazwyczaj obejmuje wiele problemów otwarty w tej fazie.
Dlatego:
do) Środowisko programistyczne nie będzie miało dostępnego w 100% środowiska czasu rzeczywistego do weryfikacji problemów z instalacją, a zatem różnica w środowisku przyczynia się do kilku problemów.
b) Z różnych powodów współpraca i koordynacja między zespołem deweloperskim a zespołem operacyjnym na początkowych etapach tworzenia oprogramowania może być niewystarczająca, aby rozwiązać problemy z dużym wyprzedzeniem.
do) Podczas rejestrowania rzeczywistych kroków instalacji w dokumencie mogą wystąpić problemy z dokumentacją, które mogą nie odpowiadać dokładnie w środowisku produkcyjnym.
Obecnie cała procedura instalacji oprogramowania zostanie zautomatyzowana w jak największym stopniu za pomocą szeregu skryptów. Jeśli wystąpią jakiekolwiek problemy z instalacją, automatyczna instalacja zakończy się niepowodzeniem z powodu jakichkolwiek nieprawidłowości w konfiguracji i wymagana jest ręczna interwencja w celu rozwiązania tych problemów.
Ponieważ zespół Ops przeprowadza IQ, ściśle przestrzegając instrukcji dostarczonych przez zespół ds. Oprogramowania w przewodniku instalacji, bardzo ważne jest, a także odpowiedzialność zespołu ds. Oprogramowania, dopilnowanie, aby „Podręcznik instalacji” był napisany w taki sposób, aby kroki instalacji są dopasowane do środowiska czasu rzeczywistego.
Na testerach spoczywa obowiązek upewnienia się, że proces `` instalacji '' został zweryfikowany na miejscu wraz z weryfikacją dokumentów pod kątem jego kompletności oraz zidentyfikowanie wszelkich niezgodności z faktycznymi krokami, które należy wykonać w systemie, z krokami udokumentowanymi w Podręcznik instalacji.
Podczas pisania instrukcji instalacji i weryfikacji ich we własnym zakresie należy pamiętać o następujących kwestiach, aby zminimalizować problemy podczas instalacji oprogramowania na produkcji.
SNO | Punkty przewodnika instalacji |
---|---|
7 | Typowy czas potrzebny na zainstalowanie oprogramowania powinien być wymieniony w Przewodniku instalacji dla zespołu operacyjnego, aby mieć pojęcie o przybliżonym czasie instalacji i odpowiednio zaplanować swoje działania. |
1 | Najważniejszy i najważniejszy, „Podręcznik instalacji” powinien być napisany prostym i łatwym do zrozumienia językiem. |
dwa | Trzeba się upewnić, że nie zajmie to dużo, więcej niż 5 stron. Powinien być krótki i schludny. |
3 | Konieczność podania numerów seryjnych dla każdego kroku wykonania w celu śledzenia jego statusu. |
4 | Zautomatyzuj kroki w jak największym stopniu i połącz je wszystkie w jeden skrypt. |
5 | Do napisania procedury instalacji należy użyć standardowego szablonu. |
6 | Należy jasno określić warunki wstępne, aby uniknąć niedopasowania, a także zapewnić kroki w celu ich weryfikacji. W przypadku niezgodności należy dostarczyć instrukcję, aby podnieść je do oczekiwanego poziomu lub zainstalować te pakiety. |
8 | Usługi, które muszą zostać wyłączone podczas instalacji, jak je wyłączyć, wpływ ich wyłączenia, muszą być wyraźnie wymienione w przewodniku. |
9 | Należy unikać podawania linków do innych dokumentów i przechodzenia z jednego dokumentu do drugiego. Każda potrzebna informacja powinna być udostępniona w tym samym dokumencie. Jeśli konieczne jest odniesienie do dodatkowych dokumentów, dostarcz je wraz z pakietem oprogramowania, a z kolei należy się do nich odwołać w głównych dokumentach. |
10 | Należy upewnić się, że nazwa skryptu wymieniona w dokumencie jest taka sama, jak ta, która znajduje się w pakiecie z plikiem binarnym. |
jedenaście | Powinien zapewnić, że wszystkie skrypty, o których mowa w przewodniku instalacji, są dostarczane wraz z plikiem binarnym. |
12 | Upewnij się, że wszystkie parametry konfiguracyjne są wyraźnie wymienione w Podręczniku instalacji / Podręczniku konfiguracji wraz z wartościami domyślnymi i innymi obsługiwanymi wartościami. |
13 | Należy dostarczyć testy automatyczne do przeprowadzania testów weryfikujących kompilację po zakończeniu instalacji oprogramowania. Muszą być minimalne i ważne, aby sprawdzić, czy kompilacja została pomyślnie zainstalowana. |
14 | Należy zapewnić „testy dymu”, aby upewnić się, że łączność między końcami systemu jest doskonała, a wszystkie elementy systemu komunikują się ze sobą zgodnie z oczekiwaniami. |
piętnaście | W przypadku niepowodzenia instalacji oprogramowania, skrypty przywracania są dostarczane wraz z pakietem, a procedura przywracania jest jasno opisana w Przewodniku instalacji, aby przeprowadzić przywracanie i przywrócić system. |
Biorąc pod uwagę wszystkie powyższe punkty, najlepszą praktyką jest automatyzacja procesu instalacji oprogramowania przy minimalnej interwencji człowieka w celu uniknięcia błędów ludzkich.
Jeśli w fazie walidacji IQ zostaną znalezione jakiekolwiek problemy, zostaną one zgłoszone zespołowi ds. Oprogramowania, po którego naprawieniu, testy dymu i testy weryfikacyjne konstrukcji zostanie przeprowadzona, aby sprawdzić powodzenie instalacji oprogramowania.
Stąd faza IQ obejmuje instalację pakietu oprogramowania, a następnie przeprowadzenie weryfikacji kompilacji i testów dymnych.
Dlatego pomyślne zakończenie fazy IQ jest bardzo ważne, ponieważ pomyślna i prawidłowa instalacja oprogramowania zapewnia, że większość problemów związanych z awariami funkcjonalności jest zanegowana.
Kwalifikacja operacyjna (OQ)
Kwalifikacja operacyjna, zwana także as CO to kolejna czynność w procesie walidacji oprogramowania po pomyślnym zakończeniu IQ.
Kwalifikacja operacyjna obejmuje t Testy do uruchomienia w celu sprawdzenia, czy oprogramowanie jest funkcjonalnie zdatne do wdrożenia u konsumentów. W idealnym przypadku kluczowe funkcjonalności oprogramowania są weryfikowane w ramach tego procesu walidacji.
Plan OQ dotyczący przeprowadzenia walidacji OQ musi zostać przygotowany przez zespół oprogramowania (testerów), który powinien obejmować wszystkie aspekty testów OQ, które należy przeprowadzić, w tym szczegóły takie jak nr. testów, harmonogramu testów, metodologii, narzędzi, wpływu na usługę, kolejności wykonywania testów, sposobu zgłaszania problemów i umów SLA ich naprawiania, podejścia Defect Triage itp.,
Operacyjne testy kwalifikacyjne, które są przeprowadzane w ramach OQ, są ponownie dostarczane przez zespół ds. Oprogramowania wraz z oprogramowaniem. Te operacyjne testy kwalifikacji stanowią zbiór ważnych testów, które zostały zaprojektowane na podstawie dokumentu „Specyfikacje wymagań funkcjonalnych”, aby zapewnić, że cały system oprogramowania działa zgodnie z oczekiwaniami.
Niniejszy dokument specyfikacji testu OQ jest przygotowywany przez inżynierów testów na podstawie dokumentu specyfikacji wymagań funkcjonalnych. Często dokument ten będzie podzbiorem dokumentu specyfikacji testów systemu przygotowanego i zweryfikowanego podczas fazy testowania systemu SDLC.
Testy mogą być zmieniane lub aktualizowane w celu dostosowania do wymagań Zespołu Operacyjnego i warunków miejsca, w którym będą wykonywane.
Dlatego należy zachować dodatkową ostrożność przy wyborze testów, które są częścią OQ, aby zapewnić, że wszystkie kluczowe funkcjonalności i główne przepływy pracy są uwzględnione w tej weryfikacji.
Poniżej znajdują się wskazówki dla Testerów podczas przygotowywania dokumentu specyfikacji testu OQ.
Sno | Wskazówki dla testerów podczas przygotowywania dokumentu specyfikacji testu OQ |
---|---|
7 | Przypadki testowe związane z wartością graniczną nie muszą być uwzględniane, co weryfikuje wartości ekstremalne, ale używa najczęściej używanych codziennie wartości jako danych wejściowych, gdziekolwiek jest to wymagane. |
1 | Upewnij się, że kluczowe testy funkcjonalności w celu udowodnienia, że funkcje oprogramowania zostały wybrane i uwzględnione zgodnie z oczekiwaniami, a zatem niezbędna identyfikowalność dla każdego z pisemnych przypadków testowych jest dostępna w dokumencie specyfikacji testów OQ. |
dwa | Upewnij się, że testy są starannie napisane krok po kroku, są zrozumiałe i zrozumiałe dla zwykłego człowieka. |
3 | Nie odwołuj się ani nie unikaj używania jakichkolwiek terminów technicznych w przypadkach testowych tak bardzo, jak to możliwe, ponieważ użytkownik tego dokumentu może nie wiedzieć o tych terminach. E że użyte dane testowe nie istnieją już w systemie. Podaj wiele zestawów danych na wypadek, gdyby użytkownik chciał wykonać przypadki testowe więcej niż raz. |
4 | Wyraźnie opisz obowiązkowe i opcjonalne wymagania wstępne dla każdego z testów. |
5 | Uwzględnij większość pozytywnych przypadków testowych, aby zweryfikować funkcjonalność. |
6 | Uwzględnij bardzo niewiele negatywnych przypadków testowych, aby upewnić się, że zachowanie oprogramowania jest zgodne z oczekiwaniami w przypadku nieistotnych danych wejściowych, a system jest w stanie pomyślnie obsłużyć negatywne przypadki. |
8 | Podaj wartości konfiguracyjne, które mają zostać ustawione, jeśli trzeba je zmienić z wartości domyślnych. |
9 | Dostarcz zautomatyzowane przypadki testowe do uruchomienia, jeśli są dostępne. Upewnij się wcześniej, że te skrypty automatyzacji można uruchomić w systemie, w którym planowane jest OQ. |
10 | Upewnij się, że każdy przypadek testowy zawiera jasne „oczekiwane” i „rzeczywiste” wyniki jako odniesienie. W razie potrzeby dodaj komentarze, aby wyjaśnić rzeczywisty wynik. |
jedenaście | Konieczne jest również uwzględnienie „Kryteriów akceptacji” dla każdego z przypadków testowych. Kryteriami akceptacji może być stan systemu po wykonaniu przypadków testowych. |
12 | Podaj dokładnie „Dane testowe”, które mają być wykorzystane w każdym z testów. Spróbuj dostarczyć najczęstsze dane z transmisji na żywo. A także kilka wyjątkowych danych, aby upewnić się, że system poradzi sobie również z wyjątkowymi przypadkami. Upewnij się, że użyte dane testowe nie istnieją już w systemie. Podaj wiele zestawów danych na wypadek, gdyby użytkownik chciał wykonać przypadki testowe więcej niż raz. |
13 | Jeśli wielu użytkowników operacyjnych równolegle przeprowadza testy z różnych lokalizacji, należy podać instrukcję przeprowadzania testów zgodnie z innym zestawem danych. |
14 | Zapewnij listy kontrolne tam, gdzie jest to wymagane, aby upewnić się, że wszystkie konfiguracje i wymagania wstępne są ustawione zgodnie z oczekiwaniami przed uruchomieniem testów. |
piętnaście | Kontynuuj monitorowanie dzienników, gdy testy są uruchomione, czy dostęp do systemu jest możliwy. |
16 | Jeśli to możliwe i wymagane, zapewnij wsparcie wykonawcze użytkownikom operacyjnym podczas wykonywania tych przypadków testowych. |
17 | Wyjaśnij metodę zgłaszania problemów znalezionych podczas wykonywania. Lepiej jest użyć narzędzia do śledzenia błędów, aby śledzić problemy. Uważnie monitoruj każdy problem i zamknij go zgodnie z ustalonymi umowami SLA. |
18 | Uruchamiaj „Segmenty defektów” z udziałem zainteresowanych stron, aby zrozumieć krytyczne i poważne problemy i często dostarczać aktualizacje dotyczące tych problemów. |
19 | Dostarcz ostateczny szablon „Raportu podsumowującego wykonanie testu OQ”, aby opublikować ostateczne wyniki po zakończeniu wykonania. |
Tak przygotowany plan OQ i specyfikacja testów powinny zostać dokładnie przeanalizowane i zatwierdzone przez odpowiednich interesariuszy, aby głównie upewnić się, że pokrycie nie jest zbyt małe lub zbyt duże, a wszystkie kluczowe funkcje są objęte.
Pomyślne zakończenie OQ pokazuje, że oprogramowanie będzie działało zgodnie ze swoimi specyfikacjami operacyjnymi w wybranym środowisku i jest bramą do przejścia oprogramowania w kierunku jego produkcji i jest sygnałem do rozpoczęcia kolejnego działania w procesie walidacji, jakim jest PQ .
Kwalifikacja wydajności (PQ)
Po zapewnieniu pomyślnego IQ, kolejnym działaniem w procesie walidacji jest zakończenie przez OQ, czy produkt / oprogramowanie spełnia określone aspekty wydajności pod spodziewanym obciążeniem, bez powodowania wąskiego gardła w środowisku produkcyjnym.
Kluczowym aspektem PQ jest zapewnienie, że oprogramowanie po zainstalowaniu w oczekiwanym systemie radzi sobie z obciążeniem na żywo i spełnia oczekiwany czas reakcji i nie ulega awarii pod szczytowymi obciążeniami i stresem podczas obsługi jednoczesnych użytkowników.
Stąd PQ ma głównie na celu zapewnienie, czy określone kryteria wydajności dla oprogramowania są osiągane przez pewien okres czasu (może tydzień) w sposób wiarygodny przy zmieniających się warunkach obciążenia, jak to ma miejsce na żywo. W związku z tym testy te muszą być przeprowadzane codziennie, aby monitorować zachowanie systemu oprogramowania, a zatem wykonanie PQ zajmie trochę czasu, zanim zostanie upewnione, że system jest sprawdzony pod względem wydajności.
W idealnym przypadku walidacja PQ jest przeprowadzana po zakończeniu OQ, gdzie zapewniona jest funkcjonalność oprogramowania i może być kontynuowana weryfikacja aspektu wydajności produktu lub oprogramowania. Czasami ze względu na ograniczenia czasowe, PQ może rozpocząć się równolegle do OQ, w oparciu o pewność procentową ukończenia OQ.
Idealnym rozwiązaniem jest przeprowadzenie tych testów wydajności w systemie na żywo z systemem w pełni obciążonym lub w warunkach podobnych do rzeczywistych i upewnienie się, że nie ma wąskich gardeł w aspektach wydajności.
Poniższe testy są generalnie przeprowadzane w ramach kwalifikacji wydajności. A wybór testów różni się w zależności od oprogramowania.
# 1) Test dostępności: Aby upewnić się, że oprogramowanie jest stale dostępne bez awarii lub awarii.
# 2) Test dostępności: Aby zapewnić, że oprogramowanie jest łatwo dostępne z każdej lokalizacji przy oczekiwanej szybkości działania bez żadnych problemów.
# 3) Test obciążenia: Aby zmierzyć zachowanie systemu w przewidywanym codziennym obciążeniu, a także w warunkach obciążenia szczytowego.
# 4) Test warunków skrajnych: Do pomiaru punktu przerwania systemu w ekstremalnych warunkach obciążenia.
# 5) Test wydajności przepustowości: Do pomiaru czasu odpowiedzi systemu i pomiaru TPS (transakcji na sekundę)
# 6) Testowanie skalowalności: System można skalować w celu obsługi spodziewanych jednoczesnych użytkowników.
Scenariusze testów wydajnościowych i odpowiadające im automatyczne skrypty są przygotowywane na podstawie wymagań związanych z wydajnością, określonych w dokumentach „Specyfikacja wymagań użytkownika”.
Podobnie jak w przypadku planu OQ, szczegółowy plan PQ, który jasno określa podejście do testowania, strategię, plan i harmonogram wraz z narzędziami, powinien zostać przygotowany i omówiony z wykonawcami PQ.
Narzędzie do testowania i monitorowania wydajności należy zainstalować w środowisku, w którym przeprowadzane jest PQ w celu pomiaru i raportowania wskaźników wydajności.
Poniżej znajdują się wskazówki dla testerów, aby umożliwić zespołowi operacyjnemu pomyślne przeprowadzenie PQ.
Sno | Wskazówki dla testerów dotyczące włączenia zespołu operacyjnego |
---|---|
7 | Prowadzić, wspierać i szkolić zespół operacyjny w zakresie przeprowadzania testów wydajnościowych w systemie. |
1 | Przygotuj kluczowe scenariusze specyficzne dla biznesu, aby przeprowadzić testy wydajnościowe w oparciu o URS. |
dwa | Upewnij się, że uwzględniono testy, aby udowodnić, że system spełnia oczekiwania dotyczące czasu odpowiedzi, szybkości, skalowalności i stabilności w różnych warunkach obciążenia. |
3 | Upewnij się, że określone obciążenie jest dostępne lub metoda i narzędzia do generowania wymaganego obciążenia są wyraźnie wymienione w odpowiednich przypadkach testowych. |
4 | Wymień jasno warunek wstępny dla każdego scenariusza, taki jak warunki wstępnego obciążenia, które powinny istnieć w systemie, liczba jednoczesnych użytkowników itp., |
5 | Wymień narzędzia, które są zalecane do przeprowadzania testów wydajnościowych specyficznych dla każdej kategorii testów i dla każdego testu. |
6 | Upewnij się, że proces monitorowania wskaźników wydajności jest jasno określony. |
Po pomyślnym zakończeniu PQ spełnienie wymagań dotyczących wydajności jest bardzo ważne, ponieważ wszelkie odchylenia związane z wydajnością mogą spowodować ogromne straty biznesowe, powodując dyskomfort dla użytkownika, a zaufanie do używanego oprogramowania zostanie utracone, co doprowadzi do awarii oprogramowania.
Krótko mówiąc, t Poniższa tabela podsumowuje działania IQ-OQ-PQ.
ILORAZ INTELIGENCJI | CO | PQ | |
---|---|---|---|
Co | Aby zweryfikować proces instalacji oprogramowania i dokumentację procesu | Aby zweryfikować prawidłowe działanie systemu | Klienci, właściciele, dostawcy, zespół operacyjny |
WHO | Klienci, właściciele, dostawcy, zespół operacyjny | Klienci, właściciele, dostawcy, zespół operacyjny | Klienci, właściciele, dostawcy, zespół operacyjny |
Gdzie | W witrynie właściciela, lokalizacji zespołu operacyjnego, miejscu na żywo, w środowisku produkcyjnym | W witrynie właściciela, lokalizacji zespołu operacyjnego, miejscu na żywo, w środowisku produkcyjnym | W witrynie właściciela, lokalizacji zespołu operacyjnego, miejscu na żywo, w środowisku produkcyjnym |
Gdy | Kiedy oprogramowanie jest otrzymane od zespołu programistycznego, przed OQ i PQ. | Przed oddaniem systemu do użytku i po pomyślnym zakończeniu IQ | Przed uruchomieniem systemu i po pomyślnym IQ, zakończenie OQ |
Poniższa tabela wyjaśnia różne dane wejściowe dla każdej z faz walidacji.
Rodzaj | Wejście |
---|---|
ILORAZ INTELIGENCJI | 1. Dokument specyfikacji projektu 2. Pliki binarne oprogramowania i inne skrypty instalacyjne 3. Podręcznik instalacji 4. Dokument instrukcji konfiguracji 5. Dokument weryfikacji budowy i testu dymu |
CO | 1. Dokument specyfikacji funkcjonalnej 2. Dokument planu OQ 3. Dokument testu kwalifikacji operacyjnej 4. Szablon raportu podsumowującego test OQ 5. IQ zakończone pomyślnie |
PQ | 1. Dokument URS (Specyfikacja wymagań użytkownika) 2. Dokument planu PQ 3. Dokument testu kwalifikacji działania 4. Szablon raportu podsumowującego test PQ 5. IQ i OQ zakończone pomyślnie |
Wniosek
Nawet jeśli produkt / oprogramowanie przeszło wszystkie etapy weryfikacji i nie udowodni żadnego z IQ-OQ-PQ, wynik może być katastrofalny i będzie wiązał się z ogromnymi kosztami. Stąd pomyślne ukończenie samego IQ-OQ-PQ jest pomyślnym przeniesieniem produktu z miejsca rozwoju do zakładu produkcyjnego.
Ogólnie rzecz biorąc, pomyślne zakończenie procesu walidacji IQ-OQ-PQ nie tylko daje zaufanie do oprogramowania, ale także zapewnia spokój Klientowi, właścicielowi, programistom i testerom.
która warstwa modelu OSI współpracuje z ramkami?
Uruchamianie IQ-OQ-PQ zmniejsza również ryzyko wdrożenia go do życia bez przeprowadzania testów oraz zmniejsza koszty awarii i zmniejsza ryzyko wycofania produktów z rynku.
Tak więc, chłopaki, programiści i testerzy, nie obchodzimy się z radością po zakończeniu tworzenia i testowania we własnym zakresie i wydaniu oprogramowania zespołowi operacyjnemu. Świętowanie odbywa się tylko wtedy, gdy pomyślnie zakończy IQ-OQ-PQ, a oprogramowanie zostanie uruchomione w docelowym systemie.
Stąd sukces oprogramowania zależy od pomyślnego ukończenia IQ-OQ-PQ i od tego, czy oprogramowanie jest aktywne i gotowe do użycia przez użytkowników końcowych.
O autorze: Ten artykuł został napisany przez członka zespołu STH Gayathri Subrahmanyam. Ma ponad dwudziestoletnie doświadczenie w dziedzinie testowania oprogramowania. Podczas swojej kariery testowej wykonała wiele ocen TMMI, prace związane z industrializacją testów, konfiguracje TCOE oprócz obsługi dostaw testowych i wdrożyła praktykę DevOps dla ogromnego zaangażowania. Ale według niej nauka nigdy się nie kończy…
Podziel się swoimi doświadczeniami z przeprowadzania procesu walidacji i daj nam znać, jeśli masz jakiekolwiek pytania dotyczące tego artykułu.
rekomendowane lektury
- Kurs testowania oprogramowania: Do którego Instytutu Testowania Oprogramowania mam dołączyć?
- Najlepsze narzędzia do testowania oprogramowania 2021 [Narzędzia do automatyzacji testów QA]
- Asystent testowania oprogramowania
- Wybór testowania oprogramowania jako swojej kariery
- Testowanie oprogramowania Praca Freelancer Writer treści technicznych
- Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
- Opinie i recenzje dotyczące kursu testowania oprogramowania
- Testowanie oprogramowania Pomoc Program afiliacyjny!