Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Python – потрясающий язык программирования. Его любят и новички, и эксперты, и он регулярно оценивается как язык с самым высоким спросом. На конференции PyData Carolinas 2016 Джош Хоус, старший менеджер управления данными в MaxPoint, описал Python примерно так:
Python – магический инструмент, который позволяет легко решать самые сложные мировые проблемы.
Я впервые столкнулся с Python в старшей школе более десяти лет назад, но начал по-настоящему пользоваться им и полюбил только недавно, используя его для тест-автоматизации. Эта серия статей научит вас тестировать на Python. Эта вводная статья даст вам базовые ориентиры, а каждая последующая подробно разберет один из фреймворков Python.
Сегодня мы будем говорить про многопоточность и расскажем про инструмент Lincheck, один из ключевых проектов Лаборатории параллельных вычислений в JetBrains Research. Если в двух словах, то это фреймворк для тестирования многопоточных структур данных под JVM, предоставляющий возможность декларативного написания тестов. Что это значит? Как правило, при написании тестов мы пишем саму логику тестирования. С Lincheck-ом же все иначе — вместо указания того, как тестировать, вы объявляете операции, которые необходимо проверить, критерий корректности (например, линеаризуемость) и возможные ограничения (например, "single-consumer" для очередей) — то есть указываете что тестировать. А дальше Lincheck уже сам со всем разберется. В этом посте мы сделаем краткий обзор Lincheck-а и расскажем про режим model checking, который мы недавно зарелизили и который уже спас нам десятки часов отладки ошибок в алгоритмах.
Автор: Энди Найт (AndyKnight) Оригинал статьи Перевод: Ольга Алифанова
Тест – это процедура, которая проверяет поведение с целью определить, правильно ли оно функционирует. У тестов много видов – юнит, интеграционные, end-to-end, но все функциональные тесты по сути делают одно и то же: пробуют что-то и сообщают PASS или FAIL.
Тестирование дает эмпирическую петлю обратной связи разработке, и тем самым обеспечивает нашу безопасность. Имея тесты, мы знаем, когда что-то ломается. Без тестов программирование может быть опасным. Мы же не хотим отправить в релиз большие страшные баги!
Как же нам написать хорошие тесты, если мы планируем потратить время на создание тестов? Существует простой, но мощный паттерн, которому следую я: "Настрой – действуй – проверь" (Arrange-Act-Assert).
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно я прошла этот отличный курс по поиску веб-элементов от Эндрю Найта в Test Automation University. Вдобавок к полезному синтаксису доступа к элементам, я также выучила еще один способ с пользой применить инструменты разработчика!
Один из самых раздражающих моментов UI-автоматизации заключается в попытке выяснить, как найти на странице элемент без идентификатора автоматизации. Возможно, вы знаете, что если открыть инструменты разработчика в Chrome, то можно кликнуть правой клавишей на элемент страницы, выбрать Inspect, и этот элемент подсветится в DOM. Это полезно, но тут скрыто нечто еще более полезное: там есть строка поиска, позволяющая вам увидеть, правильно ли сработает локатор, который вы планируете использовать в тесте. Разберем на конкретном примере, как использовать этот ценный инструмент.
На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.
TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.
Мы уже рассказывали о том, как масштабировали свою Selenium-ферму с помощью Google Cloud Engine и Kubernetes. От очередей на запуск тестов мы избавились, но из QA-департамента регулярно поступали жалобы на нестабильность тестовой инфраструктуры.
Большая конференция по тестированию Heisenbug 2021 Piter — с 6 по 9 апреля, онлайн. Опытные QA-эксперты со всего мира выступят с несколькими десятками воркшопов и докладов обо всех аспектах тестирования:
Инструменты;
Функциональное тестирование;
Нагрузочное тестирование;
Best practices;
Тестирование AR/VR;
Тестирование ML/AI;
Визуальное тестирование;
Мобильное тестирование;
SDET;
DevOps в тестировании;
И многое другое.
И все это в 4К, с возможностью ставить на паузу или менять скорость воспроизведения и доступом к записям докладов. А также активности с призами, дискуссии со спикерами и даже игровой режим платформы, который имитирует реальную площадку: локации, сцены, общение с коллегами и многое другое.
Более того, для вас действует промокод на скидку softwaretesting2021JRGpc.
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это вторая часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.
В этот раз я отвечу на вопрос "Как тестирование влияет на качество ПО?" (и связанный с ним вопрос, "Как связаны тестирование и качество ПО?").
Тут надо сделать отступление и прояснить, что я имею в виду под "качеством" при помощи определения от Джерри Вайнберга и Кема Кейнера:
Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.
