Эта серия блогов посвящена «гордиеву узлу» современной автоматизации тестирования на основе ключевых слов (2.0) в целом и возможному (и особенно в практических проектах удивительно эффективному) решению этой сложной проблемы.

Но что это за «Гордиев узел»? Какие проблемы с этим связаны?

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

Общий вопрос заключается в том, как в этом «гордиевом узле» различные интересы и способности могут быть наилучшим образом объединены в рамках одного подхода к тестированию, который выполним для всех вовлеченных сторон.

Очевидно, что ответ не может дать один-единственный «чудо-инструмент». Однако при правильном использовании хорошее управление тестированием и полезный инструмент автоматизации тестирования могут значительно облегчить работу по тестированию. Таким образом, может быть создана элегантная беспроигрышная ситуация, которая раньше казалась невероятной.

Таким образом, цель этой серии блогов состоит в том, чтобы уделить особое внимание testOFFICE, поскольку он может дать очень простой ответ на эту очень сложную проблему благодаря своему революционному TCDL-подходу. Однако цель этого блога состоит не только в том, чтобы дать представление об этом, безусловно, удивительном инструменте, но и в том, чтобы дать читателям полезные стимулы для решения проблем и ежедневных проблем, которые возникают регулярно. Проблемы, которые невозможно решить с помощью одного инструмента.

Конечно, мы обсуждаем различные подходы и парадигмы в тестировании программного обеспечения; testOFFICE как таковой является особенно хорошей отправной точкой, поскольку:

  • В первую очередь авторы этого блога являются экспертами, которые знают этот инструмент наизнанку и поэтому проводят хорошо информированные сравнения тестового офиса с другими подходами на рынке, такими как Selenium или UFT.
  • Во-вторых, по крайней мере, насколько нам известно, существует очень мало подходов, способных интегрировать инструменты и (гибкую) философию таким четко определенным образом, как testOFFICE.
  • Наконец, особенно использование testOFFICE в конкретных проектах программного обеспечения доказало, что инструмент и философия прекрасно работают вместе. Участники нашего проекта расскажут об этом практическом опыте.

Итак, начнем с…

Автоматизация тестирования — почему и как

Иногда я встаю очень рано ночью. Однажды ночью, около 3 часов, после того, как я проснулся и подумал, что было бы неплохо послушать аудиокнигу, чтобы, возможно, снова заснуть, я обнаружил ошибку. На Спотифай. Не просто хромой, где некоторые строки плохо отображаются на экране, а самый настоящий мажор. Больше нельзя было проигрывать аудиокниги, не переходя в режим воспроизведения в случайном порядке. И поверьте мне, прослушивание аудиокниги в случайном порядке — одна из самых раздражающих вещей, которые могут случиться на медиаплеере.

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

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

В автоматизации тестирования как таковой нет ничего нового. Один из первых инструментов для автоматизации тестирования, Rational Visual Test, был выпущен в 1992 году, а первые модульные тесты с помощью Small Talk даже позволили Нилу Армстронгу сделать первые шаги человека на Луне 21 июля 1969 года. Итак, , мы прошли долгий путь в тестировании программного обеспечения, когда дело доходит до автоматизации тестирования.

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

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

Я видел различные подходы в проектах: некоторые из этих проектов используют BDD с Gherkin и Cucumber/SpecFlow, и здесь эти проекты действительно стараются использовать всю мощь подхода трех амиго, когда владелец продукта пишет требования на Gherkin, инженер-испытатель отвечает за связующий код и тестовый проект, а разработчик программного обеспечения пишет тестируемое программное обеспечение. Но сказать вам что? Я никогда не видел, чтобы эти подходы работали хорошо.

Итак, в другом проекте именно я предложил использовать Spock в качестве фреймворка для тестирования. Spock — это монолитный фреймворк, преимущество которого в том, что тесты написаны так, как удобно разработчикам, а также позволяют владельцам продуктов избегать написания своих требований на Gherkin. Но вот урок: в конце концов, распределение работы тоже не удалось. Почему? Потому что все больше и больше работы по тестированию перекладывалось на разработчиков, которые помимо своей работы должны были кодировать тесты, а инженер по тестированию в основном выполнял роль скрам-мастера, отвечающего за тестирование. Несомненно, это хорошо для меня как инженера-испытателя, НО благодаря такому подходу пользовательские истории бесконечно оставались на доске, не будучи доведенными до конца, поскольку просто требовалось слишком много времени, чтобы довести дело до конца.

Но опять же, устроившись на новую работу в SPIRIT ONSIDE Consulting GmbH, я наткнулся на кое-что очень классное: testOFFICE, инструмент, который может, с одной стороны, объединить распределение работы между ролями в командах и в то же время лучше инструментов и фреймворков, таких как Selenium и UFT. В этой серии сообщений в блоге я опишу некоторые из своих знаний о testOFFICE, начав с описания философии testOFFICE, а затем, в следующем, более техническом сообщении, я сравню testOFFICE с Selenium и UFT.

Методы автоматизации тестирования

Начнем с самого главного: поскольку, несомненно, существует проблема распределения работы между ролями в команде, для автоматизации тестирования были разработаны различные методы:

1. Захват и воспроизведение

2. Сценарии

3. На основе ключевых слов

4. Управляемый образцом объекта

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

testOFFICE — автоматизация функционального тестирования

testOFFICE — это решение для автоматизации тестирования, которое в первую очередь поддерживает функциональных тестировщиков, работающих в различных подразделениях. Эти тестировщики являются экспертами в ручном и исследовательском тестировании. Преимущество этих тестировщиков, которые обычно являются экспертами в предметной области, заключается в том, что для создания и поддержки тестовых случаев при использовании testOFFICE не требуется никакого опыта работы с программами.

Однако, если требуется поддержка программирования, именно здесь вступает в игру роль инженера-испытателя. Такой инженер-испытатель должен уметь программировать на Java. Эту роль обычно предоставляет SPIRIT.

В результате усилия по автоматизации тестирования составляют 95 % у функциональных тестировщиков и 5 % у инженера по тестированию. Это особенно полезный подход, учитывая, что во многих компаниях, которые хотят заняться автоматизацией тестирования, есть много тестировщиков, которые являются экспертами в области функционального тестирования, но не имеют опыта программирования. Наш опыт в SPIRIT определенно показал, что этой группе людей может быть полезно узнать, как использовать testOFFICE, чтобы помочь им оставаться в своей экспертной области, вместо того, чтобы принуждать их к карьере программиста.

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

Отличительной особенностью testOFFICE является возможность сосредоточиться на том, ЧТО машина должна делать в КАКОМ случае, КАК это делается, можно технически проанализировать автоматизированным способом с помощью testOFFICE. Это тестирование на основе ключевых слов 2.0. Эти преимущества testOFFICE поддерживаются модульной концепцией testOFFICE и концепцией его движка.

Что будет дальше в этом блоге Я сравню testOFFICE с такими инструментами, как Selenium и UFT, чтобы показать, в чем заключаются ключевые преимущества testOFFICE.