Недавно я поучаствовал во встрече тестировщиков Лондона и слушал выступление Марка Винтерингэма, который рассуждал о ментальных моделях инструментов тестирования. Содержание его доклада и слайды можно посмотреть здесь: Почему Webdriver - это круто.
Он рассказывал, как Webdriver помогает автоматизировать тестирование/проверки (нет, я не хочу развязывать дискуссию насчет определений в этой статье), и как этот инструмент облегчил его труд тест-консультанта.
Марк также обратил внимание, что инструменты, которые мы используем, определяют наше мышление, поведение и взаимодействие с приложением. Они влияют на то, как мы принимаем решения, как мы общаемся. Иными словами, инструменты начинают определять, как именно мы тестируем - если мы позволим им это.
Он сослался на один из самых ярких докладов конференции Test Bash 3 - "Автоматизация: время менять подходы" Иана МакКовветта (видео доклада можно посмотреть здесь) и сделал вывод, что к выбору инструментов и их использованию для достижения целей тестирования нужно подходить с осторожностью.
В ходе беседы Марк агитировал нас за "полигамию" в отношении инструментов. Чтобы повысить их эффективность, нужно искать новые подходы, пробовать новые инструменты. Если мы ограничиваем себя определенным набором инструментов - мы, в конечном итоге, ограничим свое мышление. Полигамия - это, конечно, забавная, но очень точная аналогия.
Зачем тестировщику-автоматизатору учить теорию? Может быть достаточно освоить какой-нибудь популярный инструмент, например, Selenium или TestComplete? Выучить какой-нибудь язык программирования, например, Java или Python? И никакая теория не нужна.
Но подождите! Раз уж зашла речь о программировании ("выучить какой-нибудь язык") -- давайте посмотрим, как там обстоят дела с теорией.
Обучение программированию начинается с понимания того, что такое алгоритм. Базовые элементы описания алгоритма одинаковы для множества языков программирования. И если человек один раз понял, что такое условие и что такое цикл -- он сможет узнать их под разными масками в разных языках программирования.
После этого, конечно, хорошо бы уже научиться писать на каком-нибудь языке, чтобы эти теоретические знания об алгоритмах применить на практике.
Но через некоторое время оказывается, что помимо алгоритмов языки содержат конструкции для описания классов -- и тогда приходится снова возвращаться к теории, чтобы понять суть объектно-ориентированного подхода. Это тоже достаточно универсальная идея, которая применяется во многих языках программирования, хотя может выглядеть очень по разному.
Освоив принципы работы с классами и объектами, человек получает в руки новый мощный инструмент. Он уже не только алгоритмы пишет, он строит архитектуру приложения. Это позволяет писать более сложные программы.
Но ещё через какое-то время выясняется, что архитектура местами получается какая-то кривая, костыли подпирают её тут и там. И приходится снова возвращаться к теории -- читать книжки про шаблоны проектирования, изучать типовые приёмы, учиться избегать стандартных ошибок проектирования.
И эти колебания от теории к практике и обратно могут повторяться многократно. Потому что есть ещё много интересного, выходящего за рамки отдельно взятого языка программирования.
А когда вы разрабатываете автоматизированные тесты -- к общей теории программирования добавляется ещё и специфическая дополнительная теория.
Онлайн-тренинг Алексея Баранцева, 1,5 месяца занятий, 7.5 часов теории + много практики + постоянные консультации тренера в скайп-чате
Первый запуск – 25 ноября, не пропустите, обычно первая группа самая активная :-)
Можно ли представить себе хорошего линуксового системного администратора, который не знает общую теорию операционных систем и сетей, не подозревает о существовании Windows и MacOS, не умеет пользоваться для настройки системы консолью так же хорошо, как графической оболочкой? Можно ли считать хорошим инженером-строителем человека, который не владеет сопроматом, не знает про современные строительные материалы и особенности их применения, даже если на текущем объекте строительства они не используются? Можно ли признать хорошим актёром того, кто день за днём играет одну и ту же роль, не знает о современных тенденциях в театральном искусстве и не пытается попробовать себя в других амплуа?
Хороший специалист должен обладать достаточно широкими знаниями. Да, он глубоко изучает какую-то одну тему, специализируется в каком-то направлении, но при этом он должен представлять себе общую картину своей профессиональной области. Если он не будет это делать -- мир уйдёт вперёд, его узкая тема окажется устаревшей и невостребованной, а он ничего другого не знает и не умеет.
Умение создавать автоматизированные тесты предполагает владение специализированными инструментами, которые так и называются "инструменты для автоматизации тестирования". Но знания хорошего специалиста должны охватывать всю область автоматизации. Какие вообще инструменты бывают? Для чего они предназначены? В какой ситуации следует (или наоборот не следует) использовать тот или иной инструмент? Как выбрать наиболее подходящий для решения задачи инструмент среди множества похожих?
И конечно же надо уметь делать хорошие автотесты. Да, сначала надо научиться понимать, чем "хорошие" автотесты отличаются от "плохих". А потом -- научиться делать "хорошие". Эти правила являются общими, независимыми от конкретного используемого инструмента.
Для тех, кто хочет расширить свой кругозор и получить общие фундаментальные знания в области автоматизации тестирования мы подготовили этот учебный курс.
Выступление Игоря Хрола на онлайн-конференции Selen ConfeT&QA
UI-автотесты не отличаются высокой надёжностью. Где-то может не хватать синхронизации и тесты будут «падать» время от времени просто так. Или фокус «слетел» и кнопка не нажалась. Эти и другие случаи зачастую делают результаты автотестов непредсказуемыми и не вызвающими доверия.
В докладе хотелось бы поделиться опытом того, как пожертвовав целью 100%-но точной эмуляции действий пользователя, можно добиться надёжных и воспроизводимых результатов от Selenium-тестов. Разговор будет основан на опыте использования данной идеи на одном из проектов, а также будут даны общие рекомендации, применимые для широкой аудитории.
Сделать побольше, потратить поменьше, тестировать одновременно и быстро, и качественно – вот задача современных компаний. Бизнес требует высоких скоростей разработки, внедрения новых возможностей и исправления дефектов, и качество продукта не должно при этом пострадать. Однако время- и трудозатратное ручное тестирование несравнимо по точности с автоматизированными тестами – и значит, настало время познакомить вашу команду с преимуществами автоматизации
"Единственный способ принять перемены - это погрузиться в них, осознавать их, двигаться в танце с ними" - Алан Уоттс.
Все хоть раз в жизни проходили собеседование. К нему нужно готовиться! Первые минуты собеседования могут стать решающими в вопросе, возьмут ли вас на работу. Почему? Да потому, что первое впечатление - всегда самое сильное. Никогда не недооценивайте силу первых впечатлений. Используйте аналогичный подход при внедрении автоматизации в команде ручных тестировщиков. Считайте, что презентация нового подхода вашей команде или организации - это собеседование. Тщательно подготовьтесь к нему. Оправдайте ожидания команды, разъясните им их новые обязанности - это очень важно, потому что люди склонны эмоционально реагировать любые потенциальные угрозы их работе.
Выступление Дмитрия Миндры на онлайн-конференции для специалистов по автоматизации тестировния Auto ConfeT&QA.
Разработка через тестирование (TDD) известна уже более 10-ти лет. Эту практику применяют десятки тысяч разработчиков. Есть масса успешных примеров, и при этом масса людей, не верящих в эффективность разработки через тестирование. Также есть заблуждение о том, что TDD заменяет работу тестировщика. При этом TDD – это всего лишь один из инструментов разработчика, решающий определенные задачи. Данный доклад является быстрым введением в TDD, который даст вам представление о нем, а также о популярных заблуждениях и мифах.
Наличие автоматизации это не переключатель с двумя положениями. Вот вчера ещё у вас ещё не было автоматизации. А сегодня -- чик! -- и она есть. Всё совсем не так.
Автоматизация -- это делегирование некоторых задач от человека машине.
Даже если вы тестируете вручную -- почти наверняка вы используете вспомогательные инструменты для автоматизации отдельных задач. Генерация тестовых данных, утилиты для анализа логов, сбора статистики, построения отчётов и графиков.
Кто-то ограничивается такими простыми вспомогательными инструментами. А кто-то делает следующий шаг -- автоматическое заполнение форм, автоматическое выполнение серии каких-то действий по горячей клавише.
Но ведь это не автоматическое выполнение тестов, можете возразить вы. Да, не полностью автоматическое. Но даже частичная автоматизация позволяет экономить время при выполнении рутинных задач, и этим она полезна.
Впрочем, нет ничего сложного в том, чтобы сделать и следующий шаг -- к полностью автоматическому выполнению тестов. И это тоже можно сделать, не умея программировать.
Есть мнение, что "хорошие" автотесты могут быть написаны только на "настоящем" языке программирования.
Но что значит "хорошие"? Если под "хорошими" подразумеваются сложные тесты, с нетривиальной логикой и интеллектуальными проверками -- тогда, конечно, потребуется полноценный язык, позволяющий выразить эту сложность.
Однако не всегда требуются сложные тесты. Зачастую можно обойтись простыми линейными сценариями с примитивными проверками, или даже вообще без проверок -- если сценарий дошёл до конца и не упал, значит всё хорошо.
И для таких простых тестов вполне можно обойтись простыми инструментами. Некоторые из них предполагают написание сценариев вручную (например, Robot Framework). Другие позволяют автоматизировать не только выполнение сценариев, но и процесс их создания. Для этого используются инструменты-рекордеры, отслеживающие и фиксирующие действия пользователей.
Для веб-приложений наиболее популярным инструментом, не требующим умения программировать и имеющим рекордер, является Selenium IDE. Научиться пользоваться этим инструментом весьма несложно, и это будет полезно всем, кто занимается тестированием веб-приложений. Хотя бы для того же автоматического заполнения форм тестовыми данными.
Выступление Надежды Дегтяревой (Самара, Mercury Development) на онлайн-конференции Mobile ConfeT&QA.
Системы сбора статистики помогают отслеживать действия пользователей при работе с приложением, чтобы сделать его ещё более функциональным и эффективным, а также значительно облегчают жизнь команде тестирования и разработки.
В своем докладе я хочу помочь вам узнать этих скрытых помощников «в лицо» и рассказать: 1. О том, что умеют популярные системы сбора статистики, и на какой лучше остановить свой выбор. 2. Как облегчить себе жизнь и сделать настройку системы статистики более гибкой с помощью Segment.io 3. Об основных тонкостях интеграции систем сбора статистики и выбора логируемых событий, почему лучше семь раз отмерить 4. Как использовать собранную статистику себе и другим во благо, чтобы создавать действительно качественные и удобные приложения
Я несколько недель наблюдал за использованием тест-кейсов в проекте по разработке ПО. Команда приступила к созданию кейсов, когда функциональные спецификации были объявлены достаточно проработанными. Кейсы были разбиты на отдельные шаги и заведены в систему управления тестами (в данном случае - в HP Quality Center). Они были проанализированы, и команда планировала приступить к их выполнению, как только продукт будет передан в тестирование.
После утверждения спецификаций прошло несколько недель, а создание продукта продвинулось очень недалеко. Тестировщики решили, что это отличная возможность поработать над тест-кейсами. Используя момент затишья перед бурей, они планировали выполнить всю подготовительную работу, чтобы быть готовыми к бою, когда первая часть программы будет передана в тестирование. К сожалению, подготовительная работа заключалась в детальной проработке тест-кейсов для программы, которая еще не была разработана, и чей функционал был толком неизвестен. К тому же тесты основывались на спецификации, которая, как выяснилось, была неполной.
Легко догадаться, что произошло потом. Когда программа была передана в тестирование, оказалось, что техническое воплощение было не таким, как предполагали тестировщики, а спецификация, приоритеты проекта и его основные задачи изменились из-за новых требований клиента. Тестировщики готовились обороняться от вооруженной копьями пехоты - а столкнулись с гаубицами. Конечно, им пришлось отступить.
Выступление Александра Хози (автор блога Записки мобильного тестировщика) на онлайн-конференции для специалистов по автоматизации тестирования Auto ConfeT&QA.
Мобайл — молодая и стремительно развивающаяся отрасль, где лидеры и правила игры меняются с огромной скоростью. В силу молодости подходы к разработке и тестированию еще не окончательно устоялись, и имеется целый ряд препятствий, отравляющих нам жизнь. Если опытного мануального тестировщика мобильных приложений можно опознать по развитым хватательным рефлексам и мозолям на пальцах, то опытного автоматизатора мобильных приложений под iOS — по красным от слез глазам :)
Поделюсь с вами, почему автоматизация мобильных приложений — нетривиальный процесc. В частности, почему автоматизация iOS приложений — особенная пичалька :)
Расскажу:
какие ограничения существуют у мобайла и у iOS в частности;
какие инструменты мы исследовали;
что выбрали;
«по пацански» ли использовать screenshot-based средства;
как мы скомбинировали screenshot-based c «традиционными» инструментами автоматизации;
