Чи добре, що тестери змагаються, щоб побачити, хто відкриває більше помилок?

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

Це добре для проекту? Якщо ні, то як я (як розробник програмного забезпечення) спробувати змінити мислення та позиції команди тестувальників?

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

OBS: Цей конкурс не є практикою компанії! Це змагання між лише організованими ними тестувальниками та без будь-яких призів.

Я не думаю, що це добре, що вони роблять конкурс, щоб знайти найбільше помилок. Хоча це правда, що їхня робота - знайти помилок, їхня робота - це не «знайти найбільше помилок». Їх мета - не знайти найбільш, їх мета - допомогти покращити якість програмного забезпечення. Нагорода за те, що вони знайшли більше помилок - це приблизно те саме, що винагородити програміста за написання більшості рядків коду, а не код найвищої якості.

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

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

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

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

Я збираюся трохи не погодитися з іншими відповідями. "Пошук помилок" для тестера трохи схожий на "написання коду" для розробника. Сира кількість безглузда. Завдання тестера - знайти якомога більше помилок, які існують, а не знайти найбільше помилок. Якщо тестер А знайде 5 з 10 помилок у високоякісному компоненті, а тестер В виявить 58 із 263 помилок у компоненті низької якості, то тестер А - кращий тестер.

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

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

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

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

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

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

Немає нічого поганого в тому, щоб зробити гру з пошуку помилок. Ви знайшли спосіб мотивувати людей. Це добре. Також було виявлено невдачу в повідомленні пріоритетів. Закінчити конкурс було б марно. Вам потрібно скорегувати пріоритети.

Кілька реальних ігор мають просту систему балів. Чому варто полювати на клопа?

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

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

Пошук помилок - їхня робота. Поки вони не роблять речі менш ефективними (наприклад, відкриваючи помилку для ech з 10 помилок замість одного, щоб охопити декілька з них), це спонукає їх робити саме те, що вони повинні робити, так Я не бачу багато недоліків.

Це розширення на @ CandiedOrange в відповідь .

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

Кожного дня, коли повідомлялося про принаймні одну істотну помилку, залишайте маркер "Жук дня" на столі тестера. Раз на тиждень проводьте церемонію з процесією розробників, які доставлять більший і кращий жетон або трофей "Помилка тижня". Зробіть доставку трофеїв "Помилка місяця" ще більш драматичною, можливо, з тортом. Кожен жетон або трофей повинен супроводжуватися цитатою, в якій сказано, чому розробники вважали, що помилка виявлена ​​під час тестування. Примірники цитат повинні бути розміщені десь, де тестувальники можуть їх прочитати.

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

Просто ігноруйте неважливі звіти про помилки. Оскільки це було б дуже неофіційно та неофіційно, його можна було будь-коли закрити чи змінити.

Це добре для проекту?

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

Якщо ні, то як я (як розробник програмного забезпечення) спробувати змінити мислення та позиції команди тестувальників?

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

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

повідомляти про помилки про покращення екрану, зручність використання або дурні помилки.

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

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