Розробка чи тестування блоку тестування?

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

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

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

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

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

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

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

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

Це означає, що обов'язки повинні бути такими:

• Розробники пишуть автоматизовані тести
• Розробники запускають індивідуальні автоматизовані тести за потребою в рамках робочого процесу їх розробки
• QA виконує всі автоматизовані тести як один з перших етапів тестування

Якщо у вас є сервер збирання, то завдання QA (щодо автоматизованих тестів) зводиться до того, щоб "відкрити звіт сервера збірки та перевірити, чи все в зеленому".

Я думаю, що для вас найважливішим було б з’ясувати, навіщо їй потрібен цей звіт.

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

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

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

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

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

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

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

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

Я не бачу, що це має велике значення.

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

Якщо ви надаєте їх на QA / тестування, а вони не роблять належних тестів ... такий же результат, як якщо б ви їх не надали.

Однак якщо ви надасте їх, вони також можуть порівняти їх із специфікаціями та / або запропонувати, які тести можуть бути помилковими, або потребувати змін, оскільки вони виявили помилку.

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

Devs допускають помилки, QA робить помилки, в ідеалі вони не помиляються на одному предметі ... і якщо вони роблять ... це потенційно аналітик, який кинув м'яч, написавши незрозумілу специфікацію.

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

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

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

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

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

Подивіться на такий інструмент, як Sonar, який допоможе вам - він повідомить про рівень покриття коду та результати тестування вашого блоку.

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

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

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

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

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

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

Реальна роль , що традиційно називається відділ «Testing», насправді продуктивність праці розробників; тобто автоматизація, щоб організація дозволила економічно досягти необхідного рівня жорсткості.