Чи є створення ще однієї повторюваної системи забезпечення якості (QA) ще однією поганою практикою?

На роботі у нас досить складна система. Давайте назвемо цю систему, System_A. Наша команда з QA створила іншу систему, викликайте цю систему, System_B, щоб перевірити System_A.

Спосіб використання System_B полягає в наступному. Ми генеруємо входи (використовуючи сам System_B), IN, обробляємо такі входи назад через System_B і генеруємо виходи, O_B. Отже, процес такий:

System_B(IN) -> O_B.

Потім робимо те ж саме для System_A, щоб генерувати власні результати, O_A:

System_A(IN) -> O_A.

У будь-який час передбачається, що O_B - очікуваний вихід, а O_A - спостережуваний / фактичний вихід. Мається на увазі, що O_B є "золотим" джерелом (правда). Однак ми зіткнулися з поєднанням проблем.

• O_A помиляється, O_B має рацію
• O_A - це правильно, O_B - правильно
• O_A помиляється, O_B - неправильно
• O_A вірно, O_B помиляється

Хто визначає, що правильно, якщо O_B вважається завжди правильним (або що очікується)? Що ж, виявляється, що O_B іноді (або часто) помиляється з оглядом та аналізом людини. За допомогою цього процесу все пройде QA, і справжні користувачі будуть скаржитися, і ми повернемося до того, що O_B все-таки помилився.

Питання таке: чи погана практика створення "тестової системи" для тестування реальної системи?

• А як щодо слизького схилу? Тоді чи не можемо ми стверджувати, що потрібна ще одна система для тестування "тестової системи"?
• Вартість, безумовно, непомірна, оскільки розробникам зараз потрібно вивчити принаймні 2 бази коду, можливо, складність System_B більша, ніж System_A. Як ми могли б оцінити, наскільки добре чи погано мати System_B навколо організації?
• Однією з оригінальних «переконливих» причин для створення System_B було «автоматизація» тестування. Зараз ми дуже пишаємося тим, що ми повністю автоматизовані (адже System_B генерує вхід для завантаження процесу використання себе для отримання результатів). Але я думаю, що ми заподіяли більше шкоди і ввели більше складності, не підлягає оцінці. Чи слід завдання QA бути повністю автоматизованим? Чи достатньо цієї причини, щоб виправдати створення паралельної системи?
• Моє справжнє занепокоєння в цьому, хоча ми всі знаємо, що System_B помиляється (досить часто). Якщо System_B настільки добре обробляє вхід, а його вихід є золотим джерелом, чому б не замінити System_A на System_B? На це ніхто на роботі не в змозі надати задовільну відповідь.

Будь-які вказівки з цього питання високо оцінені.

• O_A помиляється, O_B має рацію

Виправити A

• O_A вірно, O_B помиляється

Виправити В

• O_A - це правильно, O_B - правильно

Сподіваємось, вони теж погоджуються.

• O_A помиляється, O_B - неправильно

Сподіваємось, вони не згодні, тож ви будете знати щось робити з цим.

Жоден процес не вловлює все. Звичайно, ви подвоїли свій код, але подумайте про нього як про 2 в O (2n). Автоматизований контроль якості аж до інтеграційних тестів - чудова річ. Тестування вручну - це тягар інновацій. Особливо щодо наскрізних змін, які потребують повного випробування. Крім того, оскільки у вас будуть різні програмісти, які реалізують одне і те ж, ви можете мати їм гонку.

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

Питання таке: чи погана практика створення "тестової системи" для тестування реальної системи?

Якщо це так, то все тестування погано.

• А як щодо слизького схилу? Тоді чи не можемо ми стверджувати, що потрібна ще одна система для тестування "тестової системи"?

Так, ми можемо це аргументувати. Ми будемо називати цю 3-ю систему, system_A. : P

• Вартість, безумовно, непомірна, оскільки розробникам зараз потрібно вивчити принаймні 2 бази коду, можливо, складність System_B більша, ніж System_A. Як ми могли б оцінити, наскільки добре чи погано мати System_B навколо організації?

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

• Однією з оригінальних «переконливих» причин для створення System_B було «автоматизація» тестування. Зараз ми дуже пишаємося тим, що ми повністю автоматизовані (адже System_B генерує вхід для завантаження процесу використання себе для отримання результатів). Але я думаю, що ми заподіяли більше шкоди і ввели більше складності, не підлягає оцінці. Чи слід завдання QA бути повністю автоматизованим? Чи достатньо цієї причини, щоб виправдати створення паралельної системи?

Складність System_B чудово ізольована від System_A. Додавати функції до System_A не важче, оскільки System_B існує. Це по факту простіше, оскільки System_B надає їм впевненості в тому, щоб швидко пройти.

• Моє справжнє занепокоєння в цьому, хоча ми всі знаємо, що System_B помиляється (досить часто). Якщо System_B настільки добре обробляє вхід, а його вихід є золотим джерелом, чому б не замінити System_A на System_B? На це ніхто на роботі не в змозі надати задовільну відповідь.

Це друкарня? System_B досить часто помиляється, тому це золотий стандарт, який ви хочете використовувати для заміни System_A?

Я припускаю, що ви мали на увазі, що System_A часто помиляється. Не важливо, хто з них помиляється найчастіше. Той, хто помиляється, той, кому потрібна робота. Ці системи не вирішують правильно і неправильно, як вважають розробники. Те, що робиться тестуванням, викликає незгоду, яка означає, що щось не так. Розробники з'ясовують, що це таке. Пам'ятайте, тут не виробляється золотий стандарт. Є лише згода або незгода. Незгода вимагає роботи. Частина цієї роботи - з'ясування куди.

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

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

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

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

Кожен раз, коли ви тестуєте систему, ви повинні знати, який очікуваний результат.

Очевидно, що проблема, пов'язана з тим, що система генерує цей очікуваний результат, - "як я тестую цю систему"

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

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