Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout
После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Автор: Маарет Пюхяярве (MaaretPyhäjärvi) Оригинал статьи Перевод: Ольга Алифанова
Хорошее исследовательское тестирование балансирует наш выбор того, что делать сейчас – поэтому, когда время вышло, мы уверены, что сделали наилучшую из возможных работу в заданных временных рамках, и способны рассказать об идеях и рисках, которые мы не покрыли. Для баланса выбора нам надо знать, какие варианты у нас есть, и недавно я заметила, что количество вариантов, из которого выбирают некоторые тестировщики, ограничено. Многое из того, что мы сейчас называем тест-дизайном – это припоминание информации с целью сделать информированный выбор. Как говорится:
"Если единственный известный вам инструмент – это молоток, все становится похожим на гвоздь".
Когда-то в прошлом году команда LearnQA обещала организовать вебинар по какой-нибудь CI-системе. И вот, это случилось - вебинар по запуску автотестов в TeamCity.
На вебинаре ведущие вебинара:
✔️ Научат запускать TeamCity и агенты, настраивать проекты и билды
✔️ Запустят Selenium-тесты на Java и TestNG в Docker-контейнере с подготовкой Allure-отчетов
✔️ Запустят API-тесты на Python и requests с предварительной подготовкой бэкенда в зависимом билде
✔️ Покажут как разобраться с настройкой триггеров, интеграицей с GitHub и запуском тестов на Pull Request
Для вебинара специально было выбрано два стека для автотестов, чтобы рассказать как можно больше интересного.
Вебинар будет вести Виталий Котов, основатель LearnQA и Александр Измайлов - Head Of RE.
Для кого этот вебинар:
✔️ для начинающих автоматизаторов и тех, кто уже задумывается о выстраивании пайплайнов в своей компании
✔️ для тех, кто хочет знать как запускать любые автотесты в популярной CI-системе
✔️ для тех, кто хочет увереннее себя чувствовать в настройке Docker-контейнеров и отчетов Allure
✔️ для тех, кому хочется закинуть крутой пример в свое портфолио
Вебинар состоится в среду, 24 марта с 20:00 до 22:00 по Москве.
Каждый участник вебинара получит видеозапись, индивидуальный доступ на TeamCity и в репозитории с тестами.
За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании?
Автор: Ян Бин (Iain Bean) Оригинал статьи Перевод: Ольга Алифанова
Выявление (и исправление) проблем доступности – важная часть навыков любого фронтэнд-разработчика, но зачастую сложно отделить полезные инструменты и техники от менее полезных. К тому же существует множество ложных представлений, поэтому я решил написать статью о тех инструментах и техниках, которыми пользуюсь сам, тестируя веб-доступность. Дабы извлечь из статьи максимум пользы, проделайте все это самостоятельно.
Начнем с начала: выберите сайт для тестирования. Если у вас есть свой сайт, или сайт вашей компании – можете использовать их, а если вы ищете что-то совсем ужасное – множество примеров можно найти на Awwwards и Product Hunt.
С 6 по 9
апреля в онлайне пройдет большая конференция по тестированию Heisenbug 2021
Piter. Опытные QA-эксперты со всего мира выступят с несколькими десятками
воркшопов и докладов обо всех аспектах тестирования: инструментах, методиках,
лучших практиках, функциональном, нагрузочном, визуальном тестировании и многом
другом.
Примеры
докладов:
— Павел
Финкельштейн и Ксения Томак, Тестирование в дата инжиниринге. Павел работает над Big
Data Tools в JetBrains, а Ксения — техлид Data Engineering в Dodo, поэтому
хорошо знают тему.
— Мануэль Риггер и Илья Яцишин, Using SQLancer to test ClickHouse and other database systems.
Мануэль и Илья лично отловили с помощью SQLancer 450 ранее неизвестных багов
в SQLite, MySQL, PostgreSQL и ClickHouse, и в докладе познакомят аудиторию
с ним на примере работы с ClickHouse.
И все
это в 4К, с возможностью ставить на паузу или менять скорость воспроизведения и
даже игровым режимом платформы, который имитирует реальную площадку.
Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полноту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...
Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Эта статья — как чек-лист, «что еще нужно найти и проверить».
Итак, давайте посмотрим, какая бывает документация:
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
По моему опыту, от работы с регулярными выражениями у всех болит голова. Никто не хочет разглядывать ^(19|20)\d\d[- /.](0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])$ и выяснять, что это значит!
Несмотря на это, регулярные выражения – мощный инструмент, и неплохо бы знать, как им пользоваться, даже если вы (как и большинство) не эксперт в этом вопросе. Эта статья – очень мягкое введение в регулярные выражения. Встретившись с ними в тестировании, вы будете чувствовать себя более уверенно.
Прежде всего, Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.
Затронутые области требуют большего внимания во время проведения регрессионного тестирования.
Отмечу сразу, чтобы не пугать QA: импакт анализ не есть "чтение кода". Он включает в себя и иные способы исследования.
