Чи повинні тестери затверджувати випуски чи просто звітувати про тести?

Чи має сенс надавати авторизацію тестувальникам? Чи повинна тестова група

1. Просто тестуйте функції, проблеми тощо, і просто повідомте про пропуск / відмову, залишаючи це іншим діяти за цими результатами, або
2. Чи мають повноваження проводити самі випуски на основі цих результатів?

Іншими словами, чи потрібно вимагати від тестувальників фактично виходити з релізів? Команда тестування, з якою я працюю, вважає, що вони це роблять, і у нас виникає проблема з-за "повзучості тестування" - відмова в затвердженні випусків іноді заснована на питаннях, явно не вирішених відповідним релізом.

У більшості місць, в яких я працював, QA мають певний крок виходу, але вони не мають остаточного повноваження щодо того, продовжуватиметься чи ні. Їхній вихід означає, що вони завершили тестування, очікуване планом випуску, а не те, що випуск є бездоганним.

В кінцевому рахунку QA! = Бізнес і бізнес повинні вирішити, чи вони в порядку з розгортанням коду в поточному стані, або вигода переважає вниз або інше. Це часто роблять клієнти або зацікавлені сторони безпосередньо перед розгортанням і часто називаються Прийняттям користувача.

Якщо ваш QA також є вашою групою з прийому користувачів, то є потенціал, що вони мають повноваження визначати вашого кандидата на випуск як неприйнятного, але якщо ви отримуєте це через проблеми, які виходять за рамки помилки / ітерації / спринту / зміни запит / що б ви не витратили на свій час, тоді керівнику проекту або зацікавленим сторонам у бізнесі потрібно приїхати на зустріч Ісуса з командою QA.

Добре повідомляти про наявні дефекти або непередбачувані результати нових вимог, але якщо це не виходить за рамки та не є катастрофічним, це правило неприйнятно вважати це блокуючим питанням. Власнику продукту надається пріоритет, як і все інше.

Комусь потрібен цей авторитет . Будь то тестер, команда тестувальників, керівник команди тестувальників чи керівник організації з розвитку дещо не має значення. Або, можливо, точніше, це залежить від організації.

Зрештою, вибір випуску програмного забезпечення - це бізнес-функція. Бізнес повинен вирішити, чи відповідає якість. Можливо, директор із забезпечення якості повинен прийняти це рішення або подати це рішення у відповідний підрозділ бізнесу. Все залежить від розміру компанії, відносної важливості якості тощо.

Все, що говорити, інформація, яка використовується для прийняття рішення, починається з тестера . Незалежно від того, мають вони право зупинити випуск чи ні, вони повинні відчувати відповідальність повідомляти осіб, які приймають рішення, коли бачать те, що, на їхню думку, може спричинити затримку випуску.

Надання повноважень щодо виходу (тобто права вето) на випуски для тестувальників має стільки ж сенсу, як і надання цього права розробникам: взагалі немає.

Тестери та розробники - це перш за все технічні люди, тому вони, швидше за все, приймають свої рішення переважно технічними підставами. Але проблеми, які необхідно зважувати під час випуску, стосуються як технічних, так і ділових проблем. Очевидно, що замовник не буде задоволений, якщо ви доставите з помилкою товар, але замовник буде однаково незадоволений, якщо ви будете продовжувати відкладати випуск, оскільки все ще є відкриті проблеми.

Комусь потрібно знайти правильний баланс між хорошим продуктом та дотриманням графіка, який був обіцяний замовнику. Для цього вам не слід брати участь у проекті в суто технічній ролі, а скоріше в більш орієнтованій на бізнес / менеджмент, як менеджер проекту чи власник продукту, і брати свій внесок від тестерів та розробників.

Рішення про "звільнення" або "не звільняти" є в кінці дня бізнес-рішенням, коли потрібно проводити суворий аналіз ризику / винагороди.

Будь-яка організація божевільна просити тестувальну групу взяти на себе цю відповідальність, або тестова група погодитися на цю відповідальність.

Роль тестової групи полягає у наданні аналізу якості програмного забезпечення, його готовності до випуску та будь-яких ризиків, визначених як внесок у бізнес-рішення щодо випуску чи не випуску.

Як зазначають інші, _ комусь _ (і я вважаю, що це людина) потрібні повноваження, щоб прийняти рішення про "звільнення" або "не звільняти". Ця ж особа може делегувати це рішення за конкретних умов (тобто відсутні помилки P1 або P2)

Я працював з тією ж ситуацією, що тестери долають і вигадують все більш креативні способи зламати систему, яка при оцінці ризику неймовірно навряд чи відбудеться у виробництві.

Хоча я розумію і вітаю тестову групу за те, що вона не бажає надсилати недосконалий реліз, вона вимагає сильної власності на продукт, щоб визначити, що таке "прийнятний ризик".

На мій досвід, тестовій команді слід надати вето на випуск програмного забезпечення, але це вето має бути перезаписане власником продукту, але лише після обговорення з провідними тестерами.

Програмне забезпечення ніколи не буде ідеальним, якщо ви страждаєте від тестового повзучості, то ви ніколи не отримаєте нічого, поки не з’явиться головна проблема виробництва (яка не буде перевірена правильно) і не вискочить.