Отправлено 6 апр. 2011 г., 12:04 пользователем Igor Khrol
[
обновлено 11 апр. 2011 г., 23:36
]
6 апреля 2011 состоялась вторая встреча участников Minsk Automated Testing Community. На этот раз мы собирались обсудить вполне конкретную тему, а именно "Кому писать автоматические тесты?" Не только собирались, но и вполне продуктивно обсудили.
Началось обсуждение с короткой презентации Игоря Хрола, в течение которой обсудили один из подходов к разделению труда при создании автоматических тестов. А именно:
- Инженеры по функциональному тестированию предоставляют требования к тому, какие действия нужно производить с UI.
- Инженеры по автоматизации тестирования разрабатывают фреймворк и набор бизнес-компонентов (методы, классы, функции), которые будут выполнять действия на UI.
- Функциональные тестировщики (инженеры по функциональному тестированию) разрабатывают тест-скрипты в исходном фреймворке и используя предоставленных API.
Данный подход позволяет достичь следующих целей (часть из них обозначена в презентации, а часть выявлена в ходе дальнейшего разговора): - Сократить время обучения автоматизаторов тестирования продукту и специфике его тестирования.
- Сократить врема обучения функциональных тестировщиков специфическим моментам в автоматизации тестирования.
- Позволить функциональным тестировщикам заниматься автоматизацией тестирования с минимальным риском того, что дело пойдёт не так из-за незнания подходов к автоматизации.
- Заставляет автоматизаторов говорить на одном языке (в рамках одной и той же терминологии) с функциональным тестированием и остальными участниками разработки продукта.
- Заставляет функциональное тестирование использовать автоматические тесты. Когда код написан своими руками, то функциональные тестировщики делают всё возможное, чтобы эта работа не пропала даром (в отличие от варианта, когда автоматизация тестирования предоставляется уже в готовом виде).
В ходе дальнейшего обсуждения недостатков данного подхода выявились следующие ограничения: - Для того, чтобы схема работала, нужна поддержка какого-либо уровня руководоства (PM, QA Manager) в том плане, чтобы ресурсы функционального тестирования были закреплены за автоматизацией и не выдёргивались, когда появляются горящие задачи по ручному тестированию. Лучший вариант - это когда на проекте есть долгосрочный план, в котором чётко обозначено, когда кто и чем занимается.
- Схема не работает вообще для проектов, где автоматизация тестирования аутсорсится (и только она, без ручного тестирования). Если же у вас на проекте и ручное тестирование, и автоматизация, то можно уже внедрять данную схему.
В качестве альтернативных схем для ответа на вопрос "Кто должен писать автоматические тесты?" были предложены следующие.
1. Функциональные тестировщики пишут автоматические тесты самостоятельно.
Будут некоторые проблемы с эффективностью из-за незнания (недостаточного опыта) в автоматизации.
2. Автотесты пишут автоматизаторы.
Есть проблемы с внедрением автотестов, а также с пониманием процессов тестирования продукта.
3. Разработчики пишут тесты самостоятельно под присмотром небольшого количества QA-инженеров, которые контролируют, чтобы функциональность была покрыта автоматическими тестами на требуемом уровне.
Требуются универсальные инженеры, которые могут эффективно как разрабатывать, так и тестированить (eBay себе может найти таких)
4. Нет понятия ручного тестирования в принципе и инженеры по тестированию отвечают за всё.
Требуются достаточно квалифицированные инженеры (Google и Microsoft могут себе это позволить)
В ходе обсуждения было оговорено, что в рамках обычных проектов Минской IT-сферы, где нельзя найти достаточное количество очень опытных и универсальных людей, подход имеет право на существование и на практике так или иначе применяется:
- У Дмитрия Тищенко (Itransition) используется для всех проектов по автоматизации, где автоматизация тестирования - не аутсорсинг. С небольшими, правда, оговорками по зонам ответственности: функциональное тестирование не только берёт на себя ответственность за написание непосредственных тест-скриптов, но и за написание API (методов, функций) в рамках разработанного фреймворка от команды по автоматизации тестирования.
- У Владимира Кривенко (Logic Software) схема похожая, но еще не до конца внедрённая (хотя делаются определённые шаги, чтобы она заработала).
- У Игоря Хрол и Сергея Талалаева (EPAM Systems) данная схема внедрена на проекте частично, но там где внедрена очень хорошо себя показывает.
- Георгий Максименко (Exadel) обозначил, что у него данного подхода нет, но вполне может быть внедрён и будет полезен.
- Наталья Савастюк (QA Club Minsk) высказалась, что подход хороший, но его нужно донести до соответствующих QA-менеджеров, которые имеют достаточно "власти" для его внедрения в массы.
Слегка обсудили техническую реализацию. Было предложены следующие варианты: - Создание набора классов.
- Достоинство: использование autocomplete в IDE для облегчения поиска нужной функции.
- Недостаток: нужно программировать.
- Behavior Driven Development (к сожалению не нашлось успешных проектов, где этот подход работает).
- Достоинство: не нужно писать код, а скрипты находятся в связке с тест-кейсами.
- Недостаток: есть вопросы, как управлять большим словарём.
По каждому из технических подходов можно устраивать отдельную встречу и детально обсуждать, поэтому технические темы были просто обозначены в качестве смежных с нашей. Местами разговор так или иначе сводился к обсуждению некоторых отвлечённых моментов, но мы старались возвращаться обратно к теме дискуссии и предмет обсуждения был раскрыт достаточно разносторонне. Так или иначе все высказались и были выслушаны. :) Напоследок парочка общих фотографий с нашими уставшими, но довольными лицами: Верхний ряд слева направо: Дмитрий Тищенко, Георгий Макименко, Надежда Кныш, Наталья Савастюк, Елена Деменчёнок, Татьяна Салцевич и Анна Сидорова. Сидят: Сергей Талалаев и Владимир Кривенко. Все те же лица, но вместо Георгия Максименко - Игорь Хрол.
Спасибо за предоставленное помещение Инкубатору БГУИР и Дмитрию Тищенко за помощь в поиске помещения. |
|
