В этой статье мы рассмотрим инструмент Appium. Данная статья является вводным материалом для введения в автоматизированное тестирование мобильных приложений. Она покажет с какими трудностями возможно придется столкнуться при использовании данного инструмента.
Рассмотрим небольшую задачу на примере «калькулятора», попробуем написать автоматизированные тесты для тестирования его и… Начнем с саааамого начала :)
Читать полностью »
Прим. пер.: эту статью я перевела в помощь тем, кто делает первые шаги в автоматизации тестирования и хочет узнать больше об инструменте Appium. В ней описывается общий принцип работы драйверов Appium, а также их виды и назначение. В начале пути многим тестировщикам не хватает упорядоченной информации, а этот материал поможет определиться с выбором нужного инструмента.
Appium — это кроссплатформенный инструмент, который позволяет автоматизировать тестирование мобильных (iOS и Android) и десктопных приложений одновременно. Способ реализации этой мультиплатформенной модели заключается в использовании различных драйверов. По сути, Appium имеет примерно ту же архитектуру, что и Selenium WebDriver, который также использует ряд независимых драйверов для поддержки кроссбраузерной автоматизации тестирования.
Читать полностью »
Привет!
Я довольно давно и много занимаюсь автоматизацией тестирования. И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Обновили XCode, вышла новая Selenium, придумали новый браузер (особое спасибо Microsoft за Edge и его драйвер), зачем-то вот вам еще один язык программирования… Все это автоматизатора приводит исключительно в радость от осознания собственной значимости. Ведь только он теперь способен запустить тесты на всем этом.
Менее опытные ребята, кто только постигает все азы и таинства работы с тестами почему-то радость не испытывает. На нашем курсе по автоматизации ученики часто спрашивают про то, как работать с новыми версиями тех или иных составляющих стека. Об этом сегодня я и решил рассказать. Кому интересно — добро пожаловать под кат.
Добрый день. Я занимаюсь автоматизацией тестирования. Как и у всех автоматизаторов, у меня есть набор библиотек и инструментов, которые я обычно выбираю для написания тестов. Но периодически возникают ситуации, когда ни одна из знакомых библиотек может решить задачу с риском сделать автотесты нестабильными или хрупкими. В этой статье я хотел бы рассказать, как вроде бы стандартная задача использования mock'ов привела меня к написанию своего модуля. Также хотел бы поделиться своим решением и услышать обратную связь.
Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) – наше все; 2) автоматическое тестирование – не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Продукту уже 12 лет, но он до сих пор активно разрастается. Деплои происходят раз в день, а иногда и два. Поэтому нам критически важно, чтобы регрессия проводилась исключительно на автотестах. Однако в Wrike (в компании) свыше 30-ти scrum-команд, а штат команды автоматизаторов не резиновый. В таких условиях ожидать автоматизации ручных сценариев в лучшем случае один-два спринта – не вариант. Опыт нашей компании говорит, что ручной тестировщик может самостоятельно писать автотесты, при соблюдении некоторых нюансов. В статье расскажу о них и почему, на мой взгляд, это умение не только помогает соответствовать тенденциям, но и будет полезно для самого тестировщика.
Читать полностью »
Четыре из пяти соискателей-QA хотят научиться работать с автотестами. Не все компании могут осуществить такие желания ручных тестировщиков в рабочее время. Wrike провёл школу автоматизации для сотрудников и реализовал это желание для многих. Я в этой школе участвовал именно как ученик-QA.
Я научился работе с Selenium и сейчас самостоятельно поддерживаю определённое количество автотестов практически без помощи извне. И, по итогам нашего совместного опыта и моих личных выводов, я постараюсь вывести ту самую формулу как можно более идеальной школы автоматизации.
Читать полностью »
FYI: this article is an expanded version of my talk at SQA Days #25.
Based on my experience with colleagues, I can state: DB code testing is not a widely spread practice. This can be potentially dangerous. DB logic is written by human beings just like all other «usual» code. So, there can be failures which can cause negative consequences for a product, business or users. Whether these are stored procedures helping backend or it is ETL modifying data in a warehouse — there is always a risk and testing helps to decrease it. I want to tell you what tSQLt is and how it helps us to test DB code.
FYI: эта статья представляет собой дополненную версию моего доклада на SQA Days #25.
Опираясь на свой опыт общения с коллегами, могу утверждать: тестирование кода в БД не является распространённой практикой. Это может нести в себе потенциальную опасность. Логику в БД пишут такие же люди, какие пишут «обычный» код. Следовательно, там так же могут присутствовать ошибки, и они так же могут повлечь за собой негативные последствия для продукта, бизнеса и потребителей. Неважно, идёт ли речь о хранимых процедурах, помогающих бэкенду, или о ETL, преобразующих данные в хранилище — риск есть, и тестирование может его существенно снизить. О том, что такое tSQLt и как оно помогает нам в тестировании кода в SQL Server, я и хочу вам рассказать.
Привет!
Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел.
Справедливости ради, подобное мнение бытует и среди ребят постарше. Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Обо всем этом и многом другом под катом.
Привет!
В мире автоматизации новичку ориентироваться довольно сложно. Приходится узнавать множество понятий, разбираться в особенностях существующих инструментов. Например, вот: Selenium, Selenide, Selenoid, Selendriod — что это, чем отличается? Да и можно ли их сравнивать?
Написал статью, чтобы помочь в этом разобраться. Кому интересно, добро пожаловать под кат!
