Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...
Привет, меня зовут Иван, я работаю руководителем горизонтали автоматизаторов в Skyeng. Занимаюсь менеджментом ресурсов автоматизаторов, внедряю процессы, которые упрощают работу ребят, пишу инструменты для команды (слак-бот, всякие интеграции с TMS и др.), менторю начинающих автоматизаторов и, иногда, пишу авто-тесты.
Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем :)
Месяц назад мы приняли участие в конференции SQA Days. Наши эксперты выступили с докладом (вот презентация, ждите подробную статью и видео выступления) и провели ряд активностей на стенде. Сегодня мы хотим рассказать об одной из них – и интересна она тем, что по факту это задание, которое в «AliExpress Россия» используется на собеседования тестировщиков.
В этом материале мы расскажем о предыстории появления тестового задания, его эволюции и дадим возможность всем желающим проверить свои силы в поисках багов.
Кукусики!
Меня зовут Юля, и я Mobile QA в компании Vivid Money.
В тестировании уже давно — столько всего интересного видела. Но как показывает практика, проблемы и заботы у всех одинаковые. Разница только в анализе, подходах и реализации решений.
В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!
Расскажу по порядку:
Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!
Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.
Всем привет! Меня зовут Александра Кабехова, я - QA Team Lead в компании «Ренессанс страхование». В этой статье хочу поделиться опытом тестирование SOAP- запросов через SOAP UI Open Source. Когда я погружалась в тестирование API, то у меня практически не было никакого опыта, пришлось самостоятельно нарабатывать базу знаний и лайфхаков, собственно про некоторые из них и хочу рассказать.
Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в процессе разработки, но столкнулись с несколькими трудностями на этом пути.
Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA отделу приходится тестировать новые фичи, их интеграцию в приложение и заниматься регрессионным тестированием. За неделю нужно проводить как минимум одно комплексное регрессионное тестирование, что довольно утомительно. Все эти трудности мы преодолели с помощью автоматизации, которая помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования — в докладе наших коллег.
Сложности в разработке часто решаются с помощью паттернов — обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже удобное wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования.
Без дальнейших предисловий перейдём к трудностям, с которыми мы боролись, и рекомендациям по их преодолению с помощью тех самых паттернов. Замечу, что это не единственные проблемы, которые у нас были и есть. Но в рамках данной статьи я решил остановится именно на приведенных ниже пунктах.
Файлы блокнотов Jupyter, в смысле количества одного из самых быстрорастущих типов файлов на Github, предоставляют простой интерфейс для итераций при решении визуальных задач, будь то анализ наборов данных или написание документов с большим объёмом кода. Однако популярность блокнотов Jupyter сопровождается проблемами: в репозитории накапливается большое количество файлов ipynb, многие из которых находятся в нерабочем состоянии. В результате другим людям трудно повторно запустить или даже понять ваши блокноты. В этом руководстве рассказывается, как для автоматизации сквозного (end-to-end) тестирования блокнотов можно воспользоваться плагином pytest nbmake.
К старту флагманского курса о Data Science — области, в которой блокноты Jupyter незаменимы — делимся переводом статьи из блога CI Semaphore о том, как при помощи Semaphore проверить, что ваши блокноты Jupyter находятся в рабочем состоянии и для этого больше не запускать блокноты вручную.
— «... ну вот опять, снова вернулась ко мне задача из тестирования, сколько можно уже?» — Вася зло прокомментировал появившееся уведомление о новом письме.
Привет, меня зовут Вася и я fullstack-разработчик. Сегодня я расскажу вам историю, как в одной маленькой команде мы попытались отказаться от ручного тестирования — почему понадобилось, что делали, что получили.
Конечно же, история будет полна героических подвигов, внезапных сюжетных поворотов, тяжелых предательств и настоящей любви.
Кому будет интересна статья:
• Руководителям команд/направлений, ищущих способы ускорить/удешевить разработку;
• Ручным тестировщикам, желающим начать заниматься Quality Assurance;
• QA, как «ещё один успешный кейс улучшения процессов в команде»;
• Разработчикам, неравнодушным к процессам в команде.
Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?
Исчерпывающее тестирование невозможно. Это один из ключевых принципов тестирования программного обеспечения. Перед тем, как начнется автоматизация тестирования, вам необходимо принять решение на основе данных о том, что вы будете автоматизировать, а что нет, и в каком приоритете. При принятии решения о том, что автоматизировать, следует учитывать несколько основных моментов, например уровень автоматизации, на котором вы будете создавать свои тесты. Автотесты можно разделить на три основных уровня: модульные тесты, интеграционные тесты и UI тесты. Вы должны оценить плюсы и минусы написания тестов на каждом из этих уровней, прежде чем приступать к их написанию.
Независимо от того, какой уровень автоматического тестирования вы выполняете, цель должна заключаться в автоматизации того, что приносит наибольшую пользу и учитывание областей, всегда тестируемых для каждого релиза, и областей, которые трудно тестировать вручную. Вам также следует обратить внимание на области, в которых требуется обрабатывать огромные объемы данных. Все эти факторы необходимо учитывать перед автоматизацией. Если вы создаете автотесты вслепую или по своей прихоти, это увеличивает вероятность того, что вы не получите от них столько пользы, сколько следовало бы.
Стабильность и скорость ― это то, что ожидается от автотестов. В этой статье я расскажу о нашей стратегии по оптимизации тестовой пирамиды, о том, почему мы сделали выбор в пользу Cypress и какие выработали подходы к написанию тестов, а также о запуске тестов на инфраструктуре AWS.
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
Разработчики непрерывно совершенствуют SOLIDWORKS Visualize в направлении удобства использования, быстродействия и качества результатов. В версии Visualize 2021 эта традиция продолжается. Давайте немного углубимся в тему и рассмотрим некоторые отличительные черты новой версии. Не забудьте также ознакомиться с полным описанием улучшений, реализованных в Visualize, здесь: Новые возможности SOLIDWORKS 2021.
Несмотря на то, что у нас так много внутренних и внешних угроз для баз данных, в этом учебнике мы рассмотрим лишь некоторые из них.
База данных — это место для хранения данных. Используется в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.
Введение
Разработка под Siebel имеет свои отличительные черты. В её основе лежит конфигурирование объектов, и автоматизация бизнес процессов c их использованием, как из кубиков, использование справочников особых значений. Возможность написания скриптов присутствует, но не занимает доминирующее положение. Все изменения производятся через IDE Siebel Tools, либо в интерфейсе приложения. Особенностей много, но ничто человеческое Siebel не чуждо, и в том числе проблема переноса изменений с dev контура на другие среды. В этой статье мы хотели бы рассказать о том, как работает наш ci/cd конвейер.
Эта статья является конспектом книги «Принципы юнит-тестирования». Материал статьи посвящен интеграционным тестам.
Юнит-тесты прекрасно справляются с проверкой бизнес-логики, но проверять эту логику «в вакууме» недостаточно. Необходимо проверять, как разные ее части интегрируются друг с другом и внешними системами: базой данных, шиной сообщений и т. д.
В этой статье рассматривается роль интеграционных тестов, когда их следует использовать и когда лучше положиться на классические юнит-тесты. Также затронем эффективное написание интеграционных тестов.
