Рубрика «Тестирование IT-систем» - 25

Когда стоит проверять гипотезу о не меньшей эффективности? - 1

Статья от команды Stitch Fix предлагает использовать подход клинических исследований не меньшей эффективности (non-inferiority trials) в маркетинговых и продуктовых A/B тестах. Такой подход действительно применим, когда мы тестируем новое решение, имеющее преимущества, неизмеряемые тестами.

Самый простой пример — снижение костов. Например, автоматизируем процесс назначения первого урока, но не хотим сильно уронить сквозную конверсию. Или тестируем изменения, которые ориентированы на один сегмент пользователей, при этом следим, чтобы конверсии по другим сегментам просели не сильно (при тестировании нескольких гипотез не забываем про поправки).

Выбор правильной границы не меньшей эффективности добавляет дополнительные трудности на этапе дизайна теста. Вопрос, как выбирать Δ в статье не очень хорошо раскрыт. Кажется, что этот выбор не до конца прозрачен и в клинических испытаниях. Обзор медицинских публикаций по non-inferiority сообщает, что только в половине публикаций выбор границы обосновывается и часто эти обоснования неоднозначны или не подробны.

В любом случае, этот подход кажется интересным, т.к. за счет уменьшения необходимого размера выборки может увеличить скорость тестирования, а, значит, и скорость принятия решений. — Дарья Мухина, продуктовый аналитик мобильного приложения Skyeng.
Читать полностью »

image

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория

В большинстве письменных тестов используются оракулы. То есть вы знаете ответ и явным образом проверяете, дают ли вычисления правильный ответ.

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

Кроме тестов-оракулов, есть и ручные тесты. Тестер садится за компьютер и сравнивает вводимые данные с результатами. В процессе усложнения систем ручные тесты становятся всё менее полезными. Каждый из них проверяет только одну точку в гораздо большем пространстве состояний, а нам нужно нечто, исследующее всё пространство состояний.

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.
Читать полностью »

Привет! В этой статье я хочу поделиться опытом разработки визуальных тестов в нашей команде.

Так получилось, что о тестировании верстки мы задумались не сразу. Ну съедет какая-нибудь рамка на пару пикселей, ну поправим. В конце концов, есть же тестировщики — мимо них и муха не пролетит. Но человеческий фактор все-таки не обманешь — обнаружить незначительные изменения в пользовательском интерфейсе далеко не всегда физически возможно даже тестировщику. Вопрос встал ребром, когда была затеяна серьезная оптимизация верстки и переход на БЭМ. Тут без потерь бы точно не обошлось и нам позарез стал нужен автоматизированный способ обнаружения ситуаций, когда в результате правок что-то в UI начинает меняться не так, как было задумано, или не там, где было задумано.
Читать полностью »

кдпв

Какое-то время назад, приключилась со мной неприятная история, которая послужила триггером для небольшого проекта на гитхабе и вылилась в эту статью.

Обычный день, обычный релиз: все задачи вдоль и поперек проверены нашим QA-инженером, поэтому со спокойствием священной коровы «закатываем» на stage. Приложение ведет себя хорошо, в логах — тишина. Принимаем решение делать switch (stage <-> prod). Переключаем, смотрим на приборы…

Проходит пару минут, полет стабильный. QA-инженер делает smoke-тест, замечает, что приложение как-то неестественно подтормаживает. Списываем на прогрев кешей.

Проходит еще пару минут, первая жалоба из первой линии: у клиентов очень долго загружаются данные, приложение тормозит, долго отвечает и т.д. Начинаем беспокоиться… смотрим логи, ищем возможные причины.
Читать полностью »

Всем привет!
Меня зовут Паша, и я QA инженер команды Order Processing в Lamoda. Недавно я выступал на PHP Badoo Meetup. Сегодня хочу представить расшифровку своего доклада.

Речь пойдет про Codeception, про то, как мы его используем в Lamoda и как на нем пишем тесты.

Читать полностью »

image

17–18 июня в Москве состоится OFFZONE 2019 — международная конференция по кибербезопасности, где свои разработки и практические исследования представят крутые специалисты из 8 стран. %Username%, предлагаем тебе убить сразу много зайцев — посетить мероприятие бесплатно, получить заряд от решения интересных задач и побороться за оффер от BI.ZONE прямо на нашем стенде. Читать полностью »

В этой статье мы расскажем про проблемы, которые решает Consumer Driven Contracts, покажем как это применять на примере Pact с Node.js и Spring Boot. И расскажем про ограничения этого подхода.

За всё ответишь! Consumer Driven Contracts глазами разработчика - 1

Проблематика

При тестировании продуктов часто используют сценарные тесты, в которых проверяется интеграция различных компонент системы на специально выделенном окружении. Такие тесты на живых сервисах дают самый достоверный результат (не считая тестов на бою). Но в то же время они — одни из самых дорогих.
Читать полностью »

Релиз часто подкрадывается незаметно. И любая ошибка, внезапно обнаруженная перед ним, грозит нам сдвигом сроков, хотфиксами, работой до утра и потраченными нервами. Когда подобный аврал стал происходить систематически, мы поняли, что так больше жить нельзя. Было решено разработать систему всесторонней валидации, чтобы спасти рядового Райана разработчика Артёма, который перед релизом уходил домой в 9 вечера, или в 10, или в 11… ну вы поняли. Идея была в том, чтобы разработчик узнавал об ошибке, пока изменения еще не попали в репозиторий, а он сам не потерял контекста задачи.

Статическое тестирование или спасти рядового Райана - 1


Сегодня вносимые изменения бережно проверяются вначале локально, а затем серией интеграционных тестов на сборочной ферме. В этой статье мы поговорим о первом этапе проверки — статическом тестировании, которое следит за корректностью ресурсов и анализирует код. Это первая подсистема в цепочке и на её долю приходится основная масса найденных ошибок.
Читать полностью »

От обычного пользователя до полноправного администратора сервера (XSS, LFI, Web-Shell) - 1

В начале года мне написал сотрудник одной фирмы. Как я понял, в компании произошел небольшой конфликт. Из-за которого существовал риск компроментации системы каким-то из сотрудников. Решение провести аудит системы определенно было правильное. Ведь результаты проверки приятно удивили меня, и «неприятно» удивили заказчика.
Читать полностью »

Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.

Выбираем подходящий баг-трекинг - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js