Jak radzić sobie z nastawieniem „Automatyzacja jest łatwa”?

Tytuł mówi wszystko. Niektórzy pracownicy w naszej firmie uważają, że automatyczne testy są „łatwe” i że „napisanie zestawu testów COM i interfejsu użytkownika powinno zająć jeden dzień”. Co można zrobić, aby temu przeciwdziałać?

Uwaga: nie pytam o to, jak promować automatyzację. To nie jest problem. Zautomatyzowane testy i procesy są tutaj promowane i wymagane przez cały czas. Problem polega na tym, że niektóre osoby nie rozumieją, że automatyzacja nie jest „łatwa”, ani „szybka”.

Następnym razem, gdy pojawi się żądanie, spróbuj rozbić jak najwięcej procesu automatyzacji na części czasu. Myślę, że kiedy zdają sobie sprawę, że zajmuje to 5 minut na każde pole tekstowe lub naciśnięcie przycisku, zaczynają zdawać sobie sprawę, ile to trwa.

Na przykład, dlaczego tak długo trwa to, że zaczynają wprowadzać współzależność między polami: np. Zezwalają im na kontynuację tylko wtedy, gdy jest to wypełnione, ale nie, jeśli tak nie jest, z wyjątkiem sytuacji, gdy ...

Staraj się je edukować, DLACZEGO zajmuje to tyle czasu, ale nie tyle, ile tracisz je w procesie „uczenia się”.

W swoich rolach spotkałem wielu ludzi „x is easy”, szczególnie przy projektach programistycznych. Moim zdaniem istnieją trzy powody:

1) Naprawdę nie rozumieją, o czym mówią, ale bardzo lubią brzmieć jak oni.

2) Przeczytali kilka książek i myślą, że wiedzą, o czym mówią

3) Wreszcie ludzie zakładają, że komputer wykonuje testy szybko, ponieważ komputery są szybkie.

Jedynym niezawodnym sposobem walki z tym jest regularne angażowanie użytkowników, strategie komunikacyjne dla projektów są kluczowe, z pewnością wyjaśnienie tajników automatycznego testowania użytkownikom nietechnicznym będzie daremne, ale uświadamiając im o zaangażowanych procesach może być korzystne. Możesz to zrobić za pomocą dokumentacji, warsztatów lub po prostu przyjaznego czatu podczas następnego przejścia.

Widziałem nawet licencjata wyróżniającego najgłośniejszych z tych „x jest łatwych” ludzi i po prostu zapraszam ich na jeden dzień w dziale, myśląc, że albo odejdą, aby dowiedzieć się więcej o tym, co robisz, LUB zrobią to po prostu odejdź myśląc „Boże, naprawdę nie wiem o czym mówię, myślę, że się myliłem”.

Oprogramowanie to automatyzacja rzeczy.

Piszemy oprogramowanie, aby ułatwić nam nudne, powtarzalne i pracochłonne zadania. Piszemy oprogramowanie do automatyzacji tworzenia raportów, gromadzenia danych, komunikacji z innymi itd. Pisanie automatycznych testów to tak naprawdę pisanie oprogramowania, aby upewnić się, że nasze inne oprogramowanie działa tak, jak tego oczekujemy.

Jeśli Twoi współpracownicy rozumieją, że pisanie oprogramowania jest trudne i zajmuje dużo czasu, powinno być dość łatwo pokazać im, że pisanie większej ilości oprogramowania powinno być trudne i wymagać czasu. Byłoby miło uzyskać wszystkie zalety automatyzacji za darmo, ale jak zwykle musimy z góry wykonać pracę, aby uzyskać korzyści później.

Jeśli tego nie rozumieją, musisz albo popracować nad ich nauczeniem, albo dopracować swoje CV.

Większość pracowników spędza czas albo w „froncie” (klient-szef-interesariusz-strona) części firmy, albo w „zapleczu” (gdzie wykonuje się „prawdziwą” pracę). Te dwie funkcje są różne, prawie przeciwnie. (I bardzo niewiele osób pracowało w obu). W rezultacie często występują nieporozumienia między obiema grupami.

Najlepszym sposobem na edukację np. „Frontowych” ludzi jest poprowadzenie jednego lub kilku z nich na „tyłach”. Gdyby ukończyli „Dzień z życia ...”, mieliby bardziej realistyczne wyobrażenie o tym, co można zrobić w ciągu jednego dnia, i dlaczego przeprowadzenie automatycznych testów zajmuje więcej czasu i wysiłku. Podobnie ludzie „z tyłu” mogliby skorzystać z dnia lub dwóch na „froncie”.

W „How to be Rich” John Paul Getty (potentat swoich czasów) opowiadał się za takim „treningiem krzyżowym”. Jego zdaniem sprzedawca, który spędził czas na linii montażowej, na której wytwarzany był produkt, wykonałby znacznie lepszą sprzedaż, a także inżynier, który spędził dzień z klientami, wykonałby lepszą robotę „debugowania”.

Problem polega na tym, że niektóre osoby nie rozumieją, że automatyzacja nie jest „łatwa”, ani „szybka”.

Nie zgadzam się z twoją przesłanką tutaj.

Jestem wielkim zwolennikiem testowania automatycznego, bez względu na to, czy jest to test jednostkowy, test integracji lub test interfejsu użytkownika. Istnieje wiele świetnych narzędzi do wdrażania automatycznych testów.

Porównajmy testy automatyczne z testowaniem ręcznym na podstawie następującego przykładu:

W aplikacji internetowej przetestuj funkcję „Zmień hasło” istniejącego użytkownika za pomocą przeglądarki.

Testowanie ręczne :

• Uruchom aplikację internetową
• Otwórz przeglądarkę
• Cholera, jest błąd. Dlaczego? Och, zapomniałem uruchomić bazę danych!
• Ok, zamknij aplikację internetową
• Uruchom bazę danych
• Uruchom aplikację internetową
• Odśwież przeglądarkę
• Hmm, jakie było hasło naszego użytkownika testowego?
• Spojrzenie na bazę danych
• Och, tabela użytkowników jest pusta! Muszę utworzyć nowego użytkownika.
• Zarejestruj nowego użytkownika w aplikacji internetowej: Wprowadzanie nazwy użytkownika, hasła, adresu e-mail
• Dlaczego nie mogę się zalogować przy użyciu nowego użytkownika? Och, muszę kliknąć link potwierdzający w wiadomości e-mail!
• Dałem użytkownikowi wiadomość e-mail w rodzaju „test@example.com”. Przejdźmy do bazy danych i ustaw „aktywną” kolumnę na „Tak”.
• Zaloguj sie. Tym razem to działa!
• Hmm, co chciałem przetestować ponownie ...?

Łatwy? Nie całkiem. Istnieje wiele możliwych pułapek.

Szybki? Nie. Praca ręczna wymaga czasu.

Teraz spróbujmy napisać test automatyczny :

• Musimy znaleźć narzędzia dla naszego języka programowania, aby automatycznie uruchomić bazę danych i serwer WWW. Badania i wdrożenie wymagają czasu.
• Baza danych musi znajdować się w stanie czystym po uruchomieniu testu. Tworzenie skryptów wymaga czasu.
• Musimy napisać test. Ponieważ potrzebujemy użytkownika, musimy również zarejestrować nowego do naszego testu. Zabiera czas.
• Na koniec możemy napisać, co chcemy przetestować: Zmiana hasła użytkownika. Dzięki naszemu narzędziu do testowania przeglądarki robi się to dość szybko w porównaniu do poprzednich zadań.

Łatwy? Nie! Musieliśmy zbadać narzędzia, wdrożyć je, naprawić niektóre błędy w naszych testach.

Szybki? Nie! Trwa to nawet dłużej niż wykonanie testu ręcznego.

Jest jednak duża różnica: w przyszłych testach wystarczy napisać sam test , ostatni punkt na liście - co zostało zrobione porównywalnie szybko. Wszystkie badania i skrypty inicjujące nie muszą być wykonywane do dalszych testów.

A po napisaniu testu możesz łatwo rozpocząć. Po kilku sekundach (a może minutach, jeśli uruchomienie bazy danych i aplikacji zajmuje dużo czasu), zobaczysz, czy procedura „Zmień hasło” działa, czy nie. Jeśli występuje błąd, napraw go i ponownie uruchom test - od razu zobaczysz, czy błąd został naprawiony. Szybko i łatwo .

Pisanie automatycznych testów nie jest ani łatwe ani szybkie, ale ich wykonanie jest takie.

I w tym momencie wraca zainwestowany czas.

Testowanie ogólnie nie jest łatwe i nie powinno być. Gdyby Boeing lub Mercedes nie testowały swoich produktów tak rygorystycznie jak wtedy, albo zbankrutowałyby z powodu pozwów sądowych, albo przestałyby sprzedawać tak niskiej jakości produkty. Czy prowadziłbyś samochód z prędkością 70 mil na godzinę, wiedząc, że kierownica może spaść na kawałki?

Bardzo trudno jest zasugerować sposoby radzenia sobie z tym sposobem myślenia bez zrozumienia, kim są ci ludzie lub jakie są ich powody. Większość menedżerów i dyrektorów myśli o kosztach i jest oceniana na podstawie tego, co powstaje. Zastosowanie tych kryteriów bardzo utrudnia im uzasadnienie spędzania czasu na testach. Jeśli tak jest w przypadku ciebie, będziesz musiał znaleźć sposoby, aby przedstawić to zadanie jako korzystne na dłuższą metę, co oczywiście jest.

To, że oprogramowanie nie jest namacalne, nie oznacza, że ​​możemy uciec bez zastanowienia się nad konsekwencjami nieudanych systemów, które budujemy. Założę się, że Amazon ma zautomatyzowane testy i założę się, że są tam ludzie, którzy zbyt dobrze znają skutki awarii swoich witryn / usług.

2 +2 = 4 to jeden z najprostszych fragmentów kodu, który wszyscy rozumieją; I możesz zobaczyć, jak łatwo to zrozumieć. Ale to nie znaczy, że jest to „łatwe” równanie. Poziom abstrakcji potrzebny do uzyskania prostego równania jest dość złożony. To samo dzieje się z oprogramowaniem i metodologiami testowania oprogramowania. Poziom abstrakcji, który wymaga fragmentu kodu, zajmuje dużo pracy.

Prawdą jest, że dobra praktyka prowadzi do ponownego wykorzystania klas i przedmiotów, ale aby osiągnąć ten stan, konieczne jest zainwestowanie czasu i wysiłku .

Istnieją dwie strony tego pytania.

Po twojej stronie wydaje się, że dobrze sobie radzisz i że grupa „Automatyzacja jest łatwa” nie wie, o czym mówią.

Po swojej stronie, z tego, co mówisz, widzą, że zautomatyzowane testy zabierają (ich zdaniem) długi czas na produkcję.

Z tej odległości, przy niewielkim nakładzie pracy, nie wiemy, kto ma rację, czy też ktoś ma rację.

Sposób radzenia sobie z automatyzacją jest prosty

Porozmawiaj z nimi. Szczerze zapytaj o ich pomysły, jak to zrobić lepiej. Zaangażuj ich i zaangażuj. To jedyny sposób, aby dowiedzieć się, czy naprawdę mają coś pozytywnego do zaoferowania. Być może mają one jakiś cenny wkład, a ty możesz wygrać / wygrać.

Jeśli nie mają rzeczywistego pojęcia, jak działa programowanie i automatyczne testowanie, ani realistycznych pomysłów na poprawę produktywności, to po zaangażowaniu ich pozytywnie możesz pokazać, jak to się robi i gdzie czas. Bądź pokorny i pozytywny, dziękując im za ich wkład / pomysły. Pomyśl o tym, co powiedzieli: może ich sugestie wprowadzą inny sposób myślenia. Jeśli tak, przekaż im tę opinię. Będąc pokornym i pozytywnym, możesz sprawić, że wygrana / wygrana również.

Zanim z nimi porozmawiasz, zastanów się, jak zbudować, uruchomić i zarządzać testami. Z jakich ram korzystasz? Czy są inne, które mogłyby być lepsze? Czy masz „standardowy” bojler, który dostosowujesz? Czy tworzenie testów może być bardziej zautomatyzowane? Co Cię powstrzymuje?