Друзья, тем, кто планирует зарегистрироваться на вторую Международную конференцию TestCon Moscow 2018, которая пройдет 18-19 апреля, напоминаем, что до ее начала осталось всего неделя!
Уже полностью сформирована программа конференции. Более 30 спикеров мировой величины, из таких компаний, как RED HAT, VOLVO Group, CAPGEMINI, CloudBees и многих других поделятся с вами самыми горячими новостями. Докладов ожидается такое множество, что вместо привычного одного дня конференции, на этот раз мы предлагаем вам целых два!
ВАЖНЫЙ МОМЕНТ! На конференции будет предоставлен синхронный перевод докладов.
Напоминаем, что по сложившейся многолетней традиции, накануне конференции (17 апреля) мы проводим практические мастер-классы. На этот раз выбрать вы сможете из пяти разных тем:
Структурированное исследовательское тестирование
От TDD до ATDD
Agile тестировщик
Тестирование usability
Приемочное тестирование
TestCon Moscow 2018 это:
1 день мастер-классов – 17 апреля
2 дня конференции – 18 и 19 апреля
3 параллельных трэка каждый день
Более 30 спикеров
400+ участников
5 мастер-классов
Синхронный перевод докладов
Торопитесь, до конференции осталось всего неделя! Не оставайтесь в стороне!
Переход к модели непрерывной поставки ПО повлиял на растущую популярность автоматического тестирования. DevOps тоже голосуют за слом барьеров между традиционными ролями. Тестировщики, умеющие программировать (на самом деле этим автоматизаторы и являются) очень здорово встраиваются в эту новую парадигму.
Автоматизация тестирования предлагает множество потенциальных выгод, включая повышенную эффективность и предоставление работоспособного метода решения сложных задач тестирования. Автоматизирование тестов также дает повышенную систематичность, позволяя более эффективно использовать ресурсы в период провала нагрузки. Однако автоматизация – не панацея. Дабы осознать потенциал автоматизации, нужно быть в курсе трех распространенных ошибок автоматизации тестирования.
В одной команде, да и в целой компании невозможно найти сотрудников с абсолютно идентичными знаниями. Кто-то знает больше, кто-то меньше; одни больше понимают в исследовательском и скриптовом тестировании, а другие мастерски владеют навыками тест-дизайна и умением грамотно разработать тест-кейсы. Практически каждый сотрудник чего-нибудь не знает, каждый желает подтянуть свои знания, но, к сожалению, не имеет времени на обучение вне работы. В своей статье я хочу на примере нашей распределенной команды рассказать о том, как можно постепенно прокачивать навыки, затрачивая минимум усилий.
Про неформальное общение
Для начала мне хочется указать на одну очень простую вещь – на общение. Ваша команда должна общаться между собой не только по рабочим вопросам, но и «обо всем на свете». Неформальное общение расслабляет человека и увеличивает шанс того, что при возникновении вопросов или проблем он придет к своим коллегам и попросит совета. А это своего рода прокачка
Я начала работу в «Лаборатории качества» совсем зеленым тестировщиком, имея за плечами теоретические знания и лишь немного практики. Конечно, в голове постоянно крутились вопросы «а как правильно?» и «а как лучше?». И вот мой первый проект, первый дефект… первая паника («как лучше описать дефект в баг-трекере?»). После написания черновика мне очень хотелось проконсультироваться с кем-то более опытным и понять, все ли хорошо, и не вернут ли мне разработчики мой дефект с грозными замечаниями. Как вы помните, мы говорим о распределенной команде, в которой все общение происходило в скайпе. Я зашла в наш проектный чат и поняла, что вопросы есть не у меня одной, а более опытные коллеги спокойно отвечают и дают советы. В ответ на свой вопрос я получила ответ и рекомендации, и это уже была пусть и небольшая, но прокачка моих навыков.
Друзья, всего 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() операцию над определенным символом этой строки, что вернуло бы массив символов, разделенных этим.
