Друзья, всего 14 дней осталось до конференции TestCon Moscow 2018! Программа уже окончательно сформирована, спикеры во всеоружии. Вас ждут два полных дня докладов, целый день практических мастер-классов, игры, призы и сюрпризы.
А пока доклад Лилии Сапуриной «Разработка автоматизированной системы тестирования «с нуля»: основные проблемы и способы их решения», вызвавший в прошлом году много дискуссий.
В этом докладе автор описывает основные этапы построения автоматизированных систем тестирования. На основании своего опыта работы в крупной компании с установленной непрерывной интеграцией и разработанной практикой по использованию автоматизации Лилия рассказывает, как построить подобную систему в небольших компаниях, где весь процесс необходимо создавать с нуля.
Общий курс по тестированию программного обеспечения Начальный курс по базам данных и SQL Начальный курс по SOAP UI
Время в пути — с 16 апреля до 17 мая (20 вебинаров и 20 заданий) Начало занятий: 11:00 с понедельника по пятницу Конец занятий: 19:00 с понедельника по пятницу
Как мы будем учиться?
Каждый рабочий день один из ведущих специалистов нашей компании будет проводить короткий образовательный вебинар. На нём будет рассказываться тема дня, после чего будет выдаваться практическое задание. Каждое задание потребует не менее 4-6 рабочих часов в день!
Внимание! Участники, не справившиеся с заданием, на следующий день обучения не переводятся! Поэтому записывайся на стажировку только если ты располагаешь достаточным временем.
Внимание-2! Это НЕ курсы, это стажировка с обучением. Если ты не планируешь работать у нас, то не трать свое и наше время. На любом этапе мы можем отказать в продолжении прохождения стажировки.
В рамках прошедшей онлайн-конференции для тестировщиков КоТэ было проведено несколько мастер-классов.
Мы публикуем мастер-класс от Алексея Баранцева, на котором он показал как строить локаторы и рассказал о конкретных приемах и правилах, которыми он руководствуется при построении локаторов, чтобы они получались хорошими.
Сбор грибов - неотъемлемая часть каждой осени в моей жизни. По крайней мере, здесь, в Эстонии, наши корни охотников-собирателей все еще очень прочны. Брести по лесу с корзиной и ножом в руках, наслаждаясь умиротворенностью и спокойствием сосен, один из самых приятных моментов в преддверии мрачной зимы.
Я считаю сбор грибов медиативным процессом, когда часть моего сознания концентрируется на грибах, в то время как другая часть занята размышлением обо всем, что приходит в голову. На этот раз я поймала себя на том, что размышляю о сходстве процессов сбора грибов и тестирования.
И да, такие сходства я нашла. Причина, по которой я захотела написать об этом статью, заключается в том, что эвристики и оракулы - понятия, которые сложно усвоить как начинающим тестировщикам, так и людям, просто интересующимся тестированием. Я провела несколько семинаров и тренингов на эту тему. Поэтому, по меньшей мере, те, кто знаком с процессом сбора грибов или другими пищедобывательными процессами, сравнивая собирательство грибов и охоту за багами, найдут в этих процессах много общего.
Автоматизация тестирования REST API на сегодняшний день является актуальной темой в интеграционном тестировании. В этой статье мы поговорим о программе Postman, применяемой для тестирования REST API, рассмотрим несколько интересных методов написания автотестов и на примере реального проекта API «Яндекс.Словарь» разберем несколько тестов.
Нам понадобится
Для того, чтобы начать тестировать «Яндекс.Словарь», нам понадобится:
Знание основ программирования. Достаточно владеть такими понятиями, как:
Проектируя автоматизированные UI-тесты, за годы работы я затвердил себе, что начинать надо с минимально валидными записями в системе. При таком подходе высвечиваются ложные предположения в различных частях системы, которые вряд ли были бы пойманы юнит-тестами.
Как я уже писал, я стараюсь настраивать тестовые данные для UI-тестов через системное API (даже если API – это чистый SQL, это все равно хорошая практика). В этом случае, когда ваш браузер стартует тест, все данные уже на местах.
К примеру (который большей частью правдив), предположим, что у вас есть запись в системе для Пользователя, и единственное необходимое поле для этой записи – это «Фамилия». Если вы начнете проектировать тесты с записями, где указана только «Фамилия», вы быстро обнаружите, где система предполагает наличие еще и «Имени», «Адреса, «Почты» или «Телефона». Чтобы узнать об этом больше, прочитайте хорошо известную статью "Falsehoods Programmers Believe About Names"
Недавно я столкнулся с особенно интересным подобным случаям, тестируя запись с полем, содержащим пустую строку. Я обнаружил, что часть системы, в которой я должен был иметь возможность удалить запись, не дает мне этого сделать: не хватает того самого поля. Система ожидала, что в этом поле будет текстовая строка, и собиралась произвести split() операцию над определенным символом этой строки, что вернуло бы массив символов, разделенных этим.
Друзья, до конференции TestConMoscow 2018осталось ровно три недели. Кроме тщательного отобранного контента, обещаем много драйва и сюрпризов. Так что приходите!
А пока еще один доклад прошлогодней конференции, привлекший огромное внимание: Вадим Зубович «Жизнь на костылях или Антипаттерны UI автоматизации»
На тему построения «правильной» автоматизации есть сотни докладов, однако, серебряной пули на все случаи жизни не существует и тут у многих начинаются проблемы. «Идеальные» подходы порой неприменимы, тогда в ход идут свои собственные решения, которые приводят к собственным ошибкам.
Именно об этих «ошибках», известных как «как НЕ надо делать» или «антипаттерны» говорится в докладе.
Автор рассматривает как антипаттерны в коде, так и в самом подходе к реализации автоматизации тестирования, с которыми ему доводилось регулярно сталкиваться и которые зачастую тормозили развитие проекта. Надеется, что вместе нам удастся впоследствии избежать этих расхожих неправильных представлений.
22 и 24 апреля Антон Семенченко (учредитель сообщества специалистов в области автоматизации тестирования COMAQA.BY) проведет в Санкт-Петербурге два очных тренинга:
На тренинге вы получите исчерпывающие ответы на наиболее актуальные вопросы построения эффективной, минимизирующей усилия / траты Архитектуры того или иного решения Автоматизации тестирования.
На тренинге вы научитесь выбирать метрики и инструменты работы с ними, внедрять их на проекте, сможете с нуля разработать ROI калькулятор и узнать как эффективно его использовать.
Описание и подробную программу можно посмотреть по ссылкам выше.
При регистрации до 5 апреля действует льготная цена!
Тестировщики, даже будучи членами команды, все равно являются аутсайдерами. Их ценность обусловлена этим статусом, поддерживается, благодаря ему, и все время находится под угрозой из-за него.
На заре времен разработки тестирование считалось незыблемым/неприкосновенным.
Тестировщики были закреплены за отдельными командами, они были изолированными единицами в организационной иерархии для того, чтобы они не попадали под влияние разработчиков. Взгляд тестировщиков на продукт был беспристрастным. Тестируемые системы являлись “черными ящиками”, в которые тестировщики подавали данные на вход и делали выводы о состоянии продукта на основании полученных в результате данных.
И хотя цели таких действий сводились к тому, чтобы оставаться беспристрастными сторонниками качества, с течением времени такая тактика приобрела конфронтационный и бюрократический характер.
С появлением и распространением agile методологий убежденные “отщепенцы” стали понемногу замещаться фидбеком и тестированием пользователей.
Тестирование в рамках традиционных больших команд было заменено на закрепление специалиста по тестированию за небольшой командой разработки.
При написании статьи использовались материалы А.Смирновой, подготовленные в рамках конференции тестировщиков «Котэ»
Тестирование – очень динамичная сфера, которая постоянно развивается; каждый день появляются новые инструменты, материалы и подходы. Тестировщик – это «универсальный солдат», зачастую объединяющий в себе различные навыки: написание кода, управление ресурсами, владение основами дизайна и верстки, а также знания в более узких прикладных областях. Руководители проектных команд стараются повышать квалификацию своих ребят, отправляя их на всевозможные курсы и тренинги. Но как быть со стажерами, с «проектными новобранцами»? Как правильно, а главное, чему именно нужно научить стажеров (особенно в распределенной команде), чтобы у них не пропал интерес к профессии, и чтобы это обучение принесло пользу не только «новобранцу», но и всему проекту? Об этом мы и расскажем в нашей статье.
Как выбрать инструмент в экосистеме, которая генерирует фреймворки быстрее, чем плодится зерг, и убивает их с энтузиазмом Дарвина на амфетаминах?
JavaScript, возможно, неоптимален для многих команд, но для большей части нашей отрасли он неизбежное зло. StackOverflow оценивает его как наиболее популярный язык программирования в течение последних пяти лет. Лет десять назад тестирование компонентов JavaScript шло сбоку-припеку и отдавалось на ручное тестирование. Сегодня это уже не побочная платформа, крутящая веб-виджеты, а ключевая часть потока бизнес-операций. Это означает, что большинству команд нужно очень серьезно подходить к вопросу тестирования JavaScript.
Недавно я проводил опрос с целью узнать о предпочтениях и опыте разработчиков в разрезе JavaScript-тестирования. Типичная для всей экосистемы тирания выбора была довольно очевидной. Я получил 683 ответа, и оказалось, что люди пользуются более чем 50 фреймворками тест-автоматизации. При такой сборной солянке ни у кого нет времени на детальное исследование всех вариантов. Однако широта выбора также вызывает вопрос, нет ли в природе чего-то лучшего, нежели то, что мы сейчас используем. Как же выбрать правильные инструменты для так часто меняющегося фреймворка?
