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

За последний год появилось куча новых тулов с прицелом на удаленку, но стоит ли бежать и смотреть их, когда есть старые добрые инструменты? В этой короткой подборке я постарался собрать несколько тулов, которые помогут тестировщикам и тестировщицам облегчить работу с коллегами по цеху, опсами и разработчиками.

ДИСКЛЕЙМЕР: На самом деле у каждого инструмента есть как минимум по несколько альтернатив, выбор из которых может привести к знатному холивару. Если у вас есть свои соображения на тему "автор дурак, надо было брать не Х, а Y", приходите в комментарии!

Эта статья является переводом статьи из блога Uber. Обычно мы в Qameta Software не занимаемся переводами, но мимо этой статьи пройти не смогли. Хороший и исчерпывающий материал о том, что такое flaky-тесты, какие они бывают и как с ними справляться (с некоторыми проявлениями). Часть материала, посвященную переезду Uber с микросервисов на монорепо я опустил, оставив только то, что напрямую связано с отработкой flaky-тестов.

Юнит-тесты лежат в основе любой Continuous Integration (CI) системы. Они позволяют обеспечить контроль над качеством кода при высоких темпах разработки, предупреждая инженеров о багах в новом коде и регрессии в кодовой базе. Кроме того, они снижают стоимость разработки за счет обнаружения ошибок на ранних этапах. Именно поэтому построение стабильной и работающей тестовой инфраструктуры является одним из базовых требований для любой крупной разработки.

К сожалению, flaky-тесты осложняют жизнь тем, кто это требование пытается выполнить. Давайте считать, что мы будем принимать тест как flaky если на любых двух воспроизведениях он возвращает разные результаты: прошел или упал, — без изменения кода. Такие тесты чаще всего возникают в результате одной из двух причин: недетерминированность на уровне кода (порядок исполнения тредов и другие сложности с многопоточностью) или неоднородностью окружений, в которых выполняется тестирование (на одной машине все работает хорошо, а на CI-сервере тесты падают).

Давайте рассмотрим простой пример, на котором будет понятно, откуда у проблемы ноги растут:

Всем привет! Недавно я наткнулся на World Quality Report (ссылку поставил в конце, чтобы не пугать вам сразу отчетов на 50 страниц) — большой обзор трендов в тестировании 2020-2021 годов. А поскольку мы в Qameta Software сами постоянно сталкиваемся с командами тестирования, которые стараются как-то поправить свои процессы и наладить работу тестирования, я решил оценить, насколько они актуальны в России.

Обзор базируется на результатах 1750 получасовых телефонных интервью с CIO или руководителями технологических подразделений, которые посчитали качество ПО и тестирование критично важным для развития бизнеса.

В этой статье я взял основные тренды из отчета и постарался оценить их с точки зрения того, что происходит в компаниях, с которыми мы сталкиваемся.

Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!

Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.

Совсем недавно я услышал замечательную историю о проекте внутри крупной российской IT-компании, ищущей руководителя в отдел тестирования. Задача была простая: есть отдел из 20 человек, которые за последние несколько лет наколбасили несколько тысяч автотестов и спроектировали пачку тестов ручных. В целом все работало, но СТО на собеседовании сказал примерно следующее: “Ваша задача — выкинуть все это к чертям собачьим и сделать нормально. А то когда предыдущий QA Lead ушел, мы поняли, что вся эта инфраструктура у нас нигде не используется.” 

Ситуация невообразимая. Так не бывает. У нас точно не так. У нас же не так? 

Проблема “works on my machine” и “ответственность за нерабочий код лежит на том, кто его деплоит” ровно о том же. И пока разработчикам рассказывали про спасительный DevOps, тестировщики и QA-специалисты как-то со стороны смотрели на это “не шаля, никого не трогая, примус починяя”. Ну что, пришло время набросить и на этот вентилятор.

В этой статье мы с Артемом Ерошенко из Qameta Software попробуем разобраться, что такое “делать тестирование нормально” в новых проектах и какие инструменты могут в этом помочь. 

Идти вперед туда, где не ждут; атаковать там, где не подготовились.
Искусство войны, Сунь-Цзы

На прошлой неделе я набросал простую математическую модель принятия решения и оценки того, пойдете вы на конференцию или нет. Для того, чтобы модель была наглядной, нам понадобятся Саша (в очках) и Женя (улыбается), вот они:

Давайте знакомиться с Сашей и Женей, все начнётся сразу под катом:

Что: Семинар «Карго Культ» (открытый, по предварительной регистрации)
Где: Москва, Кутузовский проспект, д. 32
Когда: 20 августа 2018, с 14:00
Зачем: Понять, что делать, если ваши обычные инструменты уже не работают

Оглавление серии «Производительность как восприятие»:

• Производительность как восприятие: восприятие времени;
• Производительность как восприятие: управление восприятием;
• Производительность как восприятие: управление терпением. (эта статья)

1. Название: Java-конференция JPoint 2018.
2. Дата и место проведения: 6-7 апреля 2018 года, Москва, Конгресс-центр ЦМТ.
3. 10 докладчиков уже подтвердили свое участие.
4. Call For Papers.
5. Выставка и стенды.
6. Несколько тренингов.

Что общего у разработки программного обеспечения с разработкой настольных игр? Об этом лучше всех знает Сергей Milfgard Абдульманов который учился по специальности «математик-системный программист» и владел IT-компанией, а сейчас известен читателям Хабра постами в блоге компании «Мосигра».

Он будет завершать конференцию Joker своим кейноутом «Как мы расширяли бутылочное горлышко разработки», а в преддверии этой конференции мы задали ему ещё ряд вопросов о том, чем две индустрии похожи — и чем различаются.

Сергей: Короче, правильнее будет анонсировать тезис «как мы люто облажались». Это чтобы вы не думали, что мы там новый аджайл придумали или что-то ещё. А ещё у нас тестировщики чуть не набили разработчикам морду. В частном порядке. Но это отдельная песня.