Експертна оцінка тестів так само, як і кодові огляди

Хтось практикує процес "перегляду коду" для функціональних тестів? Чи вважаєте Ви це корисним? У тому випадку, коли мій нинішній роботодавець практикує SCRUM, ми включаємо функціональне тестування як частину наших матеріалів "must have done" у будь-якому спринті.

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

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

Друга приємна річ у перегляді коду - це він дає вам інший погляд на фактичну функціональність та на 100% впевненість у тому, що він відповідає тому, що хотів клієнт / клієнт. Було кілька разів, коли хтось перебирав код і функціональність, куди ця людина пішла ... "Почекай, це не так ...", і виявилося, що особа, що реалізує код, просто щось неправильно зрозуміла.

Добре небо, так (я намагаюся не використовувати експлікати на SO; p). Експертна перевірка ваших функціональних тестів - це, в основному, рецензування ваших вимог та аналізу, це надзвичайно важливо, і якщо ви використовуєте мову BDD, як огірок, ви можете також залучати непрограмістів!

Це дивовижно, коли наші кінцеві користувачі помічають проблеми з нашими функціональними тестами, і це змушує їх відчувати себе частиною процесу розробки "Я також можу читати код !!"

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

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

Огляд того, що тести є правильними, є одним із аспектів, що вони є достатньо повними та точними / репрезентативними також дуже важливими.

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

Ви можете робити парні перевірки!

Парні перевірки:

Огляд документів, активно та неформально, як частина циклу створення та створення документів.

Причини, чому це добре працює з тестуванням, полягають у тому, що:

1. Ви можете часто перевіряти вимоги або документи з кількома очима.
2. Ви можете залучити більше, ніж просто розробників: Спробуйте BA з Test Lead, BA з PM, BA з Dev.
3. Ви можете встановити повторне виліковування зустрічей як частину процесу Agile - Не забудьте серйозно поставитися до цього з твердими зобов'язаннями членів команди.
4. Ви можете використовувати ці парні перевірки як частину вправ з розбудови звітності та спілкування зі своїми зацікавленими сторонами. Початок розмови!

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

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