Jak zachęcić klienta do wykonania wewnętrznych testów jakości?

14

Aktualizacja / Wyjaśnienie Mój klient rozumie potrzebę przeprowadzania wewnętrznych testów i zawsze przysięga, że ​​„zrobi to lepiej” (tj. Zrobi coś), ale tak się nie dzieje. Nie mają budżetu na testy zewnętrzne. Chyba pytam (niejasno, potwierdzam) o to, co może zaszczepić „test wcześnie, test często, test etosu docelowych maszyn?

Pytanie: jak zachęcić użytkowników do poświęcenia czasu na jawne testowanie i zgłaszanie problemów z nowymi wersjami, a nie do „testowania w trakcie pracy” w projektach produkcyjnych.

Tło: Mam małego klienta, dla którego napisałem pakiet multimedialnych narzędzi do prezentacji. Są miłym klientem i mamy dobre relacje. Projekt jest w toku, dodając kolejne funkcje.

Mam dwa problemy:

  1. Definiowanie funkcji odbywa się w locie, często przez telefon, z zastrzeżeniem zmiany, zmiany, cofnięcia. (trochę jak Kennedy'ego: „Pójdziemy na księżyc i robimy inne rzeczy” - zawsze mnie to bawiło w części „inne rzeczy”)

  2. Na ich końcach praktycznie nie przeprowadza się testów jakości.

Mogę poradzić sobie z numerem 1, mniej więcej. To nie jest klient, który czytałby specyfikację przed spotkaniem, nie mówiąc już o jej napisaniu. Przyzwyczaiłem się do tego. Jest to problem nr 2, z którym mam problem: nie testują lub nie testują nowych wydań. Używają ich do produkcji, więc kiedy pojawiają się błędy, albo znajdują obejście i nie zgłaszają tego, albo tak bardzo spieszą się z projektem, że zgłoszenia błędów są niejasne.

Rozmawialiśmy o tym wszystkim, ale udało mi się tylko trochę je podeprzeć (np. Używamy github do śledzenia problemów - choć głównie tego używam). Główne przyczyny są dwojakie: są małą firmą konsultingową i nie mają (lub nie sądzą, że mają) zasobów do testowania (ani budżetu na outsourcing). I kulturowe: chociaż uważają się za „programistów”, tak naprawdę są tylko użytkownikami pakietu oprogramowania multimedialnego. (np. nie zwracają uwagi na obsesyjną nerwicę na szczegóły „prawdziwych” programistów).

Wpływa to na mnie tak, jak można się spodziewać: bez informacji zwrotnej nie mogę stwierdzić, czy funkcja jest ukończona (patrz # 1), czy też są inne konsekwencje. To też sprawia, że ​​jestem trochę leniwy.

Bez chwytania
źródło
3
Jeśli błąd jest tak mały, że sami użytkownicy nie dbają o to, czy zostanie naprawiony, czy nie, dlaczego nalegasz?
kamilk,
2
@kililk - krótka odpowiedź jest taka, że ​​zainwestowałem w mojego klienta, który ma się dobrze, jest produktywny itp. Długa odpowiedź jest taka, że ​​często nie jest to kwestia „małego” błędu - może to być również problem z użytecznością, brak implementacji funkcji itp. Jeśli nie wiem o tym, nie mogę tego naprawić. Ponadto „obejścia”, które wymyślają, są dla nich ogromnym marnotrawstwem czasu lub nawet trzymaniem się wcześniejszych wersji oprogramowania.
Brak chwytania
18
Jeśli jesteś zainwestowany w klienta, który ma się dobrze; powinieneś zadbać o bardzo solidne testy przed ich wydaniem. Klienci nie są testerami. Zatrudnij testera lub przeprowadź własne testy lub napisz kodowane testy, ale jeśli chcesz mieć absolutną pewność, że Twoje produkty działają dla klientów, przetestuj je, zanim je podasz.
Jimmy Hoffa,
4
@djechlin - w ogóle chodzi o testowanie (i raportowanie). A programista może tylko tyle przetestować: nie używam go tak, jak użytkownicy.
Brak chwytania,

Odpowiedzi:

18

nie zwracają uwagi na obsesyjną nerwicę na szczegóły „prawdziwych” twórców

Przedmowa : Rodzaj języka, którego tu użyłeś, jest dla mnie zwykle czerwoną flagą. Kiedy słyszę, jak ludzie mówią o „prawdziwych” programistach lub (jednym i jedynym) „właściwym” sposobie działania, zaczynam myśleć o twórcach kultu wizjonerów tunelowych .

Nie twierdzę, że zdecydowanie jesteś jednym z tych programistów (nie mam wystarczających dowodów, aby to potwierdzić), ale jeśli tak, to możesz skorzystać z tej odpowiedzi.

Odpowiedź

Wygląda na to, że Ty i Twój klient optymalizujecie różne rzeczy. Jest to niefortunny fakt w inżynierii oprogramowania, że ​​często potrzeby biznesu i pragnienia programistów niekoniecznie się pokrywają.

Twórcy oprogramowania to często ludzie z pasją, którzy koncentrują się na doskonaleniu. Lubią poprawiać wydajność oprogramowania, proces rozwoju, procesy biznesowe, metody komunikacji itp. I to świetnie. Skupienie się na tych rzeczach odróżnia rzemieślników i rzemieślniczki od bezmyślnych manipulatorów.

Ale twój klient nie jest rzemieślnikiem oprogramowania. Twój klient to firma z zupełnie innym zestawem priorytetów. Czasami te priorytety wyglądają absurdalnie dla naszych twórców oprogramowania ... ale to tylko dlatego, że optymalizujemy różne rzeczy.

Firmy często chcą optymalizować takie rzeczy, jak wczesne wprowadzenie na rynek i krótkoterminowe oszczędności. W ten sposób mogą być zmuszone poświęcić takie rzeczy, jak kontrola jakości, wrażenia użytkownika, długoterminowe oszczędności kosztów i inne rzeczy, które sprawiają, że programiści muszą działać.

Czy to źle? Cóż, niekoniecznie. Nie mogę mówić w imieniu wszystkich firm, ale z mojego doświadczenia wynika, że ​​moi klienci robią te rzeczy, aby zwiększyć swój zwrot z inwestycji (zwrot z inwestycji). Czynności takie jak zapewnianie jakości, udoskonalanie UX i długoterminowe planowanie zapewniają im niższy zwrot z inwestycji. Co gorsza, wiele firm ma struktury inwestycyjne, które nagradzają tylko wygrane krótkoterminowe, a nie zrównoważone podejścia i wygrane długoterminowe.

Tak więc, podczas gdy mógłby próbować sprzedać ideę QA do klienta może być marnowania czasu, a wytężając siły swoje relacje z nimi. W najlepszym przypadku spotkasz kogoś chętnego do wypróbowania twoich pomysłów (mało prawdopodobne). W najgorszym przypadku będziesz musiał przekonać całą firmę do zmiany jej struktur motywacyjnych, aby nagrodzić długoterminowe inwestycje, takie jak zapewnianie jakości. W obu przypadkach szanse powodzenia są niskie.

MetaFight
źródło
4
+1, próbując zmienić wewnętrzne funkcjonowanie całej innej firmy, ponieważ nie wydaje ci się to właściwe , zwykle przerywa związek. Specjalista powinien doradzić, czy może przewidzieć poważne problemy, zwłaszcza jeśli może również doradzić, jak je złagodzić. Jednak jeśli problemy są tak małe, że firma nawet nie zadaje sobie trudu, aby je zgłosić, najlepiej od czasu do czasu wysłać przyjacielskie przypomnienie, że może zaoszczędzić czas, jeśli X lub Y nie nalegają.
Ordous,
-1, ponieważ jest to dobrze napisany post, ale tak naprawdę nie odnosi się do pytania, jak byś to zrobił. Odpowiedź brzmi: robisz to w bardzo podobny sposób, w jaki przekonujesz zwykłych programistów do testowania: pokaż, że testowanie pomaga zmniejszyć ryzyko. Mniejsze ryzyko == mniej problemów z produkcją w trakcie prezentacji klienta.
David mówi Przywróć Monikę
Nie - daleko od bazy, ale dziękuję za odpowiedź.
Brak chwytania,
@DavidGrinberg to wszystko dobrze, chyba że zmniejszenie liczby problemów produkcyjnych nie jest warte wysiłku / kosztów / czasu dla klienta. W takim przypadku żadna logika programisty nie przekonuje ich do poświęcenia ROI tylko po to, aby cię zadowolić. I dlatego ja nie odpowiedział na how na pytanie i zamiast tego koncentruje się na potencjalną wadę w jego założeniu.
MetaFight,
rzemieślnicy :-)
Toni Leigh
10

Interesujące pytanie brzmi: kiedy otrzymasz zapłatę, a nie to, czy Twój klient sam wykonuje jakieś testy.

  • jeśli otrzymujesz zapłatę na podstawie czasu, nie ma problemu.
  • jeśli otrzymasz płatność z góry, nie ma problemu.
  • jeśli dostaniesz zapłatę, gdy klient uzna projekt za „zakończony”, duży problem.

Problem polega na tym, skąd możesz wiedzieć, kiedy klient zaakceptuje oprogramowanie i zapłaci ci. To oczywiście nie działa, gdy klient stale zmienia projekt z niejasno zdefiniowanymi nowymi żądaniami. Jeśli oznacza to, że dzień wypłaty jest zawsze odraczany - i staje się bardziej mało prawdopodobny przy każdym żądaniu - staje się to dla ciebie niemożliwe.

Stała umowa, która dokładnie określa wszystkie funkcje i określa warunki, na jakich klient zaakceptuje te funkcje, jest wyraźnie bardzo niewygodnie surowa, ale umożliwia wcześniejsze zaplanowanie projektu (także następnego projektu). Gwarantuje również, że dostaniesz pieniądze za dostarczone oprogramowanie, jeśli spełnia ono wymagania specyfikacji. W takim scenariuszu jedyną odpowiedzialność klienta spoczywa na etapie definiowania umowy, a na końcu za testem akceptacyjnym .

Takie testy akceptacyjne wykonywane przez klienta są niezależne od innych form testowania:

  • testy jednostkowe
  • testy integracji systemu
  • testy użyteczności
  • testy obciążenia
  • testy przedpremierowe

O ile to możliwe, należy przewidzieć testy akceptacyjne i wykonać je samodzielnie przed dostarczeniem funkcjonalności, aby uniknąć kłopotów. Oprócz testów akceptacyjnych (które mierzą tylko wykonanie umowy , a nie jakość oprogramowania ), odpowiedzialność za zapewnienie jakości spoczywa na tobie. W szczególności twój klient niekoniecznie ma nastawienie do zapewniania jakości, niezbędne zaplecze techniczne lub umowny obowiązek przeprowadzenia kontroli jakości. Uważam też, że outsourcing wyszukiwania błędów do klienta jest dość nieprofesjonalny.

Nie oznacza to, że błędy się nie zdarzają. Zakładając, że masz relację opartą na projektach z klientem, będziesz chciał przejść od uprzejmości do szybkiego dostarczania poprawek i wyjaśnić, że zaakceptowali obecną wersję jako wystarczającą do ich potrzeb - duże zmiany wymagają nowej umowy. Jeśli masz stałą umowę wsparcia, musisz oczywiście przestrzegać ustalonego poziomu usług.

W zwinnym otoczeniu reagowanie na potrzeby klientów jest cenione bardziej niż trzymanie się litery umowy, ale nadal będziesz chciał otrzymywać zapłatę. Dlatego wiele metodologii projektów zorientowanych na zwinność ceni ścisłą interakcję z klientem do tego stopnia, że ​​klient może stać się częścią zespołu. Możesz wtedy zawsze porozmawiać z tym „właścicielem produktu”, aby wyjaśnić wszelkie niezbędne kwestie. Ponieważ organizacja zamawiająca ma prawo dać ci czas na pracę nad dowolną funkcją, którą uznają za cenną, może to zadziałać nawet w przypadku niejasnych potrzeb klienta. Jeśli nie masz tak bliskiej komunikacji, będziesz musiał zastosować bardziej formalne podejście.

  • Kiedy dowiesz się o potrzebach nowego klienta, pracuj z nim, aby przełożyć go na wymagania. Pomaga to klientowi uzyskać to, czego naprawdę chce.
  • Wymagania są obiektywnie mierzalne - są albo spełnione, albo nie. To oszczędza klientowi pół-rozwiązań, które są tylko rodzajem pracy.
  • Wszystkie żądania klientów muszą być przekazywane w formie pisemnej, aby można było je rozliczyć. Chroni to ich przed naliczaniem opłat za rzeczy, nad którymi po prostu chciałeś pracować - na przykład przepisywanie całego interfejsu, gdy pytasz o przycisk, który ma zostać wyrównany w inny sposób.

    Dużo komunikacji można wykonać osobiście lub przez telefon, ale na końcu chcesz, aby kawałek papieru udokumentował, że klient chciał, abyś pracował nad tymi wymaganiami. W prostych przypadkach może być wystarczające podsumowanie połączenia telefonicznego i wysłanie do nich wiadomości e-mail w celu zweryfikowania, o co Cię poprosili.

Zgłoszenia błędów są zawsze trudne. Jeśli Twoi klienci sami są deweloperami, powinno to pomóc, ponieważ mogą zrozumieć Twoje potrzeby: mieć wyraźne kroki do reprodukcji. Prostym sposobem na uzyskanie silnego wglądu jest umożliwienie logowania do wdrożonego oprogramowania. Pod warunkiem, że można rozwiązać problemy związane z prywatnością danych, wymagając, aby każdy raport o błędzie miał dołączony bieżący dziennik, nie tylko gwarantuje pewną pisemną komunikację, ale także mówi, co faktycznie zrobił użytkownik (w przeciwieństwie do tego, co sądzili, że próbowali zrobić) .

amon
źródło
1
Pieniądze nie są problemem (jestem na miesięcznym koncie - otrzymuję zapłatę, czy koduję, czy nie). To jak podważyć ich kulturę biurową ... lub coś, czego nie rozumiem.
Brak chwytania,
2

Sposobem zachęcania do komunikowania błędów jest zachęcanie do częstej, szczegółowej komunikacji funkcji. Jeśli wyszkolisz firmę, która może prosić o cokolwiek bez ceremonii, użyją tej funkcji również w przypadku drobnych błędów. Zrezygnuj ze zmiany przepływu pracy klienta, chyba że zmiany te ułatwią mu życie.

Nakłonienie klienta do przeprowadzenia wewnętrznych testów jest trudne, ale nakłonienie go do faktycznego zgłoszenia błędów nie jest tak trudne, jak się wydaje. Aby uzyskać więcej informacji zwrotnych, należy zmniejszyć tarcie użytkownika ... nawet jeśli oznacza to przeniesienie części tego tarcia na siebie.

  1. Używaj prostszych narzędzi, nawet jeśli są one nieodpowiednie i nieodpowiednie. Na przykład BaseCamp jest dość okropnym narzędziem do śledzenia błędów (ponieważ jest przeznaczone do zarządzania projektami), ale ludzie tak naprawdę chcą go używać.

  2. Ponieważ używane przez nas narzędzia do śledzenia błędów nie obsługiwały kopiowania i wklejania obrazu, napisałem prosty program, który kopiuje bieżący obraz ze schowka na dysk (jako Guid), a następnie kopiuje go do schowka. Po minimalnym przeszkoleniu użytkownik może dołączyć obrazy ze schowka do problemów, po prostu naciskając ekran drukowania, klikając przycisk, a następnie wklejając do okna wyboru plików narzędzia do zgłaszania błędów.

Zrzut ekranu (prawdopodobnie edytowany w MS Paint z adnotacjami) i 1-2 zdania wystarczy, aby wskazać większość funkcji / błędów.

Obie te propozycje są kierowane punktów tarcia które ja doświadczyłem, a oba te sugestie raportowania wzrosła o czynnik ponad 10. Jednak trzeba będzie kierować swoje własne punkty tarcia.

Brian
źródło
Ta odpowiedź przechodzi do sedna. Chcesz, aby wdrożyli rygorystyczne protokoły testowe: jest to bardzo mało prawdopodobne, szczególnie jeśli pochodzi spoza organizacji (np. Ciebie). Najlepszą rzeczą do zrobienia w tym przypadku, skoro i tak dostajesz zapłatę, jest możliwie bezbolesne zgłaszanie błędów. Jeśli naprawdę nie masz ochoty na dokładne testowanie, zrób to sam i dowiedz się więcej o procesach biznesowych, jeśli potrzebujesz ... To niefortunna rzeczywistość, że wiele firm nigdy nie będzie priorytetem w testowaniu.
DrewJordan,
1

Uprość testowanie swojego klienta, ale naprawdę utrudnij mu korzystanie z nowych funkcji w niesprawdzonej wersji w produkcji. Można to zrobić w następujący sposób:

Ilekroć dostarczasz nową funkcję, wdrażasz ją najpierw w „wersji beta”, wyraźnie oznaczonej znakiem „nie do produkcji”. Udostępniasz tę wersję beta klientowi do przetestowania. Podajesz także najnowszą „wersję produkcyjną”, której będzie używać do rzeczywistej produkcji (bez nowych funkcji, ale z najnowszymi poprawkami błędów) i odmawiasz przeniesienia nowych funkcji beta do wersji produkcyjnej, dopóki nie dostaniesz opinii od kogoś strona klienta przynajmniej wypróbowała to jako pierwsza.

Jeśli klient zacznie używać wersji beta na swoich rzeczywistych danych produkcyjnych, chociaż zawsze wyświetla duży komunikat „Nie do użytku produkcyjnego” przy każdym uruchomieniu programu, to nie możesz mu pomóc, ale przynajmniej wyjaśniłeś, że za każdym razem, gdy traci on produkcję pracować, ponieważ użył wersji beta do niewłaściwych celów, że to wyraźnie jego wina. Jeśli klient nie wyciąga z tego wniosków, możesz rozważyć możliwość wyłączenia przez klienta możliwości używania „wersji beta” podczas produkcji, dezaktywując niektóre kluczowe funkcje, takie jak zapisywanie wyników na dysku w wersji „beta”, jeśli to konieczne.

Zapewnienie osobnej „wersji beta” zmusi cię do ustanowienia właściwej kontroli wersji / zarządzania konfiguracją, abyś mógł bez problemu zarządzać działem produkcji i oddziałem testów beta. Ale ponieważ pracujesz z Githubem, myślę, że już używasz czegoś takiego jak GIT, co czyni ten rodzaj zarządzania bardzo prostym.

Doktor Brown
źródło
Naprawdę nie zgadzam się z pierwszym akapitem. Często ludzie naprawdę zdają sobie sprawę, że coś jest ważne, ale nie robią tego (na przykład rzucenie palenia). Testowanie jest klasycznym przykładem czegoś takiego: nawet jeśli zdajesz sobie sprawę, że jest to naprawdę ważne, wymaga dużej dyscypliny, aby nie stosować skrótów w obliczu terminów itp. Jednak pomysł na wersję beta jest dobry, biorąc pod uwagę deklarowana przez klienta chęć bycia lepszym w testowaniu.
Użyłbym tego również jako okazji do zajęcia się punktem 1. Zaproponuj klientowi cały proces, w którym nowe wymagania są spisywane, uzgadniane, testowane w środowisku nieprodukcyjnym, a następnie wydawane.
Nowe wydania oznaczam jako „alfa” lub „przedpremierowe - nie do produkcji”, a także robię cały „kamień milowy” na github z problemami (błędy, nowe funkcje do przetestowania itp.), Ale nie udało się różnica. Cała sytuacja mnie w pewien sposób wprawia w zakłopotanie. Zaproponowałem coś w rodzaju comiesięcznego testowania błędów podczas „dnia pizzy”, aby skupić swój zespół (2-3 osoby) na testowaniu, „głosować na twoją ulubioną / najbardziej irytującą kwestię”. To trochę dziwne - ale używają mojego oprogramowania przez cały czas do dużych prezentacji, więc nie rozumiem, dlaczego nie ma więcej odpychania. Podejrzewam, że należy do „innej rzeczy do zrobienia / nie do mojej pracy”
No Grabbing
@TOMATO: czy zdecydowanie odmawiasz przeniesienia funkcji z wersji przedpremierowej do wersji produkcyjnej, dopóki klient nie powie, że przetestował tę funkcję? Czy Twój klient próbuje ominąć tę odmowę?
Doc Brown,
2
+1 za wyraźnie oznaczoną wersję beta: jeśli rozdasz wersję testową jaskrawym fioletem, z wielkim zielonym migającym sztandarem u góry głównego ekranu krzyczącym „WERSJA TESTOWA - NIE DO UŻYCIA PRODUKCYJNEGO - NIEBEZPIECZNY - AAARGH! ”, nie będą go używać do prezentacji ani nawet gdziekolwiek, gdzie klient może to zobaczyć. Możesz powstrzymać czystą wersję produkcyjną (jeśli to możliwe, weź ją jako zakładnika), dopóki nie przekażą oni użytecznych informacji zwrotnych.
Christian Severin,