Czy testerzy powinni zatwierdzać wydania, czy po prostu informować o testach?

20

Czy sensowne jest przyznanie uprawnień do wypisywania się testerom? Powinien zespół testowy

  1. Po prostu przetestuj funkcje, problemy itp. I po prostu zgłoś na zasadzie pozytywnej / negatywnej, pozostawiając innym działanie na podstawie tych wyników lub
  2. Czy masz uprawnienia do samodzielnego wstrzymywania wydania w oparciu o te wyniki?

Innymi słowy, czy testerzy powinni być zobowiązani do wyrejestrowania się w wydaniach? Zespół testujący, z którym pracuję, uważa, że ​​tak, i mamy z tym problem ze względu na „pełzanie zakresu testowania” - odmowa zatwierdzenia wydań czasami opiera się na problemach wyraźnie nie poruszonych w danym wydaniu.

testing release-management process Ernest Friedman-Hill
źródło
2
Przeredaguj swoje pytanie, aby nie było ankiety. Jaki problem próbujesz rozwiązać?
M. Dudley,
5
„powinien” zależy w dużej mierze od struktury organizacyjnej firmy. Jeśli zostaną zmierzone na podstawie błędów znalezionych podczas produkcji, umiejętność utrzymania wydania z błędami jest niezbędnym narzędziem.
Doskonały punkt, @MichaelT. W mojej organizacji testowanie jest raczej rolą niż opisem stanowiska, a ocena jest bardziej doraźna, a nie ilościowa. Pomyślne wdrożenia byłyby źródłem pozytywnych recenzji, ale błędy produkcyjne nie byłyby konkretnymi negatywami, bardziej niż dla kogokolwiek w zespole.
Ernest Friedman-Hill
5
Jeśli masz problem polegający na tym, że testerzy odmawiają zatwierdzenia wydań na podstawie problemów, których nie planuje się rozwiązać, masz problem z komunikacją (nie wiedzą, że problemy nie są planowane do rozwiązania) lub problem z ludźmi (stają się ważni; czy wydanie jest ostatecznie decyzją biznesową).
Jan Hudec

Odpowiedzi:

27

Większość miejsc, w których pracowałem, ludzie ds. Kontroli jakości mają jakiś krok podpisu, ale nie mają ostatecznego upoważnienia, czy wydanie będzie kontynuowane, czy nie. Ich podpisanie oznacza, że ​​zakończyli testy oczekiwane w planie wydania, a nie, że wydanie jest bezbłędne.

Ostatecznie QA! = Firma i firma musi zdecydować, czy jest w porządku z wdrożeniem kodu w bieżącym stanie, czy też korzyść przeważa nad wadą lub czymkolwiek. Jest to często wykonywane przez klientów lub interesariuszy bezpośrednio przed wdrożeniem i często nazywa się to Akceptacją użytkownika.

Jeśli twoja kontrola jakości jest również twoją grupą akceptacji użytkowników, istnieje możliwość, że mają oni uprawnienia do zdefiniowania twojego kandydata do wydania jako niedopuszczalnego, ale jeśli otrzymujesz to z powodu problemów, które są poza zakresem poprawki / iteracji / sprintu / zmiany prośbą / czymkolwiek poświęcisz swój czas, wtedy Kierownik Projektu lub interesariusze linii biznesowej muszą przybyć na spotkanie Jezusa z zespołem QA.

Zgłaszanie istniejących usterek lub niezamierzonych skutków nowych wymagań jest w porządku, ale jeśli jest ono poza zakresem i nie jest katastrofalne, generalnie nie jest dopuszczalne oznaczanie go jako problemu blokującego. W zaległościach właściciel produktu ma priorytet, tak jak wszystko inne.

Rachunek
źródło
Kto decyduje, czy zaprosisz klienta do przeprowadzenia testu akceptacji kompilacji 1234, czy też nie jest on wystarczający do przeprowadzenia testów akceptacji?
Bart van Ingen Schenau
3
@BartvanIngenSchenau: Właściciel produktu / kierownik projektu musi mieć na ten temat ostatnie słowo. Ponieważ często nawet testy akceptacyjne będzie wybrzuszenie w razie potrzeby (chcesz funkcja X teraz chociaż nie możemy dostać Y do pracy z nim, czy chcesz poczekać jeszcze 2 miesiące, aż to naprawić?) I właściciel produktu negocjuje to.
Jan Hudec
oprócz tego, co powiedział Jan, w wielu metodologiach istniałby tu harmonogram lub kadencja. niektórzy ludzie wdrażają każdego kandydata, który przeżyje początkowy test dymu do UAT, niektórzy automatycznie wdrażają wszystko sprawdzone w gałęzi kandydata, niektóre wszystko, co jest sprawdzone w głównym. idealnie pokazujesz postępy interesariuszy, jakoś idziesz, więc nie powinno być zaskoczenia na końcu. w niektórych przypadkach kończy się pokazywanie interesariuszom, co ludzie QA ciągnęli przez węgle, a oni po prostu mówią „kogo to obchodzi” i to koniec.
Bill
We współczesnym SaaS z ciągłym wdrażaniem cykl wdrażania kodu (usługi) może być niezależny od cyklu wydania funkcji (biznesowej). Ten cykl wydawania funkcji można wdrożyć za pomocą flag funkcji lub przełączników, np. Od wersji alfa (wewnętrznej) do wersji beta (opcjonalnej) do ogólnej dostępności. Jest to jeden ze sposobów angażowania bardziej formalnego podpisu biznesowego, niezależnie od możliwości wdrożenia określonego kodu lub usług i niezależnie od tego. Przeciwnie, wiązanie wydań funkcji do wdrożeń usług wprowadza sprzężenie i ryzyko do procesu, którego można uniknąć dzięki technice flag cech.
Czy
@will Nie zgadzam się, ale ktoś nadal sprawdza, czy te ukryte funkcje są wystarczająco ukryte, aby nie zostać zauważonym przez użytkowników innych niż zespół beta przy pierwszym wdrożeniu i ostatecznie wszędzie tam, gdzie użyłem tego podejścia mniej więcej tak samo, ale z różnymi etykietami na ruchomych częściach i ryzyko nieco się zmieniło. Wolę opisywaną sytuację, ale zespół ds. Kontroli jakości znajdujący coś wcześniejszego lub menedżer produktu i tak decydujący się na kontynuację jest w tym modelu tak samo ważny jak każdy inny z moich doświadczeń.
Bill
6

Somebody potrzebuje tego autorytetu . Nieważne, czy jest to tester, zespół testerów, lider zespołu testerów, czy lider organizacji programistycznej. A może dokładniej, zależy to od organizacji.

Ostatecznie wybór wydania oprogramowania jest funkcją biznesową.Firma musi zdecydować, czy jakość jest odpowiednia. Zapewne dyrektor ds. Zapewnienia jakości powinien podjąć tę decyzję lub przekazać tę decyzję odpowiedniej jednostce biznesowej. Wszystko zależy od wielkości firmy, względnego znaczenia jakości itp.

Biorąc to wszystko pod uwagę, informacje wykorzystane do podjęcia decyzji zaczynają się od testera . Niezależnie od tego, czy mają moc zatrzymania wydania, czy nie, powinni czuć się odpowiedzialni za poinformowanie decydentów, gdy zobaczą coś, co ich zdaniem powinno spowodować opóźnienie wydania.

Bryan Oakley
źródło
6

Nadanie uprawnień do wypisywania się (tj. Prawo weta) dla wydań testerom ma tyle samo sensu, co przyznanie tego prawa programistom: w ogóle nie ma.

Testerzy i programiści to przede wszystkim ludzie techniczni, więc mogą podejmować decyzje głównie z przyczyn technicznych. Jednak obawy, które należy rozważyć przy wydawaniu wersji, dotyczą zarówno kwestii technicznych, jak i biznesowych. Oczywiście klient nie będzie zadowolony, jeśli dostarczysz produkt, który zawiera błędy, ale będzie równie niezadowolony, jeśli będziesz odkładał wydanie, ponieważ nadal występują otwarte problemy z produktem.

Ktoś musi znaleźć właściwą równowagę między dobrym produktem a przestrzeganiem harmonogramu obiecanego klientowi. Aby to zrobić, należy nie być zaangażowane w projekt w roli czysto technicznym, lecz w bardziej zorientowane na biznes / zarządzania jak rola kierownika projektu lub właściciela produktu i zabrać swoje wejście od testerów i programistów.

Bart van Ingen Schenau
źródło
1
Głosowałem za tym, ponieważ zasadniczo nie zgadzam się z kilkoma punktami i założeniami, które przedstawiliście. Nie zgadzam się, że kontrola jakości nie powinna mieć uprawnień do zawetowania wydania, ponieważ wiele grup kontroli jakości również działa w roli akceptacji użytkownika. Ponadto nie zgadzam się z założeniem, że testerzy są ludźmi technicznymi. Nie zawsze tak jest, nie każda grupa, która wydaje oprogramowanie, może sobie pozwolić na pełny zespół ds. Kontroli jakości, więc rola może spoczywać na analitykach biznesowych, którzy mogą nie być techniczni.
wałek klonowy
1
poza punktem klonu_wału często widzę ostatnie wezwanie po tej lewej stronie do tego, kto jest w roli klienta, chyba że jest coś strasznego zidentyfikowanego. jest to ostatecznie ich wynik i najprawdopodobniej mają odpowiedni punkt widzenia na ryzyko, zakładając, że dostarczysz im dokładne informacje.
Bill
5

Decyzja o „uwolnieniu” lub „nie wydaniu” jest na koniec dnia decyzją biznesową, w której należy przeprowadzić rygorystyczną analizę ryzyka / nagrody.

Szaleństwem jest, aby jakakolwiek organizacja prosiła zespół testowy o przejęcie tej odpowiedzialności lub aby zespół testowy zgodził się na tę odpowiedzialność.

Rolą zespołu testowego jest dostarczenie analizy jakości oprogramowania, jego gotowości do wydania oraz wszelkich zagrożeń zidentyfikowanych jako wkład w decyzję biznesową o wydaniu lub nie wydaniu.

Jak zauważyli inni, _ ktoś (i uważam, że to osoba fizyczna) potrzebuje autorytetu, aby podjąć decyzję o „zwolnieniu” lub „nie zwolnieniu”. Ta sama osoba mogła przekazać tę decyzję na określonych warunkach (tj. Bez błędów P1 lub P2)

Jordania
źródło
3

Pracowałem z tą samą sytuacją, w której testerzy przekroczyli i wymyślili coraz bardziej kreatywne sposoby łamania systemu, które przy ocenie ryzyka są niezwykle mało prawdopodobne w produkcji.

Chociaż rozumiem i pochwalam zespół testowy za to, że nie chce wysłać niedoskonałej wersji, wymaga silnej własności produktu, aby zdefiniować „akceptowalne ryzyko”.

Z mojego doświadczenia wynika, że ​​zespołowi testowemu należy przyznać weto dotyczące wydania oprogramowania, ale to weto powinno zostać zastąpione przez właściciela produktu, ale dopiero po dyskusji z wiodącymi testerami.

Oprogramowanie nigdy nie będzie idealne, jeśli cierpisz na pełzanie testowe, nigdy nie dostaniesz niczego, dopóki nie pojawi się poważny problem z produkcją (który nie zostanie poprawnie przetestowany) i nie wybiegniesz.

Michael
źródło
1
To prawdziwy problem, ale nie jestem pewien, czy to koniecznie problem PO. Moja interpretacja jest taka, że ​​w jakiś sposób testerzy interpretują nowe wymagania, które nie zostały pierwotnie zdefiniowane.
wałek klonowy
2
moje doświadczenie z zespołami testującymi doprowadziło mnie do upadku na drugą stronę. Według mnie QA nie powinien oczekiwać, że będzie w stanie zablokować wdrożenie bez zgłaszania się do reszty zespołu lub zmuszania właściciela do zastąpienia zespołu.
Bill
1
To prawda, że ​​prawdopodobnie nie byłem wystarczająco wyraźny, te same problemy występują, gdy testerzy zgłaszają wady, i cytuję „na początku historii”, co prowadzi do tych samych problemów - nic nigdy nie zostaje wydane.
Michael
W moim przypadku jest to bardziej interpretacja @maple_shaft; nie tyle bycie przebiegłym w znajdowaniu sposobów na złamanie oprogramowania, jak zgłaszanie braku obsługi jawnie nieobsługiwanych przypadków.
Ernest Friedman-Hill
1
@ ErnestFriedman-Hill Wygląda na to, że opisujesz wymagania negatywne, a tych brakuje w dokumentach wymagań funkcjonalnych. Negatywne wymaganie jest wyraźnym stwierdzeniem o tym, czego system NIE zrobi, i może być tak samo akceptowalne jak zwykłe wymagania. Jeśli zostaną zadeklarowane, ich przypadki testowe w stosunku do wymagań ujemnych są nieważne.
maple_shaft