Приглашаем отметить День тестировщика с Командой ВКонтакте. 9 сентября мы проведём новый онлайн-митап VK Tech Talks · QA.
Присоединиться можно с 18:00 по московскому времени: в нашем сообществе VK будет прямая трансляция (с записью эфира).
Утки в Облаках — QuAck SaaS
2 мин
В прошлых статьях я рассказывал о системе управления тесткейсами - QuAck - и сопутствующими подсистемами автоматизации и выполнения тестов, репортинга и ускорения UI-тестирования.
Изначально QuAck задумывался как open-source проект - доступный бесплатно для всех желающих.
Тем не менее, далеко не все компании готовы брать на себя бремя содержать и обслуживать сервис на своей стороне. Если это про вас, то у меня для вас - хорошие новости! QuAck теперь доступен в виде SaaS веб сервиса. Да, да, вы теперь можете просто перейти на cloud.testquack.com и начать пользоваться системой.
Давайте посмотрим - как это работает.
Митап QAчественное общение #6: отказ от рутины, тестирование по учебнику на практике, и автотесты
2 мин
24 мая в 19.00 проведём шестой митап для тестировщиков QAчественное общение.
На повестке — три доклада от спикеров из AliExpress Russia, Ozon и Альфа-Банк. Поговорим про то, как отказаться от рутины ручного написания моделей, внедрить автотесты REST API с json-schema на проекте с нуля и без опыта и как «идеальные» процессы тестирования из учебников адаптировать к реальности. Каждой теме — полчаса времени, после — время для вопросов.
Приглашаем на четвёртый митап X5 Tech по тестированию
2 мин
Всем привет! 15 февраля мы собираемся на четвёртый митап X5 Tech по тестированию. В этот раз поговорим об автоматизированных E2E тестах, динамических стендах и автоматической генерации отчётов по нагрузочному тестированию.
Делимся материалами с четвёртого митапа X5 Tech по тестированию
1 мин
На прошлой неделе прошёл наш первый митап в этом году – X5 Meetup #4 по тестированию. На нём мы обсудили автоматизированные E2E тесты, динамические стенды и автоматизацию отчётов нагрузочного тестирования. Здесь делимся презентациями спикеров и ссылкой на трансляцию.
Автоматизация тестирования: «беспилотник» Acronis Kernel
6 мин
Recovery mode
(http://bp-la.ru/bespilotnyj-apparat-danem)
Билд => Тест => Не пройден => и километры логов, разбросанных по разным системам, и десятки минут сведения концов с концами в поисках причины сбоя. Знакомо?
А если иначе?
Билд => Тест => Не пройден => Тикет в JIRA — и разработчик берет баг в работу, потому как вся информация у него уже есть.
Работая в команде Acronis Kernel, я задался целью создать именно такой автотест.
Под катом — моя история.
Selenium для всех: как мы учим QA-инженеров работать с автотестами
9 мин
Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.
Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.
Не трогайте логи руками. Часть 2: как мы внедряли Unified Logfile Analyser
7 мин
В прошлой статье мы рассказали о созданной нами системе под названием ULA (Unified Logfile Analyser) — анализаторе, основными функциями которого являются сбор и агрегация входящих сообщений об ошибках c использованием алгоритма shingles, принятие решений по ним и автоматическая нотификация при проблемах с тестовой средой. Сегодня мы поделимся практикой обнаружения/решения багов раскатки этой системы и нашими планами.
Как мы контролируем качество кода в Браузере для Android. Лекция Яндекса
11 мин
Автор этой лекции — Константин Заикин kzaikin, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.
— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.
— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.
Магнитофон — инструмент для записи автотестов
7 мин
Добрый день, уважаемые читатели. Меня зовут Виктор Буров. Я работаю разработчиком в компании ISPsystem и хочу поделиться опытом автоматизации тестирования.
Так сложилось, что у нас превалировало ручное тестирование, и тестировщики тратили кучу времени на выполнение одних и тех же действий. Однажды мы подумали: почему бы не научить панель повторять действия тестировщика, ведь, по сути, все они превращаются в конкретные вызовы API. Это бы позволило писать тесты людям даже без навыков программирования.
Мы решили написать модуль создания автоматических тестов. Чтобы тестировщик мог просто нажать кнопку создания теста, выполнить условия тест-кейса, по окончании нажать «завершить» — и всё, тест был готов! Простая идея, но реализовать ее оказалось непросто. Потому что мы хотели, чтобы этот модуль был максимально адаптирован под наши продукты и использовал преимущество унифицированного интерфейса: чтобы сделанная запись выглядела как готовый тест-кейс. Это бы полностью избавило от ручной работы по написанию тестов. Получившаяся в итоге система получила название «магнитофон».
Бдительная «Лида»: автоматизация тестирования безопасности
6 мин
Добрый день, уважаемые читатели. Меня зовут Виктор Буров, я разработчик в ISPsystem. В прошлом посте я рассказывал об инструменте для создания автотестов, сегодня поделюсь опытом автоматизации тестирования безопасности.
Сначала уязвимости в продуктах у нас искал отдельный сотрудник. Ручное тестирование занимало много времени и не гарантировало, что будут найдены все уязвимости. Выяснив основные закономерности тестирования, мы пришли к выводу, что его можно автоматизировать. Тогда мы решили написать утилиту, которая облегчит жизнь тестировщика, сэкономит его время и позволит проверять продукты после каждого изменения. Так как тестировщика звали Лида, новое приложение мы назвали в её честь. Вообще, у нас в компании это стало традицией — называть инструменты тестирования именами тестировщиц.
Сначала уязвимости в продуктах у нас искал отдельный сотрудник. Ручное тестирование занимало много времени и не гарантировало, что будут найдены все уязвимости. Выяснив основные закономерности тестирования, мы пришли к выводу, что его можно автоматизировать. Тогда мы решили написать утилиту, которая облегчит жизнь тестировщика, сэкономит его время и позволит проверять продукты после каждого изменения. Так как тестировщика звали Лида, новое приложение мы назвали в её честь. Вообще, у нас в компании это стало традицией — называть инструменты тестирования именами тестировщиц.
Все ругают самописные тестовые фреймворки. А мы своим довольны
6 мин
Меня зовут Елена Расторгуева, я отвечаю за продукт «Фактор» в HFLabs. «Фактор» — чертовски сложный алгоритмический enterprise, он обрабатывает данные в промышленных масштабах.
В статье я расскажу, как мы начинали тестировать «Фактор», как развивали автотесты и почему пришли к самописным фреймворкам.
Монолит для сотен версий клиентов: как мы пишем и поддерживаем тесты
15 мин
Всем привет!
Я бэкенд-разработчик в серверной команде Badoo. На прошлогодней конференции HighLoad я выступал с докладом, текстовым вариантом которого и хочу поделиться с вами. Этот пост будет наиболее полезен тем, кто самостоятельно пишет тесты для бэкенда и испытывает проблемы с тестированием legacy-кода, а также тем, кто хочет тестировать сложную бизнес-логику.
О чём пойдёт речь? Сначала я коротко расскажу о нашем процессе разработки и о том, как он влияет на нашу потребность в тестах и желание эти тесты писать. Затем мы пройдёмся снизу вверх по пирамиде автоматизации тестирования, обсудим используемые нами виды тестов, поговорим об инструментах внутри каждого из них и о том, какие проблемы мы решаем с их помощью. В конце рассмотрим, как поддерживать и запускать всё это добро.
Видео с Badoo PHP Meetup #2: о тестах и качестве кода
2 мин
16 марта мы собрали вторую встречу PHP-сообщества в офисе Badoo. По правде говоря, получилась целая мини-конференция — так много участников было в этот раз.
Обсуждали вопросы автотестов для PHP-разработчиков, разбирали реальные кейсы из практики, дискутировали о качестве кода и много общались. Спасибо участникам и спикерам за полезную субботу!
Под катом — слайды, записи докладов и панельная дискуссия со спикерами из Badoo, EPAM, Avito и Lamoda.
IBM System i (aka AS/400) — Как мы делали автотесты приложений зеленого экрана
14 мин
Привет! Меня зовут Антон Воробьев, я отвечаю в Альфа-Банке за разработку приложений для централизованной банковской системы.
В этом посте я расскажу вам о том, что такое приложения зеленого экрана, зачем они нужны и как мы делали для них автотесты, написав для этого собственное решение, которое позволило нам ускорить автотесты в 11 раз.
Платформа AS/400 (Application System/400) появилась на свет в 1988 году. Первой ОС для данной платформы является OS/400, позже переименованная в i5/OS и еще позже в IBM i. Не так давно она отметила свое тридцатилетие.
Погружаясь в мир разработки под операционной системой IBM i, понимаешь, что это никакой на самом деле не «legacy» в классическом понимании этого слова. Это другая, совершенно иная среда, которая мало схожа с привычными Windows или Unix-системами. Главная задача этой ОС — быть максимально производительной на аппаратуре, с которой работает, а не быть удобной пользователю.
ИМХО, эта ОС может свести с ума от того, насколько привычные подходы к написанию кода на С++ неэффективны на ней (до десятков раз потери CPU), что некоторые демонстрируемые в учебниках антипаттерны являются best-practice эффективного кода, а исходники с датой написания за 1978 год не просто собираются без проблем, но и работают как было спроектировано! Все это заставляет по-новому взглянуть на современные подходы к разработке ПО.
В этом посте я расскажу вам о том, что такое приложения зеленого экрана, зачем они нужны и как мы делали для них автотесты, написав для этого собственное решение, которое позволило нам ускорить автотесты в 11 раз.
Платформа AS/400 (Application System/400) появилась на свет в 1988 году. Первой ОС для данной платформы является OS/400, позже переименованная в i5/OS и еще позже в IBM i. Не так давно она отметила свое тридцатилетие.
Погружаясь в мир разработки под операционной системой IBM i, понимаешь, что это никакой на самом деле не «legacy» в классическом понимании этого слова. Это другая, совершенно иная среда, которая мало схожа с привычными Windows или Unix-системами. Главная задача этой ОС — быть максимально производительной на аппаратуре, с которой работает, а не быть удобной пользователю.
ИМХО, эта ОС может свести с ума от того, насколько привычные подходы к написанию кода на С++ неэффективны на ней (до десятков раз потери CPU), что некоторые демонстрируемые в учебниках антипаттерны являются best-practice эффективного кода, а исходники с датой написания за 1978 год не просто собираются без проблем, но и работают как было спроектировано! Все это заставляет по-новому взглянуть на современные подходы к разработке ПО.
Москва, 18 апреля — QIWI SERVER PARTY 4.0
2 мин
18 апреля, в четверг, мы снова собираем митап QIWI SERVER PARTY.
На митапе подробно обсудим не только технические вопросы, но и поговорим о том, нужны ли хорошим программистам soft skills, на каких ошибках мы научились, обучая стажеров, и нужен ли сотруднику ментор, или достаточно менеджера.
Подробнее о докладах — под катом.
На митапе подробно обсудим не только технические вопросы, но и поговорим о том, нужны ли хорошим программистам soft skills, на каких ошибках мы научились, обучая стажеров, и нужен ли сотруднику ментор, или достаточно менеджера.
О чем поговорим:
- Зачем разработчику писать автотесты;
- Метрики: как перестать бояться и начать понимать свою систему;
- Soft skills и работа в команде;
- Техническая устойчивость продукта при совместном владении кода;
- Почему не обязательно ограничивать себя рамками одной технологии или языка программирования;
- Менторство и обучение стажеров — как не надо делать.
Подробнее о докладах — под катом.
Создание инструмента для быстрого и эффективного написания автотестов на Selenium
26 мин
Фундаментальный строительный блок автоматизации – тестирование
Род Джонсон
Я не амбассадор автоматизации тестирования веб интерфейсов, однако сей очерк скорее будет полезен камрадам, уже имеющим опыт в этой сфере.
Для совсем новичков также будет полезно, т.к. я предоставляю исходный код, где можно посмотреть, как в конечном продукте организовано взаимодействие с селениумом.
Я расскажу о том, как с нуля, имея небольшой опыт разработки, написал платформу для запуска тестов, и о самой платформе. Сам я считаю, что мой продукт получился весьма эффективным, а значит будет многим полезен и имеет место для рассмотрения.
Автоматизируй это! Как мы улучшали интеграционное тестирование
8 мин
В давние времена у нас было всего несколько сервисов, и выложить за сутки обновление более чем одного из них на production — было большой удачей работой. Потом мир ускорился, система усложнилась, а мы трансформировались в организацию с микросервисной архитектурой. Теперь у нас около сотни сервисов, и вместе с ростом их числа увеличивается и частота релизов — их более 250 в неделю.
И если новые фичи тестируют внутри продуктовых команд, то задача команды интеграционного тестирования — проверить, что изменения, включенные в релиз, не ломают функциональность компонента, системы и других фич.
Я работаю инженером по автоматизации тестирования в Яндекс.Деньгах.
В этой статье расскажу про эволюцию интеграционного тестирования web-сервисов, а также про адаптацию процесса к увеличению числа компонентов системы и повышению частоты релизов.
И если новые фичи тестируют внутри продуктовых команд, то задача команды интеграционного тестирования — проверить, что изменения, включенные в релиз, не ломают функциональность компонента, системы и других фич.
Я работаю инженером по автоматизации тестирования в Яндекс.Деньгах.
В этой статье расскажу про эволюцию интеграционного тестирования web-сервисов, а также про адаптацию процесса к увеличению числа компонентов системы и повышению частоты релизов.
Unit-тесты в СУБД — как мы делаем это в Спортмастере, часть первая
8 мин
Привет, Хабр!
Меня зовут Максим Пономаренко и я — разработчик в Спортмастере. Имею 10-летний опыт работы в IT-сфере. Начинал карьеру в в области ручного тестирования, затем переключился на разработку баз данных. Последние 4 года, аккумулируя знания, полученные в тестировании и разработке, занимаюсь автоматизацией тестирования на уровне СУБД.
В команде Спортмастера я состою чуть более года и на одном из крупных проектов занимаюсь разработкой автоматизированного тестирования. В апреле мы с ребятами из Sportmaster Lab выступали на конференции в Краснодаре, мой доклад назывался «Unit-тесты в СУБД», и сейчас хочу поделиться им с вами. Текста будет много, поэтому я решил разбить доклад на два поста. В первом мы поговорим об автотестах и тестировании в общем, а во втором я подробнее остановлюсь на нашей системе unit-тестирования и результатах ее применения.
Вначале немного скучной теории. Что такое автоматическое тестирование? Это тестирование, которое проводится программными средствами, и в современном IT оно все чаще и чаще используется при разработке ПО. Связано это с тем, что компании растут, растут их информационные системы и соответственно растет и количество функционала, которое надо тестировать. Проводить ручное тестирование становится всё накладнее и накладнее.
Меня зовут Максим Пономаренко и я — разработчик в Спортмастере. Имею 10-летний опыт работы в IT-сфере. Начинал карьеру в в области ручного тестирования, затем переключился на разработку баз данных. Последние 4 года, аккумулируя знания, полученные в тестировании и разработке, занимаюсь автоматизацией тестирования на уровне СУБД.
В команде Спортмастера я состою чуть более года и на одном из крупных проектов занимаюсь разработкой автоматизированного тестирования. В апреле мы с ребятами из Sportmaster Lab выступали на конференции в Краснодаре, мой доклад назывался «Unit-тесты в СУБД», и сейчас хочу поделиться им с вами. Текста будет много, поэтому я решил разбить доклад на два поста. В первом мы поговорим об автотестах и тестировании в общем, а во втором я подробнее остановлюсь на нашей системе unit-тестирования и результатах ее применения.
Вначале немного скучной теории. Что такое автоматическое тестирование? Это тестирование, которое проводится программными средствами, и в современном IT оно все чаще и чаще используется при разработке ПО. Связано это с тем, что компании растут, растут их информационные системы и соответственно растет и количество функционала, которое надо тестировать. Проводить ручное тестирование становится всё накладнее и накладнее.
Unit-тесты в СУБД — как мы делаем это в Спортмастере, часть вторая
7 мин
Первая часть — здесь.
Представьте ситуацию. Перед вами стоит задача разработки нового функционала. У вас есть наработки от ваших предшественников. Если предположить, что вы никаких моральных обязательств не имеете, то как бы вы поступили?
Чаще всего все старые наработки подвергаются забвению и всё начинается сначала. В чужом коде копаться никто не любит, а при наличии времени почему бы не заняться созданием собственной системы? Это типичный подход, и он во многом правильный. Но в своём проекте мы поступили не так. В основу будущей системы автоматического тестирования мы заложили наработки по unit-тестам на utPLSQL от предшественников, а затем пошли работать в нескольких параллельных направлениях.
Представьте ситуацию. Перед вами стоит задача разработки нового функционала. У вас есть наработки от ваших предшественников. Если предположить, что вы никаких моральных обязательств не имеете, то как бы вы поступили?
Чаще всего все старые наработки подвергаются забвению и всё начинается сначала. В чужом коде копаться никто не любит, а при наличии времени почему бы не заняться созданием собственной системы? Это типичный подход, и он во многом правильный. Но в своём проекте мы поступили не так. В основу будущей системы автоматического тестирования мы заложили наработки по unit-тестам на utPLSQL от предшественников, а затем пошли работать в нескольких параллельных направлениях.