Redakcja
Ważna uwaga: QADirector jest narzędziem stworzonym i przez lata sprzedawanym przez firmę Compuware. Jakieś dwa lata temu część Compuware’a zajmująca się dostarczaniem narzędzi testujących została wykupiona przez firmę Microfocus, która stawia głównie na narzędzia z rodziny Silk, ale jak na razie supportuje QADirectora i TestPartnera. W przyszłości prawdopodobnie narzędzia zakupione od Compuware zostaną „wchłonięte” przez rodzime produkty Microfocusa i sprzedawane już pod nazwą Silk.
QADirector jako część Compuware Quality Managament integruje poniższe narzędzia:
• Quality Manager – umożliwia nadzorowanie postępu prac nad projektem w celu maksymalizacji korzyści biznesowych.
• File-AID/CS – pozwala developerom zarządzać i przygotowywać dane do tesów. Posiada podstawowe możliwości edycji, kopiowania, porównywania oraz validacji danych.
• Hiperstation – narzędzie współpracujące z QAD dzięki któremu mamy możliwość przetestowania aplikacji serwerowych bezpośrednio z naszego PC.
• QALoad – stworzony jest w celu przeprowadzania testów wydajnościowych zarówno dla aplikacji jak i sieci w której ona pracuje. Aplikacja potrafi stworzyć skrypty i zasymulować działanie tysięcy użytkowników.
• Test Partner - jest aplikacją przeznaczoną do wykonywania testów aplikacji webowych i desktopowych. W celu stworzenia testów nagrywa on zachowanie użytkownika. Poszczególne scenariusze prezentowane są później w sposób zrozumiały nawet dla początkującego testera.
• TrackRecord – służy do zbierania informacji na temat członków zespołów testujących, harmonogramów, oraz błedów. Wszystkie te dane gromadzone są w obiektowej bazie danych.
• OptimalTrace – ułatwia tworzenie notatek, dokumentów opisujących wymagania klienta.
Rys. 1
Do pracy QADirector wymaga serwera bazy danych, serwera webowego oraz serwera testowego. Nie ma znaczenia czy wszystkie te komponenty będą zainstalowane na jednej fizycznej maszynie, czy na oddzielnych. W typowej instalacji QADirector jest uruchamiany z serwera WWW, baza danych natomiast pracuje na osobnej fizycznej maszynie. Minimalnymi wymaganiami sprzętowymi dla takich serwerów jest co najmniej procesor z zegarem 2GHz, 2GB pamięci ram i co najmniej 20GB wolnej przestrzeni na dysku. Producent zapewnia nam wsparcie dla następujących baz danych: Microsoft SQL Server 2008, Microsoft SQL Server 2005. Oracle 11.1, Oracle 10.2, Oracle 10.1. Aplikacja działa w środowisku Windows i współpracuje z wymienionymi systemami: Microsoft Windows 7, Microsoft Windows Vista, Microsoft Windows XP, Microsoft Windows Server 2003 & 2003 R/2, Microsoft Windows 2008 & 2008 R/2.
Rys.2. Zalecana konfiguracja systemu QADirector.
• Web Server - główny komputer, na którym jest zainstalowany QADirector i z którym łączą się maszyny klienckie.
• Database Server – zawiera wszystkie zasoby niezbędne do pracy.
• Test Managament Server – odbiera i wysyła zapytania dotyczące wykonywania testów przydzielonych przez użytkowników.
• Client Machine - komputer z zainstalowaną przeglądarką internetową w celu dostępu do QADirectora oraz Manual Testing uruchamianych z Web Servera.
• Test Execution Agent – stacja robocza, która otrzymuje i wykonuje polecenia od Test Managament Servera, następnie uruchamia poszczególne testy i zwraca ich rezultaty.
Interfejs aplikacji jest jest bardzo uproszczony i wydawać się może trochę archaiczny, ikony oraz menu przypominają okienka z Windows98. Moim zdaniem jednak takie klasyczne rozwiązanie daje szybki i intuicyjny dostęp do najpotrzebniejszych funkcji. Dodatkowo producent dał nam możliwość personalizacji menu oraz szybki dostęp przy użyciu skrótów klawiszowych [CTRL+ ...].
Rys.3. Interfejs aplikacji po zalogowaniu się z widoczną listą projektów.
Po lewej stronie mamy w pełni konfigurowalny panel nawigacyjny, z którego możemy przechodzić bezpośrednio m.in. do danego projektu, zbioru testów i rezultatu ich wykonań, a także przeglądać poszczególne skrypty i zgłoszone błędy. Jest możlowść zdefiniowania, które zakładki i w jaki sposób będą wyświetlane.
Zaraz po zalogowaniu na głównym ekranie pojawia się lista przypisanych do nas projeków. Każdy użytkownik ma prawo do edycji ustawień wyświetlania w zakładce User Options. Domyślnie pokazywane są wszystkie projekty wraz z ich opisem, przydzielone dla danego pracownika, jednak dzięki panelowi nawigacyjnemu możemy odfiltrować te, które w danym momencie nas interesują. Uprawnienia administratora pozwalają na tym ekranie na usuwanie i tworzenie nowych projektów. Cała procedura odnośnie tworzenia i zarządzania projektami została szczegółowo przedstawiona w pomocy (F1) programu, zatem nie będę się zagłębiał tutaj w szczegóły.
Rys.4. Aktywny projekt z widocznymi wlaściwościami.
Proces testowania w QADirector ma pewien standardowy workflow, w którym możemy wyodrębnić poniższe elementy:
• Tworzenie nowego projektu,
• Wybranie modelu ryzyka,
• Określenie daty rozpoczęcia i zakończenia projektu,
• Przypisanie pracowników do danego projektu,
• Określenie wymagań i pogrupowanie ich w foldery,
• Tworzenie skryptów i testów oraz powiązanie ich z wymaganiami,
• Tworzenie testów manualnych,
• Tworzenie zadań do wykonania (manualnych lub automatycznych),
• Analiza wykonanych zadań,
• Sporządzanie raportów.
Dla każdego z etapów aplikacja zapewnia solidne wsparcie, ja chciałbym tutaj powiedzieć kilka zdań więcej ma temat przygotowania i wykonywania testów manualnych.
Nowy Test Case możemy utworzyć na kilka sposobów. Najprostszym z nich jest wybranie w panelu nawigacyjnym zakładki Tests i, klikając na głównym ekranie prawym przyciskiem, wybrać 'New Test'. Inną możliwością jest wybranie 'Global Scripts' z menu 'Manage'. Uruchamiamy w ten sposób główną aplikację do zarządzania skryptami.
Rys.5. Manage Global Scripts.
Klasyczny styl interfejsu jest identyczny jak w głównej aplikacji. Po lewej cześci okna widzimy długą listę folderów zawierających skrypty, przy pomocy których wykonujemy testy. Na górze mamy do dyspozycji rozwijaną listę, z której wybieramy rodzaj narzędzia testującego, wywodzącego się z rodziny QACenterTM (np. QARun, TestPartner lub manual), a następnie listę opcji niezbędnych do edycji skryptów (podobne możliowości uzyskamy z menu klikając prawym przyciskiem na danym skrypcie). W celu utworzenia nowego testu manualnego na liscie folderów zakładamy nowy katalog nadając mu odpowiednią nazwę. Po przejściu do niego na głównym ekranie wybieramy z menu opcje 'New Script' co powoduje uruchomienie Manual Script Editora.
Rys.6. Manual Script Editor
Chociaż jest to narzędzie stworzone z myślą o edycji i pisaniu scenariuszy, przyznam, że czasem wolę napisać scenariusz w Excelu, a następnie przeklejić poszczególne kroki do omawianej aplikacji. Dlaczego? Przy uzupełnianiu pola Text lub Notes w danym stepie aplikacja często nie zmienia wielkości okna, w którym wpisujemy tekst, skutkiem czego przy dłuższym zdaniu widzimy tylko kilka ostatnio wpisanych słów, a edycja takiego stepu jest bardzo niewygodna (powyższy obrazek). Przy kilkugodzinnej pracy w ten sposób można stracić sporo nerwów. Co wiecej, pisząc test początkowo w Excelu mamy większą szansę uniknięcia literówek (Excel-sprawdza pisownie w wielu językach, Manual Script Editor wcale jej nie sprawdza). Oprócz pola Text i Notes przy pisaniu manualnego testu musimy wybrać rodzaj stepu (Instruction, Question, Multiple Choice, Question(Text)), a także możliwe oraz spodziewane przez nas odpowiedzi. Jeżeli zachodzi potrzebna możemy również dopisać dodatkowe informacje w polu Associated Data lub załączyć plik potrzebny do przejścia danego kroku (np. skrypt SQL). W drugim przypadku dobrze jest pamiętać aby zawartość załącznika była skompresowana przed dodaniem jej do aplikacji (później wyjaśnię dlaczego...). W górnym pasku menu mamy do dyspozycji przyciski do wstawiania i zmiany kolejności stepów, proste narzędzie do wyszukiwania oraz możliwość przeglądania historii danego scenariusza.
Aby wykonać gotowy test manualny, musi on zostać najpierw przydzielony nam przez osobę zarządzającą projektem. Do samego wykonania posłuży nam przeznaczona do tego aplikacja Compuware QADirector-Manual Testing, którą uruchamiamy z Web Servera.
Rys.7. Manual Testing
Rys.8 Manual Script Execution
Po lewej stronie widzimy (Rys. 7.) listę testów w danym projekcie (można ją filtrować wybierając odpowiednią opcję z górnego menu), z której wybieramy przypisany do nas test. W głównej części ekranu zobaczymy wtedy listę skryptów wraz z ich opisem (Name, Status, Scripts, Risk, Time Est., Path, Description). Z tej listy otwieramy dany scenariusz i wykonujemy zawarte w nim polecenia (Rys. 8). Przejście scenariusza polega na wykonaniu poszczególnych instrukcji oraz udzieleniu odpowiedzi czy działanie programu jest zgodne z zachowaniem oczekiwanym przez autora. Do każdego kroku możemy dodać swój własny komentarz lub załączyć zrzutu ekranu z wykonania danej instrukcji (ewentualnie plik lub adresu URL). Przydatną często opcją jest możliwość opóźnienia o kilka sekund wykonania zrzutu ekranu po naciśnięciu przycisku.
Rys. 9. Ekran dodawania załącznika przy wykonywaniu stepu.
Wspomniałem wcześniej, że przy tworzeniu manualnego scenariusza dobrym zwyczajem jest dodawanie do programu załączników w formie skompresowanej. Wyjaśnię na czym problem polega.
Manual Scrip Editor umożliwia nam jedynie podejrzenie załączonego przez autora pliku. Brakuje tutaj niestety możliwości kopiowania go bezpośrednio do nas na dysk, co czasem jest niezbędne dla wykonania danego kroku. Jeżeli plik jest skompresowany, to możemy wypakować go we wskazane miejsce. Gdy w załączniku jest plik z rozszerzeniem .txt lub .sql, to też problemu nie ma, bo korzystając z View Attachment uda nam się ten plik otworzyć zainstalowanym na komputerze programem. Nieciekawa sytuacja natomiast pojawia się, gdy autor do załącznika wrzuci nam "goły" plik .dll (np. w celu podmiany w jakimś katalogu). Problem taki możemy rozwiązać próbując "wyciągnąć dll’kę" z bazy za pomocą programu Reflector. Jeżeli próba się nie powiedzie, to powinniśmy poszukać naszego pliku w katalogu C:UsersUser_nameAppDataLocal gdyż tam program kopiuje wszystkie załączniki przy próbie ich otwarcia.
Po przejściu każdego scenariusza wybieramy z górnego menu opcję Complete Script, program zamyka dany skryp i ładuje następny. W przypadku, gdy jeden ze stepów w danym scenariuszu nie zakończył się w przewidywany sposób, wtedy cały scenariusz zostaje zamknięty ze statusem Fail.
Rys. 10. Przykładowe podsumowanie wykonania Test Case
Linki:
• Oficialna strona producenta: http://www.microfocus.com/
• Dane o produkcie: http://www.powertest.com/files/datasheet-qadirector.pdf
• Instrukcja instalacji i konfiguracji: http://supportline.microfocus.com/Documentation/books/QADirector/Doc/AQ60/PDF/cwaqix.pdf
Autor: Piotr Olczyk
