Чи правильно виправляти помилки, не додаючи нових функцій при випуску програмного забезпечення для тестування системи?

Це питання для досвідчених тестувальників або тестових відвідин. Це сценарій програмного проекту:

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

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

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

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

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

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

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

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

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

Регулярна розробка триває для декількох версій програмного забезпечення. Наприклад, скажімо, остання версія стабільного випуску - 2.0. Усі ризикові функції будуть додані до відділення 3.0. Лише виправлення помилок переходять у відділення 2.0. Тестування спеціальною командою з контролю якості проводиться лише на стабільних галузях. Звітування клієнтів, звичайно, робиться в іншій галузі, що базується на 2.0. Довгі функції, такі як розробка наступної ген-платформи, будуть виконані в 4.0, навіть не 3.0.

Все це добре виглядає на папері. Але якщо клієнт хоче певної функції, його потрібно додати до відділення 2.0, оскільки 3.0 недостатньо стабільний, щоб бути доступним для клієнтів. Це означає, що команді QA доведеться повторно запустити весь набір регресії.

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

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

Сказавши це, тестерам зрозуміло (не обов'язково виправдано) хотіти перевірити виправлення "Ceteris paribus" (усі "інші" речі рівні).

Можуть бути деякі інші проблеми щодо способу випуску та очікування кінцевих користувачів. Наприклад, можливо, вам доведеться випустити лише після однієї ітерації виправлень помилок + тестування та ще однієї нової функції + тестування, оскільки користувачі ТОЛЬКО хочуть перевстановити або оновити, коли з’явилися нові функції. Деякі можуть вимагати виправлення як найвищий пріоритет якнайшвидшого перегляду.

Ви можете вирішити цю (загальну) проблему, об'єднавши обидві команди.

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

Я пропоную вам прочитати цей чудовий пост у блозі від Генріка Книберга, який пояснює Кабана . Ви знайдете багато ідей у ​​процесі Scrum (безкоштовна книга також Генріка Книберга ).

Він також написав чудову статтю Kanban VS Scrum у своєму блозі.

Насолоджуйтесь.

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

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

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

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

"Чи можете ви погодитися, якщо це загальний принцип тестування.

Yes

Чи справджується стурбованість групи тестів

Yes

Ви стикалися з цим на практиці у своєму проекті ".

Yes

:

and Yes Merging is the downside of it 

Ви не запитували, хто це відповідальність, але це відповідальність менеджера конфігурації. Ця стратегія потоку повинна бути в його CMP. Інакше звільнить його / її. Я думаю, що відповідь від Pierre 303 також дуже хороший, але, звичайно, там, де це можливо, технічно (наприклад, продумати випуск Siebel ...) та організаційно.

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

Тут немає правильної відповіді, але слід врахувати кілька речей:

• Чи можуть ці випуски помилок (без нової функціональності) коли-небудь надходити до користувачів? Якщо так, то так, це повинно бути розгалуженим і перевіреним, і всі повинні сприймати це як накладні витрати.

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

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

• Чи є кращий спосіб використання управління версіями тут? Щось на зразок Mercurial (див. Http://hginit.com/ - прочитайте, це добре) або інша розподілена система управління версіями розгалужується та зливається по-іншому, і може допомогти вам подолати проблему. Дійсно, погляньте на це, бо я думаю, що це може бути відповіддю вашої проблеми.

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

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

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

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

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

Завжди намагайтеся виправляти помилки, перш ніж додавати нові функції!

Де я працюю, ми вирішуємо цей сценарій, коли кожен задуманий випуск у виробництво має свою галузь. Наприклад, припустимо, на секунду відбудеться реліз наприкінці червня та ще один - в кінці липня. Червневий випуск отримає власну філію, і всі функції будуть додані туди і відправлені до QA. З цього моменту ми б почали працювати над звільненням липня та виходити з відділення червня. Коли QA виявляє помилки, ми виправляємо їх у відділенні червня, і як тільки виправлення висуваються на QA, вони об'єднуються у відділення випуску липня. Це додає трохи накладних витрат для обробки цих злиттів, але зазвичай злиття є досить безболісними. Час від часу великий біль у тому, що ти знаєш, але це виникає лише тоді, коли оптові зміни вносяться, і вони не повинні відбуватися під час циклу якості (але вони трапляються, більше, ніж мені подобається визнати). Але з хорошим набором тестів (одиниця та інтеграція) та охопленням кодом та всіма іншими модницями TDD, ризики трохи зменшуються. Щоб вирішити проблему, ми зазвичай маємо одну особу для обробки об'єднань для кожного проекту.