Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. – устоявшегося русскоязычного термина пока нет. Как, зачем, когда и надо ли?
Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.
Автор: Иан Динвуди (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-экспериментов.
Тестировщики для контроля качества продуктов применяют средства автоматизации, анализаторы сетевого трафика, инструменты отладки… а также головной мозг для выполнения, так называемого, «ручного тестирования». Данное словосочетание неудачно по той причине, что процесс тестирования невозможно свести только к мышечной активности. Тем более руки в этом процессе задействованы незначительно. А вот от работы нервной системы в целом и зависит результат. В данной статье я постараюсь раскрыть то, как можно применять знания о высшей нервной деятельности человека для успешного решения задач по тестированию.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Python – потрясающий язык программирования. Его любят и новички, и эксперты, и он регулярно оценивается как язык с самым высоким спросом. На конференции PyData Carolinas 2016 Джош Хоус, старший менеджер управления данными в MaxPoint, описал Python примерно так:
Python – магический инструмент, который позволяет легко решать самые сложные мировые проблемы.
Я впервые столкнулся с Python в старшей школе более десяти лет назад, но начал по-настоящему пользоваться им и полюбил только недавно, используя его для тест-автоматизации. Эта серия статей научит вас тестировать на Python. Эта вводная статья даст вам базовые ориентиры, а каждая последующая подробно разберет один из фреймворков Python.
Сегодня мы будем говорить про многопоточность и расскажем про инструмент Lincheck, один из ключевых проектов Лаборатории параллельных вычислений в JetBrains Research. Если в двух словах, то это фреймворк для тестирования многопоточных структур данных под JVM, предоставляющий возможность декларативного написания тестов. Что это значит? Как правило, при написании тестов мы пишем саму логику тестирования. С Lincheck-ом же все иначе — вместо указания того, как тестировать, вы объявляете операции, которые необходимо проверить, критерий корректности (например, линеаризуемость) и возможные ограничения (например, "single-consumer" для очередей) — то есть указываете что тестировать. А дальше Lincheck уже сам со всем разберется. В этом посте мы сделаем краткий обзор Lincheck-а и расскажем про режим model checking, который мы недавно зарелизили и который уже спас нам десятки часов отладки ошибок в алгоритмах.
