Wprowadzenie
W wielu projektach, nad którymi pracowałem, ludzie nie dostosowywali TestRail do swoich potrzeb i korzystali z domyślnych ustawień. Dlatego w tym artykule postaram się opisać przykłady indywidualnych ustawień, które mogą pomóc Ci zwiększyć efektywność pracy. Na przykładzie weźmy projekt rozwoju aplikacji mobilnej.
Małe zastrzeżenie. W tym artykule nie opisuję podstawowej funkcjonalności TestRail (na ten temat istnieje wiele poradników) ani nie przedstawiam zachęcających wyrażeń, które pięknie opisują, dlaczego warto wybrać tego dostawcę do tworzenia repozytorium testów.
Plan uzasadnienia (co będzie zrealizowane)
Ogólne wymagania
Przypadek testowy powinien móc przejść absolutnie każda osoba
Przypadki testowe powinny utrzymywać aktualność jak najdłużej
Przypadki testowe muszą jak najdokładniej obejmować funkcjonalność aplikacji mobilnej w takim zakresie, w jakim nie stoi to w sprzeczności z dwoma pierwszymi punktami
Podział na TestCase i TestScenario
Szybkie tworzenie TestRun różnych typów
Smoke
Regress
Testowanie wpływu itd.
Optymalizacja wsparcia przypadków testowych
Rezygnacja z „martwych” hardcodowanych zrzutów ekranowych i przejście na „movable data”
Wymagania
Aby edytować pola, potrzebujesz dostępu administracyjnego
Wybór rodzaju projektu
Możesz wybrać trzy typy projektu:
Wybierzemy typ domyślny. W nim będą dostępne jednocześnie wszystkie przypadki testowe. Będziemy korzystać z inteligentnego filtrowania i dynamicznie zarządzać wszystkimi przypadkami jednocześnie.
Dodanie pól do wyświetlania listy przypadków testowych
Dodajemy pole do wyświetlania priorytetu przypadków testowych:
Można również dodać inne pola.
Ustawienie pól i tagów przypadków testowych
Otwieramy menu ustawień:
Potrzebujemy takich pól:
Pole „Podsumowanie” (nagłówek przypadku testowego)
To pole już istnieje, tylko usystematyzujemy jego użycie. Będziemy dzielić przypadki na TestCase i TestScenario. Aby lepiej czytać długą listę przypadków, lepiej wcześniej ustalić regulamin pisania podsumowań.
TestScenario:
Przykład: TestScenario — Główny scenariusz użycia aplikacji mobilnej
TestCase:
Przykład: MainScreen — Sekcja logowania — Wprowadzenie loginu
Zatem widzimy w podsumowaniu przypadku klasyczne rozumienie: „co, gdzie, kiedy”. Wizualnie również dzielimy wysokopoziomowe scenariusze testowe i niskopoziomowe przypadki testowe w najbardziej odpowiedniej formie dla automatyzacji.
Znacznik „StartScreen” (ekran, z którego zaczyna się TestScenario, wiele testów może dotykać sąsiednich ekranów)
Do czego może być potrzebny: usuniemy z tekstu kroki testów, które prowadzą użytkownika na ekran aktualnego testu. (standardowe kroki do stworzenia określonej sytuacji testowej) Wszystkie standardowe kroki dla wszystkich testów będą zapisane w jednym pliku. O nim napiszę bardziej szczegółowo osobno.
Tworzymy nowe pole:
Wypełniamy komponenty nowego pola:
W tym przypadku tworzymy pole wyboru z listy wartości. Wprowadzamy wartości tego pola:
Zwróć uwagę, że id wartości nie zaczynają się od jedynki i nie są kolejno numerowane. Dlaczego tak zrobiono? Chodzi o to, że jeśli mamy zapisane testy z wprowadzonym id,
a następnie będziemy musieli stworzyć trzeci ekran między dwoma istniejącymi,
to będziemy zmuszeni przepisać id, i ponieważ są już powiązane z tagami istniejących testów, po prostu zostaną usunięte. Będzie to bardzo nieprzyjemne.
Znacznik „Screen” (nazwa ekranu, który dotyczy TestCase)
Do czego może być potrzebny: jeden z punktów odniesienia do testowania impaktowego. Na przykład, deweloperzy stworzyli nową, fajną funkcję. Musimy ją przetestować, ale w tym celu musimy zrozumieć, co dokładnie ta funkcja mogła dotknąć. Domyślnie możemy przyjąć, że różne ekrany (Activity) aplikacji mają różne klasy i w związku z tym stanowią różne komponenty aplikacji. Oczywiście w tym przypadku potrzebne jest indywidualne podejście.
Przykład: home_screen, MapScreen, PayScreen itd.
Pole „MovableData” (link do proxy Bazy Danych z zmiennymi danymi testowymi)
Następnie postaramy się rozwiązać problem utrzymania aktualności danych w testach:
Linki do aktualnych makiet (to znacznie lepsze niż robienie martwych zrzutów ekranu)
Standardowe kroki do ekranu z sytuacją testową
Zapytania SQL
Linki do danych zewnętrznych i innych danych
Zamiast umieszczania danych testowych w każdym przypadku testowym, stworzymy jeden zewnętrzny plik i w wszystkich przypadkach testowych stworzymy do niego odwołanie. Po aktualizacji tych danych nie będziemy musieli przeglądać wszystkich przypadków testowych i ich zmieniać, a zmienimy te dane tylko w jednym miejscu. Jeśli ktoś nieprzygotowany otworzy przypadek testowy, zobaczy w treści przypadku testowego link do pliku oraz wskazówkę, że powinien w nim poszukać danych testowych.
Wszystkie te dane spakujemy w jeden zewnętrzny plik, który będzie dostępny dla wszystkich zainteresowanych w projekcie. Na przykład można użyć Google Sheet lub Excela i skonfigurować wewnątrz pliku wyszukiwanie. Dlaczego akurat ci dostawcy? Sprawa ma się tak, że opieramy się na paradygmacie, iż każdy członek zespołu powinien móc otworzyć i przejść przez przypadek testowy bez potrzeby wcześniejszego instalowania różnych narzędzi.
Dla Google Sheet można użyć zapytań SQL. Przykład:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Dla Excel można skonfigurować wygodne makra do natychmiastowego wyszukiwania. (filtrowania) Przykład .
Sama idea nie jest nowa i została opisana w pierwszej książce testera „Testowanie dot com”. (autor Sawin Roman) Tylko integrujemy w TestRail metody proponowane przez Romana Sawina. W tym celu stworzymy pole z linkiem do utworzonego pliku:
uzupełniamy domyślną wartość linku, aby w każdym nowym przypadku testowym już był link:
Jeśli lokalizacja zewnętrznego pliku się zmieni (przewidujemy wszelkie nieprzewidziane okoliczności), to wygodnie można w jednym kroku zmienić jedno lub kilka pól we wszystkich przypadkach testowych:
Pole „Descriptions” (opis lub pomysł na przypadek testowy, standardowe instrukcje)
W jakim celu może być potrzebne: W tym polu tekstowym umieścimy krótkie opisy przypadku testowego i standardowe instrukcje.
Przykład: Wszystkie dane testowe (aktualne makiety, użycie narzędzi i inne dane) z tego przypadku testowego są oznaczone linkami {...} i znajdują się w pliku MovableData. Link do MovableData znajduje się w odpowiednim polu u góry.
Tag „Component” (komponent aplikacji mobilnej)
Do czego może być potrzebne: do testowania wpływu. Jeśli aplikację mobilną można podzielić na komponenty (które jak najmniej wpływają na siebie nawzajem), to zmiany w jednym komponencie można wystarczająco (z pewnymi ryzykami) sprawdzić w ramach tego samego komponentu, co zmniejsza podstawy do przeprowadzania ogólnych regresji. Jeśli istnieje informacja, że jeden komponent może wpływać na drugi, tworzy się macierz testowania wpływu.
Przykłady komponentów: GooglePay, Zamówienia, Użytkownicy, Mapa, Autoryzacja itd.
Tag „TAG” (Inne tagi do filtrowania)
Tagowanie zestawu testów etykietami do dowolnego filtrowania.
Bardzo przydatne dla:
szybkiego tworzenia TestRun dla różnych typowych zadań: smoke, regresji itd.
czy testy będą zautomatyzowane lub już zostały zautomatyzowane
jakie inne tagi
Przykład: Smoke, Zautomatyzowane, WhiteLabel, DoUsunięcia itd.
Ustalamy kolejność wyświetlania pól w zestawie testów
Stworzyliśmy wiele nowych pól, nadszedł czas, aby ułożyć je w wygodnej kolejności:
Tworzenie TestRun
Teraz stworzymy nowy test run z aktualnymi przypadkami do przeprowadzenia testów smoke w trzy kliknięcia:
Inne przydatne porady
Jeśli w TestRail jest kilka projektów, nie zapominaj twórczyć nowych pól tylko pod Twój projekt, w przeciwnym razie koledzy z sąsiednich zespołów mogą być bardzo zdziwieni pojawieniem się nowych, nietypowych pól. Możliwe są lokalne omdlenia.
2. Przypadki z dużą ilością pól łatwiej kopiować z podobnej grupy niż tworzyć nowe:
3. Można wspólnie korzystać z kont. Na przykład: jedno konto administratora, kilka użytkowników.
Podsumowanie
Opisane powyżej przykłady zostały wdrożone w kilku projektach i wykazały swoją skuteczność. Mam nadzieję, że pomogą one poprawić Twoje rozumienie tego narzędzia oraz umożliwią tworzenie efektywnych i wygodnych „repozytoriów testowych”. Będę bardzo wdzięczny, jeśli w komentarzach opiszesz swoje doświadczenie z TestRail oraz przydatne porady.
Linki:
Książka:
Dziękuję bardzo za uwagę!
Źródło: habr.com
