Проверки и Приемки

Проверка (verification) — это проверка того, что система соответствует какому-то описанию целевой системы (требованиям, архитектуре, неархитектурной части проекта).

Приёмка (validation) — это проверка того, что использующая система соответствует желаемому стейкхолдером её описанию, если в её составе работает целевая система.

Очень частая ошибка: забывают о необходимости валидации (приемке). В результате система удовлетворяет инженеров, которые эту систему сделали в соответствии со спецификациями, но не удовлетворяет стейкхолдеров: испытания должны проводиться не только для целевой системы (проверки), но и для использующей системы (приёмка!). Только после приёмки (то есть удостоверения в том, что использующая система работает как надо) системные инженеры могут считать, что их работа выполнена.

Основной тренд: это непрерывное автоматизированное разноуровневое тестирование, на всех этапах жизненного цикла, в том числе в ходе эксплуатации. Практики проверки и приёмки приходят сейчас главным образом из software engineering (как обычно), а потом медленно с лагом 10 лет принимаются системной инженерией. Software_testing - внизу страницы раздел Topics.

На V&V (проверки/приёмки/контроль/тестирование/испытания) приходится до половины всех затрат на разработку!

Как всегда, основной тренд в системной инженерии – это сдвиг всех проверок и приёмок влево на V-диаграмме (см. пост Donald Firesmith – «Four Types of Shift Left Testing»).

Ссылки

  • Классика жанра (классические определения и общее понимание предмета):
    • место проверки и приёмки в ходе воплощения системы (водопад);
    • проверка;
    • приёмка;
    • что делает инженер по испытаниям (hardware test engineer);
    • чему учат: пример программы курса (ещё);
    • пример материала (слайдов) для вузовского курса;
    • слайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов).
  • TDD, test driven development (разработка софта, вариант agile методологии разработки)

driven против based:

    • тестоориентированная разработка;
    • пример, как и в пользу чего отказываются от TDD (читать нужно так «TDD очень хорош, но это явно не панацея в тестировании»);
    • что ещё кроме TDD бывает в agile (а именно, developer TDD, developer regression testing, reviews/inspections, end of lifecycle testing, acceptance TDD, parallel independent testing, independent regression testing).
  • Model-based testing (и по сопричастности test automation): тут очень интересно, ибо приходится разбираться, как устроена предметная область – т.е. что такое испытания как таковые.
    • model-based testing;
    • пример слайдов занятия по model-based testing;
    • time partition testing;
    • обезьянки против роботов (на русском) (2) (3).
  • Test of Cyber-physical systems (control system engineering):
    • разница в Model in loop(MIL), Software in loop(SIL), Processor in loop(PIL), Hardware in loop(HIL);
    • hardware-in-the-loop;
    • примеры испытательных стендов (как «что-то-in-the-loop»);
    • коротенькие определения терминов в картинках.
  • Моделирование инженерных обоснований (в том числе assurance case)
    • много-много ссылок внутри.