Меня зовут Елена Расторгуева, я отвечаю за продукт «Фактор» в HFLabs. «Фактор» — чертовски сложный алгоритмический enterprise, он обрабатывает данные в промышленных масштабах.
В статье я расскажу, как мы начинали тестировать «Фактор», как развивали автотесты и почему пришли к самописным фреймворкам.
Читать полностью »
Добрый день, уважаемые читатели. Меня зовут Виктор Буров, я разработчик в ISPsystem. В прошлом посте я рассказывал об инструменте для создания автотестов, сегодня поделюсь опытом автоматизации тестирования безопасности.
Сначала уязвимости в продуктах у нас искал отдельный сотрудник. Ручное тестирование занимало много времени и не гарантировало, что будут найдены все уязвимости. Выяснив основные закономерности тестирования, мы пришли к выводу, что его можно автоматизировать. Тогда мы решили написать утилиту, которая облегчит жизнь тестировщика, сэкономит его время и позволит проверять продукты после каждого изменения. Так как тестировщика звали Лида, новое приложение мы назвали в её честь. Вообще, у нас в компании это стало традицией — называть инструменты тестирования именами тестировщиц.
Читать полностью »
Добрый день, уважаемые читатели. Меня зовут Виктор Буров. Я работаю разработчиком в компании ISPsystem и хочу поделиться опытом автоматизации тестирования.
Так сложилось, что у нас превалировало ручное тестирование, и тестировщики тратили кучу времени на выполнение одних и тех же действий. Однажды мы подумали: почему бы не научить панель повторять действия тестировщика, ведь, по сути, все они превращаются в конкретные вызовы API. Это бы позволило писать тесты людям даже без навыков программирования.
Мы решили написать модуль создания автоматических тестов. Чтобы тестировщик мог просто нажать кнопку создания теста, выполнить условия тест-кейса и по окончании нажать «завершить» — и всё, тест был готов! Простая идея, но реализовать ее оказалось непросто. Потому что мы хотели, чтобы этот модуль был максимально адаптирован под наши продукты и использовал преимущество унифицированного интерфейса: чтобы сделанная запись выглядела как готовый тест-кейс. Это бы полностью избавило от ручной работы по написанию тестов. Получившаяся в итоге система получила название «магнитофон».
Читать полностью »
Автор этой лекции — Константин Заикин, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.
— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.
В прошлой статье мы рассказали о созданной нами системе под названием ULA (Unified Logfile Analyser) — анализаторе, основными функциями которого являются сбор и агрегация входящих сообщений об ошибках c использованием алгоритма shingles, принятие решений по ним и автоматическая нотификация при проблемах с тестовой средой. Сегодня мы поделимся практикой обнаружения/решения багов раскатки этой системы и нашими планами.
Привет!
Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.
Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.
(http://bp-la.ru/bespilotnyj-apparat-danem)
Билд => Тест => Не пройден => и километры логов, разбросанных по разным системам, и десятки минут сведения концов с концами в поисках причины сбоя. Знакомо?
А если иначе?
Билд => Тест => Не пройден => Тикет в JIRA — и разработчик берет баг в работу, потому как вся информация у него уже есть.
Работая в команде Acronis Kernel, я задался целью создать именно такой автотест.
Под катом — моя история.
