Я работаю 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. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.
В качестве второй части ретроспективных уроков исследования я бы хотел сконцентрироваться на теме, которая редко обсуждается. Однако, с моей точки зрения, жизненно необходимо расширить свои горизонты в этой области, чтобы улучшить свой исследовательский подход.
Зачастую, когда я спрашиваю студентов, как бы они тестировали приложение, я получаю ответы вроде "Я сравню продукт с документацией или спецификацией". Логичным образом я задаю следующий вопрос – что, если спецификации нет, или продукт еще не создан?
В этой части цикла мы поразмышляем об исследовании артефактов, приносящем пользу тестированию, и разберемся, как построить тест-стратегию, имея или не имея документации, а также о том, как найти в ней баги. Иными словами, мы научимся мыслить вне рамок документации.
Я большой фанат тестирования. Я пишу об этом в блог и почтовую рассылку, я обсуждаю это c другими разработчиками в свободное время, я зашел так далеко, что даже создал обучающий курс по тестированию в Go.
Но несмотря на всю мою любовь к тестированию, я не рекомендую его новичкам.
Звучит дико, правда? В этой статье я собираюсь пояснить свою точку зрения более детально, но весь смысл, в итоге, сводится к двум пунктам:
Начинающим не хватает знаний, чтобы писать что-либо кроме самых простых тестов. Это неизбежно приводит к следующему пункту…
Пытаться тренировать навыки, необходимые для написания реалистичных тестов, одновременно с обучением программированию крайне тяжело
Я понимаю, что это, в принципе, один пункт. В любом случае, я разбил его на два для того, чтобы было проще понять.
Знаю, многие из вас не согласятся со мной, но пожалуйста, прочитайте статью, и, если после прочтения вы останетесь при своем мнении, я буду рад обсудить это с вами. В конце концов, я здесь чтобы учиться
В современном мире Agile с его двухнедельными спринтами и частыми релизами тестированию сложно поспевать за всем. Зачастую мы полностью заняты тестированием юзер-стори текущего спринта и полагаемся на то, что автоматизация возьмет на себя регрессионное тестирование. Однако в тестировании есть ключевой компонент, про который часто забывают – это кросс-браузерное тестирование.
Автор: Энди Найт (Andy Knight)
Автор: Кристин Джеквони (Kristin Jackvony)
Автор: Баз Дийкстра (Bas Dijkstra)
Автор: Виктор Славчев (Viktor Slavchev)
Автор: Кристин Джеквони (Kristin Jackvony)