С 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: импакт анализ не есть "чтение кода". Он включает в себя и иные способы исследования.
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это третья часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.
В этой статье я отвечу на вопрос "Когда должно начинаться тестирование?" (и связанный с ним вопрос "Когда тестировать?").
Приглашаем Вас посетить Международную конференцию по вопросам качества программного обеспечения – SQA Days-28.
Конференция будет проходить в три потока. Предусмотрены оффлайн и онлайн форматы. В рамках мероприятия представлены доклады на общие и узкопрофессиональные темы. Но даже если вы не будете успевать увидеть все сами - после конференции все доклады станут доступны в записи.
Также мы повторим формат BarCamp - свободный обмен знаниями, где каждый может подготовить доклад на свою любимую тему.
Узнать больше, зарегистрироваться и приобрести билет можно на сайте конференции: https://www.sqadays.com/.
Чтобы оценить уникальную атмосферу конференции, посмотрите видеофильм о том, как проходила предыдущая SQA Days.
SQA Days-28 – территория качества!
________________________________________________
Организаторы конференции - компания «Лаборатория тестирования» - ежегодно проводят целый ряд ИТ-конференций и тренингов для специалистов в области тестирования, управления, бизнес-анализа, разработки программного обеспечения. Кроме SQA Days, это Analyst Days-12 -конференция для системных и бизнес-аналитиков.
Хотите получить скидку 10%? Просто введите st28 в поле “Промо код” в форме регистрации.
Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. – устоявшегося русскоязычного термина пока нет. Как, зачем, когда и надо ли?
Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.
Автор: Иан Динвуди (IanDinwoodie) Оригинал статьи Перевод: Ольга Алифанова
Что я сделал не так и как это исправить? Именно это хочет знать пользователь, сталкивающийся с сообщением об ошибке в ходе использования ПО. Сообщения об ошибке – форма прямой коммуникации с конечным пользователем, которую зачастую недооценивают. Они играют важную определяющую роль в пользовательском опыте. Исследователи пользовательского опыта команды MozillaFirefox выяснили, что "после замены сообщения об ошибке на новый вариант количество пользователей, заявляющих, что воспользуется другим браузером, снижается на 29-60%" (Walkington, 2019). Другими словами, сообщения об ошибках могут сильно влиять на удовлетворенность и удержание пользователей. Гайдлайны сообщений об ошибках, как правило, зависят от отрасли и сценариев использования. В этой статье я обрисовал основные цели, чтобы читатели могли поразмышлять о качестве сообщений об ошибках в своем контексте.
На online-митапе спикеры Luxoft расскажут об особенностях и вызовах в области Automotive.
Доклады будут посвящены самым актуальным темам: что Automotive привнесет в повседневную жизнь, как достичь полной автоматизации в Automotive тестировании и особенности Move конструктора и лямбда-функции.
У всех будет возможность задать вопросы спикерам и принять участие в розыгрыше призов от Luxoft в режиме online за лучший вопрос!
Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.
Автор: Нипа Шах (NipaShah) Оригинал статьи Перевод: Ольга Алифанова
Подход Agile стремится убедиться, что команда с самого начала следит за качеством. На ранних стадиях тестировщики исследуют функцию и сценарии ее использования. В ходе анализа эпиков они узнают больше, оспаривают статус-кво, и помогают прорабатывать юзер-стори с учетом бизнеса и технических перспектив. И, наконец, тестировщики работают с командой над дизайном и внедрением, напоминая о тестируемости, удобстве использования и граничных случаях.
Мнение тестировщика имеет значение в ходе всего процесса, так как тестировщик помогает не забыть о взглядах и пользователя, и инженера, задача которого – искать лазейки и возможные проблемные области как с точки зрения бизнеса, так и с точки зрения технологии.
Когда тестировщики инициируют и поощряют дискуссии, это помогает прояснить тонкие детали элементов бэклога, позволяя инженерам сфокусировать свои действия. Хорошо сформулированные вопросы провоцируют хорошие обсуждения и ответы. Когда тестировщики внятно объясняют свою стратегию, разработчики смогут помочь им убедиться в тестируемости кода, а также написать более сфокусированные юнит- и интеграционные тесты. Все эти меры повышают качество тестирования кода.
В этой статье приведено десять примеров ситуаций, когда все зависит от хороших коммуникационных навыков тестировщика.
