Czy programiści powinni pomagać testerom w projektowaniu testów?

Jak bardzo programiści powinni pomóc testerom w projektowaniu testów?

Nie sądzę, że w ogóle powinni pomóc. Martwię się, że jeśli pomogą testerom w zaprojektowaniu testów dla własnego kodu, „zainfekują” testerów własnymi uprzedzeniami i martwymi punktami na temat tego kodu.

Uważam, że wymagania powinny być wystarczające do podania informacji potrzebnych testerom do stworzenia swoich testów. Jeśli jest jakaś część implementacji, którą programiści uważają za niepokojącą, to myślę, że ich obowiązkiem jest wdrożenie testów jednostkowych w celu przetestowania tej części lub nawet przeprowadzenie własnych nieformalnych testów systemowych w celu przetestowania tej części.

Jednak nie wszyscy, których znam, zgadzają się z tym (i rozumiem niektóre z ich argumentów do pewnego stopnia). Co sądzą o tym inni? Czy jest to omówione w literaturze gdziekolwiek?

Zgadzam się. Programiści mogą pomóc testerom zrozumieć specyfikację funkcjonalną, znaleźć zasoby do badań, ale nie powinni zanieczyszczać umysłów testerów własnymi pomysłami na temat podejścia do testowania.

Myślę, że jest miejsce dla programistów i testerów, aby spokojnie koegzystować w dziedzinie kontroli jakości. :)

Mówiąc dokładniej, myślę, że programiści powinni być odpowiedzialni za pierwszy poziom testowania - testy jednostkowe i podstawowe testy integracyjne, aby upewnić się, że ich rzeczy działają w większości przypadków, zanim przekażą je testerom.

Do testerów należy tworzenie testów akceptacyjnych w oparciu o wymagania, które są całkowicie niezależne od wszelkich szczegółów implementacji (jest to zwykle określane jako „testowanie czarnej skrzynki”). Jeśli istnieje rozbieżność w sposobie, w jaki testerzy i programiści rozumieją wymagania, jest to problem, którym powinien zająć się kierownik projektu (jeśli taki istnieje) lub upewnienie się, że wszyscy są na tej samej stronie w fazie projektowania funkcji.

Myślę, że zarówno testowanie, jak i rozwój są działaniami opartymi na współpracy , więc oczywiście (IMO) deweloperzy powinni przekazywać testerom pomysły na testy. Nie sądzę, żeby to je zarażało lub w ogóle testowało skazy. Tester powinien oczywiście ulepszyć te testy za pomocą wielu innych metod testowania.

Jestem także wielkim fanem testerów pomagających programistom - przeprowadziłem burzę mózgów z projektantami i połączyłem je z nimi, aby naprawić błędy (oraz wskazałem błędy i sugerowane poprawki) wiele razy w mojej karierze, i nie sądzę, że ” kiedykolwiek skazywał programistę testerami.

Jeśli nie widzisz tego jako wysiłku polegającego na współpracy, po prostu kod zostanie „przerzucony nad ścianą” od dewelopera do testowania… i skończysz na niższej jakości. To prawda w moim świecie, ale (oczywiście), ymmv.

Widzę to tak, że nie jest zadaniem QA testowanie mojego kodu. Zadaniem testera jest upewnienie się, że mój kod spełnia wszystkie wymagania dla tego zadania.

Kiedy przekazuję coś do kontroli jakości, upewniam się, że znają moje zadanie, a nie specyfikę mojego kodu. Nigdy nie przekazuję niczego QA, które ma w sobie błędy „głowy kości”. To marnuje mój czas, ich czas ... i prawie każdy czas.

W mojej ostatniej pracy od początku mieliśmy do czynienia z kontrolą jakości. Dotyczyło to sesji gromadzenia wymagań, spotkań projektowych i spotkań projektowych. Słuchali i zadawali pytania, a gdy programiści pisali kod, pisali swoje plany testowe. Udało się świetnie i złapaliśmy wiele problemów, które prawdopodobnie prześlizgnęłyby się.

Wydaje mi się, że tutaj jesteś w błędzie. Byłem testerem i programistą i jako tester odniosłem wiele korzyści ze wskazówek deweloperów na temat obszarów, które uważali za grupy wysokiego ryzyka lub niestabilne; jako programista chcę, aby testerzy znaleźli problemy, których dogłębnie nie zbadałem.

Nie było „zanieczyszczenia”, chyba że twój kod to surowe ścieki, i to z zupełnie innego powodu.

Wymagania mają okropną robotę w komunikowaniu o problemach technicznych, na których by się liczył specjalista ds. Kontroli jakości, ponieważ w najlepszym razie opracowują tylko to, co analitykom biznesowym udało się uchwycić. Dobrzy programiści będą świadomi, że ich kod jest zoptymalizowany na „szczęśliwej ścieżce” i będą chcieli wiedzieć, co pozostawili bez uwzględnienia. Będą mieli przynajmniej intuicję co do tego, co może pójść nie tak i jakie obszary chcieliby zbadać w ramach kontroli jakości. Wiedzą także, jaki jest ogólny obraz ryzyka związanego z konkretną funkcją opartą na ich projekcie.

Jako że testerowi brakuje wskazówek od zespołu programistów, czasami stosowałem niewłaściwe podejście, które generowało dobre raporty o błędach, ale nie do końca korzystałem ze ścieżek kodu wysokiego ryzyka i większych problemów, których można było uniknąć dzięki lepszej współpracy wraz z zespołem programistów wysyłanym do klientów.

Podczas gdy tester z pewnością nie powinien ograniczać się do testowania tego, co zdaniem programisty jest ważne, nie zostanie on uszkodzony przez poznanie własnych obaw programistów dotyczących kodu. Czasami mogą dopracować swoje podejście w oparciu o swoją wiedzę na temat wdrażania. Tylko jeśli tester jest szczególnie krótkowzroczny, weźmie pod uwagę opinię dewelopera na temat ryzyka jako ostateczne słowo; nie będą całkowicie zamykać rzeczy, które programista określa jako niskie ryzyko, ale włożą więcej wysiłku w rzeczy, które mogą mieć większy wpływ na klienta.

Zespół kontroli jakości prawdopodobnie zobaczy obszary, które mają duży zakres testów kombinatorycznych niż zbieracze wymagań lub twórcy systemu, ale mogą nie być świadomi elementów systemu, które mają bardziej subtelny rodzaj kruchości, który korzysta ze świadomości projektu lub wdrożenie systemu.

Z mojego doświadczenia wynika, że ​​współpraca między QA a działem rozwoju zapewnia produkty lepszej jakości. Nigdy nie zalecałbym przekazywania tylko czarnej skrzynki.

Jako tester nie mam żadnych zastrzeżeń do programistów sugerujących przypadki testowe (choć nie oznacza to, że będę się trzymał tylko tych przypadków testowych) lub opisujących szczegóły implementacji. Czasami bardzo pomocne może być powiedzenie „Myślę, że ten kawałek może być ryzykowny, bardzo bym go chciał, gdybyś go dokładnie przetestował”. Znajomość niektórych szczegółów implementacji pomaga mi wykorzystać wieloletnie doświadczenie w wyborze testów, które moim zdaniem mogą się nie powieść. Czasami krótka wzmianka oznacza, że ​​kilka testów nagle powiększa moją listę priorytetów.

Czy to mnie skazi? Trochę łaskocze mnie pomysł programistów rycersko dążących do zachowania czystości testera, ale tak naprawdę - nie, to mit. Więcej informacji zwykle powoduje dla mnie jeszcze więcej pytań, nie mniej. Myślę, że to jest sposób myślenia - nie znajduję błędów, ponieważ jestem ignorantem, znajduję problemy, ponieważ jestem sceptycznym, nieufnym typem, który jest po prostu zbyt cholernie uparty, aby całkowicie polegać na zaufaniu. W każdym testowanym przeze mnie systemie stwierdzam, że znajduję więcej problemów, a im bardziej „interesujących”, tym głębiej je rozumiem.

Lubię przeglądać plany testów i sugerować dodatkowe przypadki testowe, o których QA może nie pomyślała. Nie jestem pewien, jak to „zainfekowałoby testerów własnymi uprzedzeniami”.

Znalazłem się w tak dziwnym położeniu, że muszę później zaimplementować i napisać przypadki testowe w Selenium, ponieważ brakuje personelu do kontroli jakości. Uważam, że rozwój oparty na testach byłby niezwykle pomocny, ale nie został jeszcze dostosowany w moim sklepie.

Jedną z rzeczy, które uważam za pomocne w pisaniu testów, jest to, że znajduję błędy podczas pisania testów. Myślę w innej perspektywie, aby pomóc mi napisać bardziej niezawodny kod. Ale to prawda, że ​​zasięg testu może być ograniczony. W takim przypadku QA mogą zawsze dać nam znać, co chcieliby być objęci. Lub możemy pasywnie dodać więcej testów, gdy zobaczymy błędy.

Robię kontrolę jakości i w przeciwieństwie do większości domen wiedza na temat korzystania z naszego kodu jest znacznie trudniejsza niż nauka jakiegokolwiek języka programowania. Dlatego liczymy na to, że programiści dostarczą nam przypadki testowe dla ich nowych funkcji whizzbang, ponieważ nie wiedzielibyśmy, jak to zrobić. W każdym razie problemy związane z kontrolą jakości polegają raczej na wychwyceniu regresji i rzeczy, które się psują, niż oryginalnym testowaniu nowych funkcji. W każdym przypadku, gdy wynik jest złożonym obliczeniem, trudno jest ustalić, która odpowiedź jest poprawna, a która zła, a nawet jeśli nieprawidłowe zakończenie jest dobrą lub złą rzeczą.

W każdym razie deweloper, jeśli jest szczery, prawdopodobnie wie coś o podatności swoich dzieci. Prawdopodobnie wie, przy jakich wartościach parametrów, musi wybierać różne algorytmy lub domeny podczas wyszukiwania w tabeli lub cokolwiek innego. Wiedząc, że jeśli jest szczery w kwestii rygorystycznych testów, powinien być w stanie wygenerować zestaw testów o rozsądnej wielkości, który obejmuje dużą część kodu.