Авторы: Мария Гуцук (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, который мы недавно зарелизили и который уже спас нам десятки часов отладки ошибок в алгоритмах.
Автор: Энди Найт (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-департамента регулярно поступали жалобы на нестабильность тестовой инфраструктуры.
