Home

Оригинал публикации: 

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

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

Ожидание №1: Можно тратить время на изучение фреймворка и тест-кейсов при автоматизации нового приложения.

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

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

Оригинальная публикация: https://habrahabr.ru/post/326020/

"Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”.

Так работали всегда

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

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:

Нажмите на картинку, чтобы увеличить изображение

Оригинальная публикация: https://habrahabr.ru/company/jugru/blog/329372/

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

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов. 

Marc Philipp – один из основных разработчиков фреймворка JUnit 5 – инструмента для Java-тестировщиков. В данный момент работает в качестве инженера в немецкой компании LogMeIn над облачными SaaS-решениями.

Всеволод Брекелов — Senior QA Engineer в компании Grid Dynamics, более 5 лет занимается тестированием, имеет опыт построения автоматизации тестирования с нуля.

Автоматизация тестирования — сфера, в которой идет постоянная работа над улучшениями, увеличением надежности и простоты использования.

Некоторые инструменты могут помочь создать лёгкие, надежные и легко поддерживаемые скрипты, но сами тяжелы в использовании. Другие — более просты в использовании, но на выходе вы получаете тест скрипты которые тяжело поддерживать. Каждый раз мы сталкиваемся с выбором, при котором мы где-то выигрываем, а где-то проигрываем.

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

На протяжении прошлой недели я работал с простым, но мощным софтом — Katalon Studio. Он вмещает в себя UI возможности, которых мне так не хватает в Selenium WebDriver и гибкость, которой не может похвастаться UFT. И да, он абсолютно бесплатный.

=> Если вам интересно узнать больше, мы уже сделали один обзор этого бесплатного инструмента: Katalon Studio review. 

Оригинал статьи: http://www.ontestautomation.com/monitoring-the-quality-of-your-test-automation-code/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

Если вы работаете в Agile-команде, то периодически вам придется (или "у вас будет возможность", зависит от ваших взглядов) браться за задачи, находящиеся вне вашей "зоны комфорта", или как минимум отличающиеся от ваших обычных дел. В течение нынешнего спринта у меня было свободное время, а в проекте накопился приличный технический долг, относящийся к качеству кода, и команда решила, что неплохо бы с ним частично разделаться. Я никоим образом не разработчик, но кое-что понимаю в коде (я и не шеф-повар, но ужин приготовить могу), поэтому я усмотрел в этом возможность получить дополнительный опыт по чтению, интерпретированию и правке кода. В нашем нынешнем проекте мы используем SonarQube в качестве платформы для управления качеством. Я никогда раньше не работал с этим инструментом, поэтому ничего особенного от него не ожидал, но пока что мне все нравится.

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

Аргумент "за": создание автотестов – это разработка ПО.

Успешное внедрение автоматизации требует к себе отношения, аналогичного отношения к любому другому проекту по разработке ПО: автоматизация требует планирования, внятного дизайна и наличия разработчиков автотестов, которые знают толк в своем деле. Почему бы не отнестись к коду автотестов так же, как и к коду продукта, вплоть до оценки его качества? Как и любой другой код, созданный в течение жизненного цикла ПО, код ваших автотестов должен быть читабелен и легок для поддержки. Под "легким для поддержки" я имею в виду возможность исправлять и дополнять его после того, как создавший автотесты гений перешел на другую должность или покинул компанию. Опять-таки, мы же поступаем так с кодом продукта, почему бы не поступать так с автотестами?

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: http://www.ontestautomation.com/trust-automation/

Перевод: Ольга Алифанова

Сейчас большинство людей уже в курсе, что цель автоматизации – это НЕ "поиск багов". Конечно, неплохо, когда ваши автотесты ловят баг-другой, которые иначе просочились бы в продакшн. Но пока искуственный интеллект автоматизации не достиг больших высот (я имею в виду, действительно БОЛЬШИХ), тестировщики куда более искусны в поиске багов, чем самые умные, развитые автоматизированные решения для тестирования.

Нет, добавочная ценность автоматизации совсем в другом – в уверенности. Из оксфордского словаря:

"Уверенность: твердое убеждение в надежности, правдивости, или способности чего-либо или кого-либо."

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

Эта уверенность появляется благодаря доверию:

Автор: Александр Андряшин

Оригинальная публикация: https://habrahabr.ru/post/327184/

Представляю вам перевод моей статьи на Medium.com.

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

Проблема

Как веб-разработчик или инженер по автоматизации тестирования вы можете столкнуться со следующими неудобствами при работе со стандартным Selenium сервером:

1. Нужно устанавливать несколько разных браузеров себе на компьютер. В обычной жизни вы, как правило, используете один браузер, например, Chrome, но вам приходится устанавливать себе Firefox и Opera, чтобы отлаживать в них Selenium-тесты.
2. Трудно устанавливать и использовать несколько версий одного браузера. Если вы устанавливаете браузер из пакетов, то вообще можно иметь только одну установленную версию. Кроме того Selenium и его веб-драйверы обычно ищут исполняемый файл браузера по определенному пути. Поэтому, поверьте, использовать несколько версий может быть трудной задачей.
3. Если вы запускаете браузер, установленный в вашей операционной системе — он забивает место на диске своими временными файлами и содержимым кеша.
4. Нельзя гарантировать, что настройки браузера всегда останутся в том же состоянии, как после чистой установки. Например, вы можете случайно изменить адрес прокси-сервера или настройки безопасности. Это может привести к падению ранее работавших тестов.
5. Трудно запускать несколько тестов в разных браузерах параллельно. Попытка сделать это как правило приводит к различным проблемам: окна начинают конкурировать за фокус, не срабатывающие события, не ожидаемые CSS стили и так далее.
6. Нужно знать какая версия Selenium совместима с какой версией браузера. То же самое верно для исполняемых файлов веб-драйверов (например, Chromedriver).

Приведенный выше список недостатков далеко не полный. Но давайте остановимся на этом и попробуем гораздо более удобный способ отладки Selenium-тестов локально.

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2017/01/09/how-to-start-learning-automation/

Перевод: Ольга Алифанова

Люди спрашивали меня, как им узнать больше про автоматизацию тестирования. Я думаю, все согласны, что знать что-то про автоматизацию, работая в сфере QA – дело хорошее, и может быть подспорьем в нашей работе – не говоря уже о росте ценности наших резюме.

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

Я хочу поделиться с вами тремя Большими Секретами. Бесплатно. Только сегодня, только у нас. И вы сможете начать учиться автоматизации.

Большой секрет №1: "Нельзя рулить припаркованной машиной"

Эту фразу произнес мой тесть много лет назад, когда я просил у него духовного наставничества. Я задумался, как я узнаю, в каком направлении мне двигаться, одобряет ли Господь то, что я делаю?

Ответом тестя было "Нельзя рулить припаркованной машиной".

Нет, дальше он развил свою мысль, конечно же.

Где-то минуту я осмыслял, что он имеет в виду, и в конце концов понял: Господь будет направлять мою жизнь, если я начну движение. Я начну движение – он начнет рулить.

Довольно крутая аналогия.

Эта мудрость достаточно коротка и влезет даже на кепку, но применима в большом количестве ситуаций. "Если речь идет об обучении автоматизации, спросите себя, в каком направлении вам двигаться?" А движетесь ли вы вообще? Вы не можете двигаться в каком-то направлении, если вы припаркованы.

Если вы не движетесь хоть в какую-то сторону (которую можно выбрать позднее), то заведите машину и нажмите на газ.

Автор: Дмитрий Мамонов, Департамент разработки, Wrike

Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.
Л.Кэрролл, «Приключения Алисы в стране чудес»

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

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

Автор: Олег Половинкин

Оригинальная публикация

Материал основан на реальном проектном опыте.

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

Забегая вперед, отмечу, что сейчас релизы проходят каждый день или через день, а ручная часть тестов (то, что оказалось невозможно автоматизировать по тем или иным причинам) занимает примерно столько же времени, что и прогон автотестов с просмотром результатов.