Home

Автор: Ричард Брэдшоу (Richard Bradshaw)

Оригинал статьи: http://www.thefriendlytester.co.uk/2016/08/give-your-automated-checks-voice.html

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

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

Однако поговорить я хочу об автоматизированных проверках. Они могут куда больше, нежели тупо сообщать "Пройдено/Не пройдено", если вы их как следует попросите. Я расскажу о четырех фокусах, которыми пользовался я, и о том, как они мне помогли.

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

Оценка методологии автоматизации - MBT, Дмитрий Химион, Performance Lab, Москва, Россия

Как мы приручили демона или процесс тестирования демонов в Badoo, Anton Volkov, Badoo, Москва, Россия

Jenkins 2.0: Организуем тестирование в составе Continuous Delivery, Oleg Nenashev, CloudBees, Inc., Neuenburg, Швейцария

Игры с огнём: знакомимся с BDD и Cucumber фреймворком BDDfire, Vladislav Romanenko, Intellectsoft, Минск, Беларусь

Автор: Дэн Эшби (Dan Ashby)

Оригинал статьи: https://danashby.co.uk/2016/03/08/information-and-its-relationship-with-testing-and-checking/

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

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

Многие тестировщики считают, что они обязаны научиться автоматизировать, чтобы не потерять работу. Люди, считающие себя экспертами по тестированию, тоже верят в это и пропагандируют этот подход в обсуждениях в Интернете.

Я читал статью Майкла и Джеймса, которая объясняет, в чем разница между "тестированием" и "проверками", а также то, как школа контекстно-управляемого тестирования рассматривает автоматизацию. Мне нравится статья, и я пытался познакомить с ней компании, страдающие от вышеописанной проблемы – но эти проблемы никуда не делись. Когда я интересовался, прочитали ли люди статью, они обычно отвечали, что она "слишком длинная", или что им не нравится термин "проверка" (многие автоматизаторы рассматривают этот термин как уничижительный для своей работы – они относятся к нему примерно так же, как я к "ручному тестированию").

Как же помочь людям понять, о чем я говорю, как упростить мои объяснения?

Вопрос применения автоматизированного тестирования очень популярен среди специалистов нашей области. Когда необходимо автоматизировать и почему? Сегодняшняя подборка посвящена именно этой теме. Ниже вы найдете видеозаписи нескольких блиц докладов с конференции 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 Пол Гроссман рассказал про свои пять секретов автоматизации тестирования (то есть про пять вещей, которые ни в коем случае не нужно делать, если вы хотите эффективно автоматизировать).

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

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

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

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

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