how improve test release process
Zobaczmy typowy proces związany z dostarczaniem oprogramowania od „fazy rozwoju” do „fazy testowania” dla udane, wolne od błędów wydanie oprogramowania do produkcji / klienta .
Firmy programistyczne albo przeoczają te procesy, albo pomijają je, co skutkuje słabym zarządzaniem testami, a tym samym „ powozik ”Wydania oprogramowania dla klienta, co prowadzi do„ niezadowolonych klientów ”.
Nawet jeśli Zespół testowy poświęca dużo czasu i wysiłku przy każdym wydaniu , gdy wydane oprogramowanie nie ma określonej jakości lub nie spełnia założonych kryteriów, nie tylko wpłynie to na reputację firmy u klientów, ale także demotywuje i demoralizuje zespół projektowy, co najważniejsze, cały zespół testujący .
Jeśli jesteś częścią zespołu testowego w tym scenariuszu, możesz ciągle myśleć „jak poprawić moje możliwości testowania i czy istnieje lepszy sposób na przezwyciężenie tej sytuacji”.
Chcę podać kilka wskazówek i sugestii, opartych na moim doświadczeniu z różnymi zespołami testującymi zajmującymi się aplikacjami i wydaniami produktów korporacyjnych z wieloma domenami i platformami oraz z wieloma strukturami testowymi, na jak ulepszyć procesy wydawania testów , co ułatwi Ci życie zawodowe jako inżyniera testów lub kierownika testów w zakresie dostarczania oprogramowania na światowym poziomie.
Czego się nauczysz:
- Proces wydania testowego
- Udoskonalenie procesu wydania testowego:
- Zarządzanie i kontrolowanie zawartości wersji testowej
- Przykładowy szablon raportu o wydaniu:
- Wniosek:
- rekomendowane lektury
Proces wydania testowego
Poniższa tabela zawiera przegląd procesu wydawania testów z trzema uniwersalnymi fazami, takimi jak wejście, proces i wyjście.
zrobić kopię tablicy
WEJŚCIE | PROCES | WYNIK |
---|---|---|
7 | Lista kontrolna przeglądu kodu została zaktualizowana i jest dostępna w VSS? | |
Poprzedni proces Rozwój | Proces zaczyna się od • Instalacja wydanego oprogramowania na serwerze testowym | Potrzeby następnego procesu • Oprogramowanie, które przeszło testy dymu / zdrowia psychicznego |
Informacje / numer dokumentu • Dokument wymagań użytkownika • Specyfikacje wymagań oprogramowania • Plan testów jednostkowych • Standardy kodowania • Lista kontrolna przeglądu kodu • Plan rozwoju • Plan kontroli jakosci • Podział zadań • Pakiet roboczy • Harmonogram projektu • Plan projektu • Plan zarządzania konfiguracją • Ryzykowny plan zarządzania. | Procesy podrzędne • Przygotowanie przypadków testowych dla wszystkich jednostek • Rozwój i testy jednostkowe • Postępowanie z procedurami niezgodności • Wdrażanie planu zarządzania konfiguracją. • Wdrożenie planu zarządzania ryzykiem • Monitorowanie postępu projektu • Korekta błędów i recenzje | Wewnętrzne potrzeby klientów • Kompilacja oprogramowania z numerem wersji • Raport wydania • Przypadki testowe / Dokument zestawu testów • Planowanie wykonania testów • Macierz identyfikowalności • Dane testowe |
Weryfikacja przychodzących danych wejściowych • Dokumenty projektu są sprawdzane i zatwierdzane? • Standardy kodowania, lista kontrolna przeglądu kodu są dostępne w celach informacyjnych? • Przydzielone zadanie i zaktualizowany pakiet roboczy? • Specyfikacja funkcjonalna, plan rozwoju i plan jakości są sprawdzane i zatwierdzane? • Plan zarządzania ryzykiem zawiera środki łagodzące i awaryjne, aby poradzić sobie z ryzykiem? • Skuteczność harmonogramu projektu w celu dostarczenia produktu na czas? | Specyfikacja procesu • Przypadki testów jednostkowych powinny składać się ze wszystkich kryteriów wejścia i wyjścia • Zgodność kodu ze standardami kodowania • Z KPK należy postępować zgodnie z wytycznymi • Kroki zarządzania konfiguracją powinny być zgodne z planem zarządzania konfiguracją • Obsługa ryzyka powinna być zgodna z planem zarządzania ryzykiem • Testy dymu przechodzą wszystkie główne cechy i funkcjonalności | Potrzeby klientów zewnętrznych • Oprogramowanie wolne od błędów |
Procesy wspomagające • Alokacja ludzi / sprzętu / oprogramowania / zasobów • Konserwacja po awarii sprzętu • Szkolenie dla członków zespołu | Proces kończy się • Wykonanie testów dymu / poczytalności w wydanej kompilacji | Parametry sprawności • Każda Jednostka powinna przejść pierwszą rundę Testów • Zadania do wykonania zgodnie z harmonogramem projektu • Test dymu należy zdać przed wydaniem • Pasja zespołu testującego do testowania oprogramowania |
Każdy zespół testowy powinien stworzyć plik wyjątkowy lista kontrolna do wydania oprogramowania, zgodnie z domeną i platformą oprogramowania oraz metodologią zarządzania projektami (jak Agile Scrum itp.) oraz zgodnie z ramami testów ręcznych / automatycznych, aby zaakceptować wydaną kompilację, przed rozpoczęciem wykonywania testów, aby zaoszczędzić czas i wysiłek.
Jest to jeden z najważniejszych parametrów wydajnościowych w fazie testów.
Udoskonalenie procesu wydania testowego:
1) Przejrzyj raport wydania w przypadku nowej funkcjonalności, dostosowywania / modyfikowania istniejącej funkcjonalności, poprawek błędów z poprzedniej wersji, które zdecydują o rozpoczęciu wykonywania testów dymu lub testowania poczytalności lub obu.
dwa) Przejrzyj aktualizację Dokumenty testowe zgodnie z nową funkcjonalnością i poprawkami błędów, jeśli nie zostały jeszcze zaktualizowane. Zwykle podczas cyklu życia oprogramowania dokumenty te są aktualizowane przez zespół testujący na podstawie regularnych cotygodniowych spotkań przeglądowych projektu.
3) Przejrzyj repozytorium konfiguracji oprogramowania jest aktualizowany pod kątem numeru kompilacji, numeru wersji, oznaczony etykietą lub opatrzony komentarzem nazwą wydania zgodnie ze standardami określonymi w planie projektu. Upewnij się również, że kompilacja została pomyślnie skompilowana i zainstalowana na serwerze testowym.
4) Zaplanuj szybkie spotkanie przeglądowe projektu po wydaniu omówić wady i zalety wydanej wersji, znanych błędów i krytycznych funkcji itp., aby uniknąć wszelkich nieporozumień i przejrzeć wszelkie ważne wymagania klienta. Należy ściśle unikać jakiejkolwiek komunikacji ustnej między zespołami programistów i testerów, ponieważ ma to duży wpływ na jakość wydania oprogramowania.
5) Upewnij się, że narzędzie do śledzenia błędów jest poprawnie skonfigurowane , dla przydzielonego zespołu testującego i zespołu programistów projektu, numery kompilacji i wydania oprogramowania oraz modułów / funkcjonalności oprogramowania, które pomogą efektywnie rejestrować błędy. Jeśli nie, powinno zostać przekazane kierownikowi projektu lub kierownikowi testów na zasadzie wysokiego priorytetu.
6) Zwróć kompilację do zespołu deweloperskiego bez żadnych kompromisów, jeśli kompilacja nie powiedzie się w testach dymu lub poczytalności. Ściśle rzecz biorąc, testowanie nie powinno być kontynuowane, gdy system nie przejdzie pomyślnie testu dymu. Zaoszczędzi to dużo czasu i wysiłku oraz poprawi jakość oprogramowania udostępnianego w kolejnych wersjach.
7) Zaplanuj wydanie projektu na 1śwDzień tygodnia co pomoże kierownikowi testów zaplanować nadchodzący cykl testowy w oparciu o stabilność kompilacji, a także wysłać szybki raport z testów do kierownika projektu, który z dużym wyprzedzeniem podniesie jakość oprogramowania. Jeśli zespół programistów zaplanuje publikację projektu w piątek, weekend może zostać wykorzystany na ewentualne poślizgnięcia, a także wszelkie problemy z kompilacją w ręcznej lub automatycznej strukturze kompilacji.
8) Upewnij się, że testerzy są odpowiednio przeszkoleni w domenie co pomoże zespołowi testowemu w przestrzeganiu harmonogramu testów i zapewni czas na następną rundę testów. Ponadto zespół testujący powinien być przeszkolony i mieć kontakt z wymaganą technologią, taką jak skrypty i SQL, jeśli projekt wymaga białej skrzynki.
9) Unikaj przydzielania testerów w wielu projektach ponieważ ma duży wpływ na jakość wykonywania testów w czasie rzeczywistym. W praktyce nawet doświadczeni testerzy pomijają cechy i funkcjonalność, a także pomijają przypadki testowe, zakładając, że niektóre przypadki testowe nigdy nie zawodzą, gdy są przeciążone pracą lub przydzielane do wielu projektów z terminami.
10) Doceń zespół testujący za pasję ponieważ testerzy nie powinni pracować dla „dnia” ani komentować „Call it a Day”. Gdy oprogramowanie ma wiele modułów, a funkcjonalista jest całkowicie lub częściowo zintegrowany lub powiązany, testerzy powinni mieć pasję do pisania / wykonywania przypadków testowych z dużym pokryciem i matrycą identyfikowalności, mając na celu jakość końcowego oprogramowania / produktu. Ponieważ nawet problem kosmetyczny jest „błędem” i jest liczony jako „1 błąd”.
jedenaście) Upewnij się, że instalacja oprogramowania jest łatwa i prosta ponieważ pomaga zespołowi testującemu w ponownej instalacji oprogramowania w razie potrzeby, zamiast czekać, aż kierownik ds. rozwoju lub kierownik instalacji wykona tę samą pracę, co niepotrzebnie zabije dostępny czas testowania. Na przykład, mimo że instalacja oparta na systemie Windows jest łatwa, ale jeśli obejmuje wiele serwerów WWW i sieci rozległych w wielowarstwowym środowisku testowym, instalacja oprogramowania może zająć testerom wiele godzin. Jeśli testowanie oprogramowania obejmuje i instalację, dezinstalację , łaty lub aktualizacje oprogramowania, jest bardziej prawdopodobne, że zostanie szczegółowo omówiony proces wykonywania przypadków testowych z zespołem testującym.
12) Upewnij się, że zautomatyzowane narzędzia są dostępne z licencją przez ramy testowania automatyzacji . Wykonywanie przypadków testowych w zautomatyzowanej strukturze jest łatwe w porównaniu ze scenariuszem testowania ręcznego, pod warunkiem, że zautomatyzowane narzędzia są odpowiednio skonfigurowane i licencjonowane dla wielu użytkowników. Szczególnie, gdy plan testowania obejmuje testy wydajnościowe i obciążeniowe oprócz zwykłego wykonywania przypadków testowych i testów regresyjnych, testerzy powinni obejmować wykonywanie przypadków testowych w wielu środowiskach, takich jak wiele serwerów, wiele przeglądarek, wielu użytkowników itp.
13) Upewnij się, że maszyny widmowe są przygotowane do testowania przed rozpoczęciem wykonywania testów. Maszyny widmo to maszyny z innym środowiskiem testowym. Na przykład aplikacja internetowa może być zaplanowana do testowania w wielu środowiskach, takich jak Windows 7 i Access DB lub Windows 2008 i SQL Server lub Windows 8 i Oracle lub Mainframe i DB2 itp., Przy użyciu wszystkich przeglądarek, takich jak Chrome, Firefox, Internet Explorer. , Safari itp., Niektóre „testy systemu” wymaga nawet całkowitego sformatowania dysku twardego i zainstalowania nowego oprogramowania lub aktualizacji istniejącego oprogramowania za pomocą poprawek i aktualizacji itp.
14) Unikaj wdrażania nowych funkcji / żądania zmiany zatrzymując wykonywanie testów i ponownie udostępniając oprogramowanie w celu ponownego określenia fazy testowania. Jest to bardzo zła praktyka w wielu organizacjach zajmujących się oprogramowaniem, zgodnie z wymaganiami biznesowymi, aby zadowolić klientów zewnętrznych lub przynajmniej spełnić wymagania komitetu sterującego zarządzającego lub czasami zespołów sprzedaży / marketingu. Mimo że prośby klientów o zmiany są zawsze zachęcane w zwinnym środowisku projektowym, należy je odpowiednio zaplanować i wdrożyć przed wydaniem oprogramowania zespołowi testującemu.
Zarządzanie i kontrolowanie zawartości wersji testowej
Zarządzanie i kontrolowanie zawartości wersji testowej jest najważniejsze dla każdego oprogramowania informatycznego, a nawet dla dowolnego środowiska oprogramowania innego niż IT, które zostanie przedstawione na poniższym rysunku.
- Kierownicy projektu i / lub komitet sterujący projektem zależą od uprawnień macierzy organizacji, są odpowiedzialni za wybór treści dla każdego wydania.
- Po zidentyfikowaniu i zatwierdzeniu błędów i / lub nowych funkcji oraz żądań zmian od klientów, zostaną one wdrożone przez zespół programistów, który powinien zostać poinformowany o tym interesariuszy projektu przed rozpoczęciem opracowywania / wdrażania.
- Na podstawie zaimplementowanej ostatecznej wersji zespół testujący zaktualizuje powiązane dokumenty i odpowiednio przygotuje się do testów.
- Zespół testujący rozpocznie testy Smoke / Sanity zgodnie z wymaganiami określonymi w raporcie o wersji.
- Po przejściu poczytalności zespół testujący rozpocznie wykonywanie testów zgodnie z harmonogramem i przydzielonymi zadaniami, a mianowicie testami funkcjonalnymi, testami niefunkcjonalnymi, testami bezpieczeństwa, testami systemu, testami wydajnościowymi, testami obciążenia, testami akceptacji użytkownika itp.
- Po zakończeniu pierwszej rundy cyklu testowego, raporty z testów zostaną przesłane do wszystkich interesariuszy i kierownika zespołu programistycznego w celu zaplanowania kolejnej iteracji wykonania testów.
- W zależności od statusu raportów z testów oraz wagi i złożoności błędów, pełny cykl drugiej rundy wykonywania testów lub testów regresyjnych zostanie zaplanowany wraz z testami akceptacyjnymi użytkownika.
- Po zakończeniu zaplanowanych cykli wykonania testów, raporty z testów zostaną wysłane do wszystkich interesariuszy projektu w sprawie pozytywnych / nieudanych / pominiętych funkcji, funkcjonalności i poprawek błędów.
Przykładowy szablon raportu o wydaniu:
Uwaga : Przykładowy szablon MS Word raportu o wydaniu jest również dostępny do pobrania poniżej.
Znajdź poniżej „ Przykładowy raport o wydaniu ”, Która obejmuje główne aspekty procesu wydawania, dzięki czemu życie zawodowe całego zespołu projektowego jest o wiele szczęśliwsze niż kiedykolwiek wcześniej.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
#1 Zakres
Nawigacja GPS dla XYZ Company Limited jest udostępniana do testów wewnętrznych. Wydana wersja to 1.0.7, numer wydania to 14.0, a numer kompilacji 105.25.03. Ta wersja oprogramowania zawiera nowe funkcje i główne poprawki błędów z poprzedniej wersji. Testy dymu przeszły z fazy rozwoju, ale przed przejściem do testów regresyjnych wymagane jest wykonanie testów Smoke & Sanity.
# 2) Odniesienia
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Opis wydania
Ta wersja jest kontrolowaną wersją nawigacji GPS i zawiera następujące funkcje i możliwości.
Funkcje oznaczone * są nowe w tej wersji.
Następujące funkcje nie zostały zaimplementowane w tej wersji.
1. Moduł 1
1.1 Cecha 1
1.1.1 Funkcjonalność 1
# 4) Zarządzanie konfiguracją
Używamy Visual Source Safe jako narzędzia do zarządzania konfiguracją. Kompilacja jest dostępna w następującej ścieżce.
Link wewnętrzny: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Link zewnętrzny: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Instrukcje i kroki instalacji
Podaj szczegółowe informacje dotyczące instalacji kompilacji zespołowi ds. Kontroli jakości / testów.
# 6) Problemy / błędy naprawione
Status błędów jest aktualizowany w systemie śledzenia defektów.
# 7) Problemy / błędy do naprawienia
# 8) Materiały dostarczane
# 9) Znane błędy / problemy
# 10) Lista kontrolna wydania
Tak nie / | Opis | T / N |
---|---|---|
1 | Czy wszystkie pliki zostały sprawdzone w programie Visual Source Safe? | |
dwa | Czy etykieta została umieszczona w odpowiednim folderze w VSS zgodnie z wewnętrznymi standardami? | |
3 | Czy wydanie można zidentyfikować jako wydanie „zewnętrzne” / „wewnętrzne” w usłudze VSS? | |
4 | Czy w komentarzach wspomniano o wersji w VSS? | |
5 | Czy w komentarzach wspomniano o krótkim opisie w VSS? | |
6 | Kod został przejrzany i problemy z przeglądaniem kodu są zarejestrowane w Clear Quest? | |
8 | Czy dokument testu jednostkowego został przygotowany i zweryfikowany? | |
9 | Wykonano testy jednostkowe, a wyniki zaktualizowano pod kątem statusu? | |
10 | Zaktualizowany dokument przypadku testów jednostkowych jest dostępny w VSS? | |
jedenaście | Czy wszystkie problemy z Clear Quest w tym wydaniu zostały rozwiązane / zamknięte? | |
12 | Czy wszystkie zadania pakietu roboczego zostały ukończone i zaktualizowane w VSS? | |
13 | Czy testy dymu zostały wykonane i zdane? |
=> Ściągnij: Kliknij tutaj, aby pobrać przykładowy szablon raportu o wydaniu w formacie MS Word.
Wniosek:
Jak stale ulepszać proces wydawania testów
Wskazówka nr 1) Skonfiguruj zespół inżynierów wydań, który zajmie się krytycznymi czynnikami związanymi z utrzymaniem wersji i kompilacji oprogramowania oraz będzie odpowiedzialny za scentralizowane systemy zarządzania konfiguracją oprogramowania.
Wskazówka nr 2) Motywuj i doceniaj zespoły projektowe za śledzenie procesu związanego z cyklem życia tworzenia oprogramowania, cyklem życia rozwoju produktu i cyklem życia testowania oprogramowania. Możemy zdefiniować proces, ale dopóki nie będą przestrzegane przez zaangażowane osoby, nie ma sensu definiować procesu.
Wskazówka nr 3) Oszacuj wysiłek związany z testowaniem na podstawie doświadczeń i wcześniejszej historii. Pisanie przypadków testowych różni się całkowicie od wykonywania tego samego. Testerzy powinni wiedzieć, co testować, jak i kiedy testować, w przeciwnym razie wysiłek włożony w cykl testowania zostanie zmarnowany, nawet jeśli miało miejsce wiele rund cyklu testowego.
Porada 4) Wreszcie, jeśli to możliwe i wykonalne, zautomatyzuj fazę testowania za pomocą powszechnie akceptowanych narzędzi testowych. Korzystanie z narzędzi do automatycznego budowania i narzędzi do automatycznego testowania zmniejsza wysiłki związane z testowaniem o ponad 50%, poprawiając jakość oprogramowania i zapewnia 100% jakość, jeśli struktura automatyzacji jest odpowiednio zaprojektowana.
Wskazówka nr 5) Wreszcie, wydanie testowe to nie tylko praca, to sztuka ułatwiania i zwiększania komfortu życia wszystkich interesariuszy w projekcie.
O autorze: Balu A. jest doświadczonym specjalistą IT z ponad dwudziestoletnim doświadczeniem w zakresie oprogramowania IT oraz dziesięcioletnim doświadczeniem w zarządzaniu projektami i testami, dostarczając aplikacje dla przedsiębiorstw i rozwiązania mobilne w różnych domenach przy użyciu technologii Microsoft, Oracle, Java i Mobile. Zasadniczo jest liderem z pasją promowania ludzi, aby stali się liderami z odpowiednim nastawieniem i uwielbia pracę w środowisku zorientowanym na procesy i wierzy, że proces poprawia wydajność, jakość i produktywność pracowników.
Wnastępny tutorial, dowiemy się - jak to zrobić Popraw wydajność przypadków testowych.
Daj nam znać swoje przemyślenia / pytania w komentarzach poniżej.
Miej wydanie oprogramowania zgodnie z procesem!
Pełne testowanie zgodnie z harmonogramem z dużą produktywnością i wysiłkiem !!
Postaraj się uzyskać wolne od błędów, gwarantowaną jakość oprogramowania !!!
Jeśli podoba Ci się ten artykuł, rozważ udostępnienie go znajomym!
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
- Czym jest testowanie małp w testowaniu oprogramowania?
- Wybór testowania oprogramowania jako swojej kariery
- Testowanie oprogramowania Praca pisarz treści technicznych Freelancer
- Przykładowy raport o błędzie
- Praktyczny przebieg procesu testowania oprogramowania QA (wymagania do wydania)