Home

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

Ниже представлены записи следующих докладов:

• Автоматизация тестирования ролей и привилегий, Serhii Ivashchenko, X1 Group, Харьков, Украина
• GUI-автоматизация в Telerik Test Studio, Мария Афанасьева, T-Systems, Санкт-Петербург, Россия
• Полуавтоматизация third-party API или избавляемся от лишних зависимостей, Елена Бычкова, Mail.ru Group, Москва, Россия
• Тестирование в изоляции: Играем в драконий покер, Eugeny Govako, OOO "Deutsche Bank Technology Center", Санкт-Петербург, Россия

Автор: Брэндан О'Коннолли (Brendan O'Connolly).

Оригинал статьи: http://www.brendanconnolly.net/a-healthier-relationship-with-code/

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

То, что в мире существует код – это здорово, потому что благодаря этому у тестировщиков есть работа. Несмотря на наши тесные взаимоотношения с ним в повседневном труде, многие тестировщики выстраивают их дисфункционально. Почему это происходит? Как это изменить?

Страх

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

…59% людей, начавших обучение на программе бакалавриата в области компьютерных и информационных наук в 2003-2004 годах или бросили обучение, не получив степень (31%), или переключились на другую область (28%) к 2009 году.

Навряд ли все они забросили образование, чтобы ринуться основывать Фейсбук или Майкрософт – а ведь они выбирали эту профессию сознательно. Программирование для многих выглядит как набор магических рун, которые, будучи разложенными в правильном порядке, заставляют швабры и ведра весело летать, как в Диснеевских мультиках. Конечно, здорово, когда швабры и ведра летают сами по себе, и это безусловно поможет в уборке, но если вы не контролируете магию, которая ими управляет – вы начинаете бояться ее.

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

Автор: Лукас Розуонек (Łukasz Rosłonek).

Оригинал статьи: http://testdetective.com/top-5-traps-of-test-automation/

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

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

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

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

Как раз этот вопрос обсуждали участники конференции SQA Days 19 и вот к каким выводам они пришли:

Как перестать бояться и начать автоматизировать. Или не начать, Алексей Лянгузов, Behavox, Санкт-Петербург, Россия

JDI: Автоматизировать проще, чем кажется, Наталья Гребенщикова, EPAM, Санкт-Петербург, Россия

Тестирование систем процессинга банковских карт. Особенности и сложности, Алексей Зенкин, АО Сбербанк-Технологии, Москва, Россия

Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.

Как обычно для читателей нашего портала действует промокод на получение 10% скидки.

Промокод для получения 10% скидки - s-t.ru

Обсудить в форуме

Автор: Джефф Найман

Оригинал статьи: http://testerstories.com/2015/12/automation-language-is-not-necessarily-your-development-language/

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

Множество компаний считает, что тестировщики обязаны использовать тот язык программирования, на котором написано тестируемое приложение. Если компания пишет на Java, то все тестовые решения обязаны быть именно на Java. Это абсолютно неверный, близорукий подход к вопросу. Такая ситуация возникает, если менеджеры разработки отвечают за создание тест-команды, или когда тестировщикам приходится полагаться на других людей, чтобы они сделали их работу (и заодно подумали) вместо них самих.

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

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2016/07/test-infected-developers.html

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

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

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

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

Автор: Джо Колантонио (Joe Colantonio), Пол Гроссман (Paul Grossman)

Оригинал статьи: https://www.joecolantonio.com/2016/05/26/5-secrets-test-automation/

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

В эпизоде TestTalks Пол Гроссман рассказал про свои пять секретов автоматизации тестирования (то есть про пять вещей, которые ни в коем случае не нужно делать, если вы хотите эффективно автоматизировать).

Ниже – краткое содержание интервью с ним.

Отсутствие документации

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

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

Первое, что сделал Пол, когда стал разбираться в унаследованной от предшественника системе автотестов – это убедился, что каждое внесенное разработкой или тестировщиком изменение внятно документировалось.

Автор: Дороти Грэм (Dorothy Graham)

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

Оригинал статьи: http://dorothygraham.blogspot.ru/2016/05/test-automation-as-orchard.html

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

Автоматизация – это ОЧЕНЬ просто.

Переформулирую, пожалуй – зачастую автоматизация кажется очень простой штукой.

Когда вы смотрите на первое демо, или запускаете свой первый автотест, вы чувствуете себя волшебником . Ого-го! Это так круто! Хотел бы я уметь печатать так быстро!

Но хорошая автоматизация сильно отличается от этого вашего первого запуска.

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

Однако хорошая автоматизация – это скорее организация этого огорода, позволяющего прокормить небольшой городок.

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

Оригинал статьи: https://testzius.wordpress.com/2016/02/22/continuous-integration-strategies/

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

Привет! В вашей компании наверняка есть автотесты в той или иной форме, которые делают работу за вас.

Они экономят вам время, правда?

Эээ... не всегда.

Чем больше команд переходит на DevOps, тем очевиднее становится необходимость автоматизировать автотесты.

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

Этот процесс называется "непрерывная интеграция" (CI) или "непрерывная разработка" (CD).

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

Автор: Оливер Эрлевайн (Oliver Erlewein)

Оригинал статьи: http://hellotestworld.com/2016/02/18/test-automation-sells/

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

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

Тестирование и качество - это неосязаемые вещи, и непрофессионалу трудно вникнуть в их суть. Потому-то идея урезать расходы на них так привлекательна, ведь мы ничему не навредим – ну, протестируют наполовину, но протестируют же? Когда появятся проблемы, отследить их связь с урезанным бюджетом уже не так-то просто (а бюджет уже согласован и утвержден). К тому же все мы знаем, что тестировщикам лишь бы поныть и пожаловаться на жизнь.

Поэтому автоматизация тестирования преподносится менеджерам (в большинстве случаев не имеющим к тестированию никакого отношения), как эротичная модель в купальнике из глянцевого журнала. Блага, которые предлагает автоматизация, просты и понятны:

• Экономия денег: успеете больше, наняв меньше людей
• Сокращение сроков: протестируете продукт быстрее.
• Простота: этим может заниматься кто угодно (особенно если вы снабдите этого "кого угодно" специнструментами, отправите на тренинги и купите у нас еще что-нибудь).
• За автоматизацией будущее! Вы же не хотите, чтобы вас поймали на отсутствии автотестов?
• Запись и воспроизведение тестов (этот аргумент помер еще в конце 90-х, но все равно иногда всплывает).
• Тестировщик, научись автоматизировать или вон из профессии!
• Гибкие методологии невозможны без автоматизации.
• Непрерывная интеграция и деплой невозможны без автоматизации.
• Это передовой опыт!
• Единороги и радуги! Хотя нет, такого аргумента я не видел... пока что.