Двойной QA talk прошел в Воронеже и Херсоне

Прямая трансляция между Воронежем и Херсоном объединила желающих получить практические советы от специалистов в бизнес-анализе и автоматизированном тестировании.

Игорь Гулида, Business Analyst из Херсона, рассуждал об ошибках, которые допускаются при разработке ПО, и том, как их можно предотвратить. Прежде всего, Игорь вместе со слушателями попытался разобраться с понятием «ошибка». Для большинства оказалось, что ошибка — понятие, равносильное «багу». Но докладчику удалось переубедить слушателей, что это более обширное понятие: и баг, и отсутствие фичи, и частичное решение или решение, которое не приносит пользы и т. п. Развеять все сомнения о важности предупреждения ошибок при разработке Игорю удалось простой статистикой: оказалось, что исправление шибок занимают 75% стоимости реворка проекта, проекты в среднем превышают график на 120% и изначальную стоимость на — 150.

Игорь очертил путь предотвращения ошибок. Во-первых, нужно понять, где кроется ошибка, и не забывать, что в половине случаев она в требованиях. Во-вторых, важно хорошо разбираться в требованиях, анализировать их изначально и уточнять все невыясненные моменты заранее, причем, как правило, это возлагается на QA. В-третьих, нужна правильно подбирать и использовать инструменты для понимания требований и заказчика, чтобы предложить ему правильное решение.

По мнению Игоря, наиболее простые инструменты для подготовки материалов для демонстрации заказчику — диаграмма связей Mind Map, карта систем Feature List и карта процессов Process Map.

В конце доклада Игорь озвучил основные правила коммуникации с заказчиком, полагаясь на свой практический опыт: нужно всегда уважать время заказчика, заранее договариваться о времени и продолжительности, внимательно слушать, не перебивать и только после предлагать свои вариант и всегда знать, чего он хочет и способствовать достижению этого.

28198799542_977127f50a_k

Евгения Гатауллина, QA Automation из Воронежа, рассказывала о главных принципах BDD-подхода в автоматизированном тестировании. Она сразу подчеркнула, что behavior driven development — расширение подхода test driven development, потому что главная его задача – не только проверить код на отсутствие ошибок, но и узнать, как будет вести себя приложение с точки зрения конечного пользователя.

Евгения описала структуру BDD-проекта, главной частью которой выступает коллекция различных сценариев story, сами сценарии и реализация: инструкции и имплементация на уровне приложения. На практических примерах Евгения показала, как могут выглядеть все эти структурные элементы в BDD-проекте и как их следует описывать. Затем подвела итог и озвучила основные достоинства использования BDD-подхода: тестирование с позиции пользователя, разделение написания сценариев и реализации между тестировщиками и программистами. Среди недостатков выделила главный — работу с текстом.

Особое внимание Евгения уделила вопросу «где и кому стоит использовать BDD-тесты?». Оказалось, что их могут использовать Product Owner, QA, бизнес-аналитики для отслеживания выполнения инструкций и генерирования отчетов по результатам выполнения тестов.

Во второй части Евгения рассказала об использовании инструментов Cucumber, который имплементирован под использование многих языков, и JBehave, который использует только Java. Она привела сравнительную таблицу, в которой наглядно показала отличия всех элементов BDD-тестов в Cucumber и JBehave, и привела примеры описания сценариев на JBehave.

28019210390_7fc7fe3aa4_k

Все фотографии: https://www.flickr.com/photos/outsourcing/sets/72157668180749723/with/27685128423/