Testy funkcjonalne po zmianie wersji

Testy funkcjonalne po zmianie wersji sprawdzają, czy aplikacja poprawnie działa na nowym silniku bazy.

Zakres testów po aktualizacji silnika bazy danych

Testy funkcjonalne po zmianie wersji sprawdzają, czy aplikacja wykonuje te same operacje biznesowe co przed aktualizacją, gdy korzysta już z nowej wersji silnika bazy danych. Weryfikacji wymagają przede wszystkim uruchomienie programu, logowanie użytkownika, odczyt rekordów, tworzenie nowych wpisów, edycja danych, usuwanie danych zgodnie z uprawnieniami oraz wyszukiwanie po polach używanych przez aplikację. Każdy scenariusz powinien być wykonany na danych testowych o znanej zawartości, aby można było porównać rezultat z oczekiwanym wynikiem. Sam fakt poprawnego nawiązania połączenia z bazą nie potwierdza poprawności działania całego programu.

Zakres należy dobrać do zmian wprowadzonych podczas aktualizacji. Jeżeli zmieniono sterownik, bibliotekę dostępu do danych, ustawienia kodowania, sposób uwierzytelniania albo definicje tabel, testy powinny obejmować funkcje korzystające z tych elementów. Trzeba również sprawdzić operacje wykonywane w jednej transakcji, zatwierdzanie zmian i wycofywanie operacji po błędzie. W praktyce istotne są przypadki graniczne: puste pola, wartości maksymalnej długości, znaki diakrytyczne, daty, liczby dziesiętne, duże wyniki wyszukiwania oraz próba zapisania rekordu naruszającego ograniczenie unikalności. Test powinien wskazywać nie tylko, że pojawił się błąd, lecz także czy aplikacja obsłużyła go zgodnie z założeniami.

Porównanie zachowania przed i po zmianie wersji

Wiarygodne testy wymagają ustalenia punktu odniesienia. Przed zmianą wersji warto zapisać wyniki reprezentatywnych operacji, między innymi liczbę zwróconych rekordów, kolejność sortowania, wartości obliczane przez aplikację oraz komunikaty prezentowane użytkownikowi. Po aktualizacji te same scenariusze wykonuje się na równoważnym zestawie danych. Porównanie powinno uwzględniać typy wartości, format dat i liczb, obsługę wartości pustych oraz sposób interpretacji znaków specjalnych. Różnica w wyglądzie interfejsu nie musi oznaczać błędu, ale różnica w treści zapisanego lub odczytanego rekordu wymaga wyjaśnienia.

Osobną grupę stanowią funkcje zależne od relacji między tabelami. Należy sprawdzić dodawanie elementu podrzędnego do istniejącego rekordu nadrzędnego, odczyt danych po połączeniu kilku tabel, filtrowanie wyników oraz reakcję na próbę usunięcia rekordu, do którego odwołują się inne dane. Jeżeli aplikacja korzysta z raportów, eksportu lub importu, test powinien potwierdzić kompletność pliku wynikowego i zgodność jego wartości z danymi w bazie. Warto zweryfikować także wielokrotne wykonanie tej samej operacji, aby wykryć niezamierzone duplikaty. Wynik testu powinien zawierać opis warunków, wykonane czynności, rezultat rzeczywisty i ocenę zgodności.

Obsługa błędów, uprawnień i przerwanych operacji

Zmiana wersji silnika może ujawnić problemy, które nie występowały podczas zwykłego odczytu danych. Dlatego scenariusze funkcjonalne powinny obejmować brak połączenia, przekroczenie czasu oczekiwania, odrzucenie nieprawidłowych danych oraz przerwanie operacji w trakcie zapisu. Po wystąpieniu błędu trzeba sprawdzić, czy użytkownik otrzymuje zrozumiały komunikat, czy aplikacja pozostaje responsywna i czy nie pozostawia częściowo zapisanych danych. Jeżeli operacja obejmuje kilka zmian, jej rezultat powinien być zgodny z przyjętą regułą: wszystkie zmiany zostają zapisane albo wszystkie są wycofane. Nie wolno uznawać testu za pozytywny wyłącznie dlatego, że aplikacja nie została zamknięta.

Sprawdzenia wymagają również role użytkowników i zakres dostępnych operacji. Konto przeznaczone tylko do odczytu nie powinno móc dodawać, modyfikować ani usuwać rekordów, natomiast konto uprawnione do edycji powinno wykonywać wyłącznie operacje przewidziane dla tej roli. Trzeba potwierdzić zachowanie po wygaśnięciu sesji, ponownym zalogowaniu oraz zmianie uprawnień. Jeżeli aplikacja wyświetla komunikaty zależne od odpowiedzi bazy, należy sprawdzić, czy błędna operacja nie jest przedstawiana jako zakończona sukcesem. Logi aplikacji powinny pozwolić powiązać konkretny scenariusz z czasem wykonania i rodzajem błędu, bez zastępowania testu samą analizą logów.

Protokół odbioru aplikacji na nowej wersji bazy

Po wykonaniu testów należy sporządzić protokół zawierający wersję testowanej aplikacji, zastosowaną wersję silnika bazy, konfigurację połączenia, zakres danych testowych i listę scenariuszy. Dla każdego przypadku trzeba zapisać status, wynik oczekiwany, wynik uzyskany oraz ewentualny identyfikator błędu. Usterki należy klasyfikować według wpływu na działanie: brak możliwości uruchomienia, utrata lub zniekształcenie danych, niedostępna funkcja, niepoprawna obsługa błędu albo rozbieżność wyłącznie prezentacyjna. Przed zakończeniem odbioru warto powtórzyć scenariusze, które wcześniej zakończyły się błędem, oraz przeprowadzić krótki test regresji obejmujący podstawowe funkcje używane codziennie.

W środowisku domowym lub biurowym problemy po zmianie wersji mogą być widoczne jako niedziałający program, błędny zapis dokumentów, brak wyników wyszukiwania albo komunikat o niedostępnej bazie. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w ramach diagnostyki stanowiska można również sprawdzić poprawność działania aplikacji po aktualizacji jej komponentów. Końcowa ocena powinna opierać się na powtarzalnych wynikach testów, a nie na pojedynczym pomyślnym uruchomieniu. Jeżeli wymagania nie zostały spełnione, aktualizację należy oznaczyć jako niezatwierdzoną do zwykłego użytkowania do czasu usunięcia przyczyny i ponownego wykonania odpowiednich scenariuszy.