От архитектуры приложения до приемочных автоматических тестов, или тестирование нефункциональных требований by Oleksandr Reminnyi

Speaker Александр Реминный
Title - Название доклада
От архитектуры приложения до приемочных автоматических тестов, или тестирование нефункциональных требований
Title in English
From the application architecture to the automated acceptance tests, or testing of non-functional requirements
Annotation - Аннотация (1000 знаков с пробелами)

Ни для кого не секрет, что автоматическое тестирование является долгосрочным и затратным инвестированием. Соответственно, перед началом автоматизации всегда стоит вопрос, – какие тесты автоматизировать в первую очередь? А еще важнее – как построить автоматические тесты, которые действительно могут служить базовым набором для приема функционирующей системы?

 

В рамках архитектурной группы компании SoftServe была разработана методология создания набора приемочных системных тестов приложения, которая основывается на качественных атрибутах системы, то есть нефункциональных требованиях. У истоков методологии стоит техника определения архитектуры системы на основании тех же качественных атрибутов, разработанная сотрудниками Carnegie Mellon Software Engineering Institute. Этой методологией, а также примерами ее использования мне и хотелось бы поделиться. 

Annotation in English - Аннотация на английском (1000 symbols with spaces)

It's obvious that automated testing is a long term and costly investment. Accordingly, before the automation is started we need to answer the primary question - what tests are automated in the first place? And even more important question is - how to build primary acceptance test suite to validate the system under test?

 

SoftServe architectural group developed methodology for creating an acceptance test suite for application which is based on the quality attributes of the system (or the non-functional requirements). The methodology is based on architecture definition technique, developed by Carnegie Mellon Software Engineering Institute. I would like to share this methodology principles, as well as real use cases.

Detail description or Plan of the talk- Развернутые тезисы или план доклада

Carnegie Mellon Software Engineering Institute предложили метод определения системы на основании ее качественных атрибутов.

Так, заинтересованные лица со стороны заказчиков собираются в одном помещении с консультантами по определению архитектуры. Проводиться двухдневный семинар, на основании которого определяются основные качества системы, а также основные сценарии, соответствующие этим качествам. (Например, качество – «производительность». Сценарий – «Запрос за конкретными данными на сервер не должен превышать определенный порог времени»).

Соответственносценариираскладываютсяпотаблице (Artifact/Stimulus/Stimulus Source/Response/Response Measure/Environment). Эту таблицу очень просто переопределить в рамках языка спецификации тестов Gherkin и получить удобный для автоматизации формат.

Важно то, что система может уже существовать, и такая методика позволяет сделать «взгляд в прошлое» и вернуться к основным целям приложения перед ее тестированием, абстрагироваться от функционала.

 

Соответственно методологии было проведено несколько сессий, получены приоритетные сценарии. Методология получила высокую оценку со стороны клиентов. 

Type of Presentation - Тип доклада
  • Regular Talk - Секционный доклад (40 min)
Level of audience - Уровень аудитории
  • 3 (advanced)
Contact info - Контактная информация

skype - alexander.reminniy

email: alexander.reminniy@gmail.com

Public profile - Ссылка на публичный профиль
ua.linkedin.com/pub/oleksandr-reminnyi/21/b2/5b7
Subjects of the talk - Тематика доклада
  • Test automation
Last Updated 21 Jan 11:07