Прежде всего, 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 стремится убедиться, что команда с самого начала следит за качеством. На ранних стадиях тестировщики исследуют функцию и сценарии ее использования. В ходе анализа эпиков они узнают больше, оспаривают статус-кво, и помогают прорабатывать юзер-стори с учетом бизнеса и технических перспектив. И, наконец, тестировщики работают с командой над дизайном и внедрением, напоминая о тестируемости, удобстве использования и граничных случаях.
Мнение тестировщика имеет значение в ходе всего процесса, так как тестировщик помогает не забыть о взглядах и пользователя, и инженера, задача которого – искать лазейки и возможные проблемные области как с точки зрения бизнеса, так и с точки зрения технологии.
Когда тестировщики инициируют и поощряют дискуссии, это помогает прояснить тонкие детали элементов бэклога, позволяя инженерам сфокусировать свои действия. Хорошо сформулированные вопросы провоцируют хорошие обсуждения и ответы. Когда тестировщики внятно объясняют свою стратегию, разработчики смогут помочь им убедиться в тестируемости кода, а также написать более сфокусированные юнит- и интеграционные тесты. Все эти меры повышают качество тестирования кода.
В этой статье приведено десять примеров ситуаций, когда все зависит от хороших коммуникационных навыков тестировщика.
Авторы: Мария Гуцук (Mariia Hutsuk), Шиваморти Бос (Sivamoorthy Bose) Оригинал статьи Перевод: Ольга Алифанова
Исследовательское тестирование – это подход к тестированию, при котором тестировщики динамически проектируют и выполняют тесты на основании своих знаний, исследования тест-объекта и результатов предыдущих тестов (согласно глоссарию ISTQB).
Исследовательское тестирование часто путают с ad-hoc тестированием, которое проводится по запросу без заранее составленных тест-кейсов, и манки-тестированием, которое заключается в рандомных действиях пользователя. Исследовательское тестирование – это изучение продукта путем небольших экспериментов и адаптация новых экспериментов в ходе тест-сессии. Этот тип тестирования отлично подходит для Agile– у него такая же логика, как и у Agile-экспериментов.
