Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Недавно на моем тренинге тестировщица никак не могла разобраться в одном вопросе. Вот о чем она спросила:
Почему некоторые технические руководители (к примеру, руководитель технического отдела, менеджеры разработки, тест-менеджеры и тест-лиды) сразу бросаются к тест-кейсам, если хотят обеспечить отслеживаемость, поделиться усилиями тестирования с заказчиками, и передать знания о фичах тестировщикам?
Не могу сходу ответить. Боюсь, что по большей части фиксация на тест-кейсах проистекает от невежества. Многие просто не знают другого способа думать о тестировании, и даже не пытались пробовать. К сожалению, это правдиво не только в отношении руководителей, но и в отношении тестировщиков. Большая часть тестирования как бизнеса опирается на костыли мифов, фольклора и инерции.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Допустим, вы отвечаете за изначальную подготовку набора автотестов в вашей команде. Используя ваш основной компьютер, вы создали все сценарии, тщательно их протестировали, и теперь они готовы к использованию. Они основаны на существующем смоук-наборе тестов, и вы планируете запускать их при каждом деплое – теперь этим не нужно заниматься тест-команде. Автоматизация имеет бешеный успех и бережет кучу времени тестировщика еженедельно! Вы планируете заслуженный отпуск – всего на недельку.
Вся теория тестирования и 40 часов практики с экспертами QA:
★ Для тех, кто осваивает новую специальность
Получите все нужные знания, чтобы начать работать джуниор-тестировщиком в федеральной или международной компании.
★ Для тестировщиков с опытом 1-2 года
Приведете знания в систему, научитесь тратить на работу в 2 раза меньше времени, получите новый уровень кейсов, чтобы усилить ваше резюме на милд-позиции.
Мы ценим наших учеников и хотим стать полезнее шпината) Поэтому мы делаем наш курс полезнее, удобнее и понятнее с каждым запуском.
Читайте о том, как отзывы и пожелания наших участников помогали нам делать курс лучше и сильнее с каждым потоком. Для тех, кто дочитает до конца, сюрприз!
Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).
Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.
Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Python – изумительный язык программирования. Как сказал Дэн Каллаэн (Dan Callahan) в своем докладе на PyCon 2018, "Пайтон занимает второе место в списке лучших языков, подходящих для чего угодно, и это чудесно". Однако я убежден, что если рассматривать тест-автоматизацию, то Python – один из наилучших языков для нее. Ниже – десять причин, почему я так думаю.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Я твердо убеждена, что вне зависимости от достоинств виртуальных устройств и автоматических тестов нужно всегда проводить тестирование на реальном физическом устройстве. Однако никто из нас не может позволить себе приобрести все возможные устройства и подключить всех возможных операторов. Поэтому сегодня мы обсудим, как собрать портфолио мобильных устройств, отвечающих минимальным тест-критериям, и как провести тестирование на других физических устройствах. Мы также поговорим о ручных проверках, которые должны быть неотъемлемой частью любого мобильного тест-плана.
JUnit - это библиотека на языке программирования Java, предназначенная для разработки и запуска автоматизированных тестов. Изначально разрабатывалась для unit-тестирования, однако позже стала использоваться для других типов тестов - функциональных, API-тестов и UI-тестов.
В эту библиотеку входят такие модули, как junit.framework.Assert, предназначенный для верификации каких-либо данных или состояний теста и junit.framework.TestCase, предназначенный для выделения самого теста в отдельную сущность, имеющую прекондишены (описанные с тегов @Before) и посткондишены (описанные тегом @After).
О том, как начать работать с JUnit мы рассказываем в этом видео:
Это и другие видео вы можете увидеть на нашем youtube-канале. Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Selenium против Katalon Studio – узнайте, как упростить Selenium-тесты при помощи Katalon Studio (на примере тест-кейса авторизации в обоих инструментах).
Автоматизированное тестирование – это техника, в которой одно приложение проводит тестирование другого приложения.
Автоматизированное тестирование – очень ценная в мире Web-проектов практика. Автоматизация широко в них применяется, так как позволяет выгодно проводить UI-тестирование, критически важное для обеспечения высококачественного сервиса.
Selenium – один из наиболее популярных инструментов Web-автоматизации с открытым исходным кодом. При помощи Selenium можно сделать очень многое – например, провести рефакторинг веб-элементов в классы, которые легко вновь и вновь использовать в тест-кейсах.
Однако для новичков в автоматизации эти хитрые задачи могут не соответствовать тест-потребностям. Скорее всего, вы еще не хотите морочить себе голову такими сложностями, и хотите сразу приступить к созданию тестов и по ходу дела изучить принципы тест-дизайна.
Эта статья – введение в автоматизированное тестирование.
Сначала мы займемся автоматизацией кейса авторизации при помощи Selenium – фреймворка на основе Web. Затем мы научимся делать то же самое, но с меньшими усилиями, используя Katalon Studio.
Примечание: согласно моим наблюдениям, скриптованное выполнение тестов и тип регрессионных скриптов, о котором я говорю в статье, медленно отходят на второй план, однако многие организации все еще их используют. Не у всякой организации есть банда тестировщиков, работающих исследовательским методом с учетом контекста, и применяющих CI/CD, с релизами несколько раз в день. Если вы работаете в таком коллективе – отлично, эта статья, вероятно, не для вас. Но держите в уме, что многие компании все еще применяют традиционный подход к тестированию.
Последнее время я часто рассказывал о своих (неоднократных!) провалах на моем карьерном пути. К примеру, мой доклад на румынской тест-конференции начался с моего признания, что ретроспективно очень много проделанной мной до недавнего времени работы было в лучшем случае неэффективно – а в прочих случаях бессмысленно. Сейчас я медленно начинаю осознавать, что же такое автоматизация на самом деле, и как применять ее с большей пользой и эффективностью, не просто бросая в ее топку все больше и больше инструментов – эту точку зрения я поддерживал довольно долго.
Сегодня я хочу рассказать об еще одном примере деятельности, которую мне стоило бы осуществлять куда лучше.
Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.
