OpenQuality.ru
Качество программного обеспечения
Содержание:
7 августа 1974 года французский канатоходец Филипп Пети прогулялся по канату, натянутому между Северной и Южной башнями-близнецами Всемирного торгового центра в Нью-Йорке. Прогулка продолжалась 45 минут, во время которых Филипп восемь раз прошел туда и обратно. Сразу после головокружительного променада Филипп был арестован полицией, но все обвинения были сняты в обмен на бесплатное представление для детей в Центральном парке Нью-Йорка.
Заниматься автоматизацией тестирования – это идти по канату, прокинутому через пропасть. Неверный шаг может дорого стоить для тебя, для проекта и для компании в целом. А если твои взгляды на автоматизацию тестирования не вписываются в какие-либо рамки, то даже при позитивных результатах можно нарваться на критиков, которые вонзят клыки в твою плоть: “Ах ты такой-сякой, зачем ты взялся за одно, а не за другое, что за фигню ты юзаешь, а где у тебя то, а где у тебя сё”. Поэтому лучше сразу расставить все точки над i:
Я полагаю, что нет единственно верных подходов к организации и написанию автотестов. Их реализация в значительной степени зависит от интерфейсов тестируемого продукта, его текущего состояния, требований к продукту, а также организации работы в проекте (product management, разработка, тестирование). Одни и те же подходы могут быть полезны в одном проекте и бесполезны в другом. Любой шаг или вектор в разработке автотестов для конкретного продукта всегда субъективен (как и в любой сфере деятельности). Всегда есть плюсы и минусы, подводные камни, согласные и несогласные, поэтому в первую очередь здесь важна ответственность лица, принимающего решение. Вот задача, вот критерии, вот что нужно учесть, вот решение, вот реализация, вот пропасть и вот покоренные вершины.
В сухом остатке, все нижеизложенное – это просто немного общеизвестной информации плюс мысли без претензий на истину в последней инстанции. В один прекрасный день я перечитаю это и ужаснусь: “Вот же какой лопух я был”. Все течет, все эволюционирует.
Автотесты в общей структуре обеспечения качества
Знаменитая пирамида тестирования Фаулера выделяет модульные тесты, сервисные тесты, а также тесты в графическом интерфейсе.
В соответствии с этой концепцией считается, что в продукте должно быть как можно больше модульных тестов, какое-то существенное покрытие сервисными (интеграционными) тестами и небольшое количество UI-тестов. Почему так? Потому что, как правило, UI-тесты сравнительно медленные, дорогие в разработке и поддержке, а также хрупкие. Попробуйте автоматизировать клики по нужным элементам в Veeam ONE Monitor, и вы меня поймете.
Кстати, на заре зарождения автоматизации тестирования довольно популярным был обратный подход – как можно больше тестов через пользовательский интерфейс. Такая концепция получила название “рожок мороженого” в соответствии с картинкой, иллюстрирующей этот подход.
Ваш покорный слуга в свое время прошел через три этапа:
2. Не, так не пойдет, заплюхаемся с UI. Давайте за потроха дергать. Здравствуйте, Com-объекты, CLI и API.
3. Нужна золотая середина – смотрим за что можно дернуть и оцениваем эффективность (но об этом ниже).
Как правило, модульные тесты (unit tests) пишут разработчики: либо в рамках методологии TDD (сравнительно редко), либо постфактум (после написания кода приложения), либо вообще не пишут - зависит от квалификации разработчиков, позиции менеджмента и возраста проекта:
Есть и другой край спектра: разработчики пишут тесты на всех уровнях пирамиды тестирования. Классический пример: SQLite. Разработчики этого продукта в свое время заявляли о 100% покрытии кода автотестами.
Обычно тестировщики-автоматизаторы (то есть, люди из QA) не пишут низкоуровневые модульные тесты. Во-первых, нужна соответствующая квалификация (досконально понимать код продукта). Во-вторых, это не всегда считается важным. Но порой в одном месте сходятся люди с нужной квалификацией и назревшие потребности в модульных тестах, и результат может порадовать Мартина Фаулера (автора пирамиды тестирования). Более того, в отдельных компаниях есть даже позиции типа Software Developer In Test (SDET). Иногда под это определение попадают обычные “тестировщики-автоматизаторы от QA”, но порой это достаточно квалифицированные разработчики, которые full time пишут низкоуровневые тесты либо специализированные инструменты для их написания. Например, таких людей много в Google. И раз уж мы упомянули Google, то вот ссылка на, пожалуй, самую нашумевшую статью по автотестам за последние несколько лет.
Как бы то ни было, в большинстве случаев тестировщики-автоматизаторы пишут интеграционные и высокоуровневые автотесты, задействуя CLI, API, REST, командлеты, пользовательский интерфейс.
Выбор теста на автоматизацию и критерии хорошего автотеста
Зачем нужны автотесты, которые пишут тестировщики-автоматизаторы? Для того чтобы снять часть нагрузки с ручных тестировщиков:
2. Автотесты избавляют от рутинных проверок как в наиболее часто используемых, так и в редкотестируемых сценариях. Если в автотестах удается реализовать перебор различных вариантов в той или иной функциональности (опции продукта, версии OS, SQL Server и т.п.), то у ручных тестировщиков высвобождается время на более интеллектуальные сценарии.
Вот каких принципов мы придерживаемся:
С учетом этих принципов и специфики наших продуктов мы обсуждаем возможные сценарии для покрытия автотестами и определяем их приоритеты. Этими же принципами мы руководствуемся при выборе технологий, языков, инструментов и структуры автотестов. Мы отслеживаем наработки и веяния в нашей отрасли и стремимся брать из них самое лучшее, но при этом мы не гонимся за новизной ради новизны и во главу угла ставим наши задачи и потребности. При внедрении технологий и инструментов мы стремимся не впадать в две крайности: изобретать свой велосипед и жить с недостатками готовых решений. Иными словами, мы всегда ищем разумный компромисс в подходах, сценариях и инструментах, чтобы наши автотесты приносили пользу. Вопрос не в том насколько тот или иной инструмент стар или нов, популярен или нет. Вопрос в том сможет ли он эффективно прослужить нам N запланированных лет на вот этом конкретном продукте с учетом его запланированной траектории развития.
В качестве примера рассмотрим реализованный сценарий для продукта Veeam ONE. Один из компонентов продукта – Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов “в лоб” с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп, вызывая их из Powershell. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.
Юный автоматизатор начинает с написания простых тестов в соответствии с согласованными планами/подходами/инструментами. Решает самые простые задачи, учится справляться с трудностями, находить решения. Матереет, обрастает знаниями и навыками. Задачи становятся все более серьезными, кредит доверия автоматизатору растет. Если автоматизатор не останавливается в своем росте, то спустя какое-то время он дорастает до разработки комплексных технических решений и более глубокого участия в обсуждении стратегии и приоритетов в разработке автотестов. В один прекрасный день он принимает под свое крыло юных автоматизаторов, которые хотят приносить пользу и расти.
Ну и раз уж речь идет про карьеру автоматизатора, позвольте сообщить, что мы в Veeam будем рады новым боевым товарищам. У нас нет формализма, есть драйв, профессиональный и карьерный рост, комфортные условия, желание и возможность выпускать лучшие в мире продукты и готовность помогать друг другу. Вот навыки специалиста, который был бы нам особенно интересен:
Если вы только вступаете на дорогу автоматизации, не имеете опыта с WebDriver и REST, но уверенно себя чувствуете в написании кода на C# и питаете глубокий интерес к сфере автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.
Мы будем рады вашему резюме и неформальному сопроводительному письму (почему вам интересна работа в Veeam, что привлекло вас в нашей вакансии, ваши сильные стороны). Пожалуйста, присылайте резюме с сопроводительным письмом по адресу qa@veeam.com
Успехов на нашем поприще.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : Заметки по автоматизации тестирования — Блоги экспертов | August 23, 2019
[…] Источник […]
Автор комментария : Максим | September 16, 2019
“Ручные тестировщики доверяют результатам автотестов.”
Почему именно ручные? У вас обрабатывают результаты прогона тестов не те, кто написал код приложения?
“Желательно, чтобы ручной тестировщик понимал, что именно и как тестирует автотест” - если он их при этом не пишет, мы имеем оверхед в виде аллюра и прочей ненужной отчетности.
[Ответить]
Капитан отвечает:
September 16th, 2019 в 1:06 pm
Максим, добрый день.
На текущий момент результаты прогона тестов обрабатывают те, кто их пишут – тестировщики-автоматизаторы.
По поводу ручных тестировщиков есть два нюанса. Первый нюанс описан в статье (не должно быть false negative и false positive тестов + желательно, чтобы ручной тестировщик понимал, что именно и как тестирует автотест – тогда ему будет ясно, что автотест на данный момент может проверить и что нет). Второй нюанс: в перспективе обработку результатов автотестов хочется возложить на ручных тестировщиков, чтобы у них была полная картина по продукту, а у автоматизаторов больше времени на написание автотестов.
На данный момент разработчики продукта не смотрят результаты автотестов, написанных командой QA-автоматизаторов. Гораздо эффективнее прийти к ним с багом: вот сценарий, вот ожидаемое поведение, вот результат, вот логи. Разработчики смотрят результаты низкоуровневых unit-тестов, которые написали сами, но это уже совсем другая история.
Не обязательно прикручивать аллюр и прочую ненужную отчетность. К примеру, если автотест запускает хранимую процедуру на SQL-сервере и проверяет ее результат, то достаточно просто вывести ожидаемый и реальный результаты. Если они не совпадают, то ручному тестировщику ясно, что что-то может быть не так с компонентом, который эту процедуру использует – если, конечно, это не баг в автотесте и не проблемы с энвайронментом (как правило, это видно без углубленного понимания работы автотеста).
[Ответить]