Життєздатність команди розвитку без * виділеної * ролі тестера [закрито]

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

Поки що я визначаю худорляву команду як наступне:

• Малий;
• Самоорганізація;
• Усі члени повинні мати на увазі QA;
• Члени повинні бути здатні виконувати декілька ролей

Останній пункт - де я трохи хвилююся, тому що, як іде мантра ...

Розробники роблять погані тестери.

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

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

Моя модель вимагає:

• Невеликий програмний дім із 2+ проектами
• Спритний (ітеративний) підхід до розробки та реалізації
• 1 команда на проект
• Усі члени команди будуть розробниками програмного забезпечення
  • Їх опис роботи буде чітко розвитку , забезпечення якості , тестування та доставки в якості обов'язків

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

• Кожен член команди буде чергувати між роллю розробника та роллю тестера
• Якщо член команди - розробник проекту A , він буде тестувачем проекту B
  • Учасники працюватимуть лише над одним проектом за один раз, тому, як очікується, вони будуть виконувати функції як розробник, так і тестер.
• Роль Цикл складається з 3 -х ітерацій як Dev і 2 ітерації в якості тестера (знову ж , на два різних проектах)
• Команди проектів мали б 3 розробників та 2 тестери за весь час.
• Рольові цикли учасників повинні бути поза фазою за допомогою 1 ітерації.
  • Це мінімізує крутості змін команди. Для кожної ітерації 2 Devs та 1 Tester залишаться такими ж, як і попередні ітерації.

З огляду на сказане, я бачу такі плюси і мінуси:

Плюси

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

Мінуси

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

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

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

Примітка: заради стислості я зосередився лише на ролях Dev і Tester. Я розширю на інші ролі, якщо потрібно.

Я не згоден з цим

Розробники роблять погані тестери

Більшість команд, над якими я працював у своїй кар’єрі, не мали підтримки QA. Сюди входить кілька великих глобальних корпорацій, що включають такі продукти, як їх глобальна система входу та реєстрації. В іншому випадку я мав 30% доходу компанії за допомогою коробки на своєму столі. (Ці практики не рекомендуються BTW;)) Ці компанії покладалися на інженерів, щоб переконатися, що код працює правильно. І ми, орієнтуючись на деталі, трохи нав'язливі і пишаємось своєю роботою, намагалися б переконатися, що наше програмне забезпечення працює правильно.

Також як розробник я роблю набагато більше тестування, ніж Тестери. Я регулярно перевіряю свій код на 90%, або на 100%, якщо я не працюю з Java.

Мені подобається працювати з Тестерами, тому що вони приходять до цього з іншого погляду, і ловлять речі, про які я не думав. Але я дійсно не розраховую на те, щоб вони забезпечили понад 30-50% тестового покриття, в той час як я вважаю себе відповідальним за 100%. (BTW Це не гріх на них - вони, як правило, розкидані між проектами.)

Замість того, щоб запитувати інженерів на інтерв'ю, чи хочуть вони робити QA, запитайте: якщо помилка з'являється у виробництві, хто відповідальний? Якщо я ввожу помилку, і клієнт відчуває це, я почуваюся погано і беру на себе відповідальність. Я не звинувачую хлопців із якості. ІМХО Це такий інженер, якого ви хочете найняти (і працювати з ним)

Мій метод забезпечення якості - це а) суперагресивне тестування одиниць (хоча я не можу змусити себе зробити повний тестовий розвиток); б) сильний процес перегляду коду справді допомагає; в) інтегрувати нетерпимість та нетерпіння з недоліки в культурі команди.

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

Але більшість команд, над якими я працював, особливо для невеликих компаній, не мали формальної складової якості.

Я погоджуюся з відповіддю @Rob Y і хочу додати декілька пунктів:

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

• Dev роблять поганих тестерів ... а тестери роблять поганих тестерів. QA важкий. Насправді це дуже важко. Вашою проблемою можуть бути не люди та ролі. Ваша проблема може полягати в тому, що ваше програмне забезпечення вискочило. Знову ж таки, по-спритному, ваша команда повинна перевірити перед виробництвом (чи присвятили вони якість якості чи ні).

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

• Провокація: Хто каже, що якісні якості краще, ніж розробники в QA-ing? Люди щось кажуть, але ... [потрібне цитування]. Необхідний "хакерський" менталітет QA - це менталітет розробників. Фактично всі хакери є або були розробниками, а не QA ...

• Провокація 2: 99% QA роботи можуть бути (і, смію сказати, повинні бути ) автоматизовані за допомогою сценаріїв. Хороша команда зробить це, і для цього правильно вам потрібні ... розробники.

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

Ключове - зробити це частиною культури колективу та частиною кожного проекту. Ми склали плани тестів (лише короткі списки тестів, які ми мали намір написати для проекту), а інші розробники переглянули та запропонували випадки та сценарії, які ми пропустили.

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

По-перше, застереження - я працював професійно як QA інженер, так і програмний інженер.

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

Усе можливо.

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

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

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

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

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

Можливо, ти в чомусь дивовижний, з яким я ще не стикався - але я сумніваюся в цьому.

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

1. Будьте дуже вперед щодо подвійних ролей кандидатів. Це не для всіх з багатьох причин. Якщо у вас занадто багато людей, яким це не подобається, у вас буде невдача і оборот.
2. Складіть план, де можна оцінити найкращий спосіб включити це до команди. Хоча мені подобається зосереджуватися на одному завданні / проекті за один раз, я не впевнений, що хотів би не програмувати протягом дуже тривалого періоду часу. Можливо тестування - це приємний відпочинок далеко від програмування. Не те, що простіше, просто використовуючи для зміни деякі різні клітини мозку. Будьте готові спробувати це по-різному, перш ніж вирішити, що найкраще.

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

Цей план не дозволяє командам достатньо самоорганізовуватися. Одна стратегія, ймовірно, не підходить всім командам та всім проектам.