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

В этот раз Илария Тарасова и Максим Колодкин из Контур.Эльбы, расскажут, почему тестировщику нужно общаться с клиентом и какие инструменты для этого есть в Контуре. Чтобы не пропустить новую статью, подписывайтесь на телеграм-канал.

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

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

За 8 лет число пользователей сильно выросло, поэтому увеличилось и число консультантов. Сейчас их 70, они работают по жестким правилам и регламентам ради эффективности. С одной стороны, это помогает выстроить работу большой команды, а с другой, делает процесс очень негибким. Консультант может решить конкретную проблему, но у него не хватает времени, чтобы подумать шире и найти её истинную причину (например, в интерфейсе). В итоге такие проблемы не всплывают в ежемесячной статистике, а так и лежат на дне, пока не накопится критическая масса недовольных пользователей.

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

Первая статья была опубликована в январе на сайте «Сообщества тестировщиков Екатеринбурга». Мы переносим её на Хабр, чтобы её прочло больше тестировщиков. Следующая статья — за февраль — выйдет завтра, а её анонс будет в телеграм-канале.

Открывает цикл Максим Захаров, руководитель всех тестировщиков Контура и один из тестировщиков Ритейла. Он расскажет, почему копятся баги, как разобрать бэклог и уничтожить 80 багов с помощью пиццы :)

Бэклог — журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов — источником пользовательских историй.

Я работаю тестировщиком в офисе примерно по 8 часов, изредка работаю в выходные. Есть большие цели на полгода и небольшие проекты на несколько недель или месяцев. Есть и обязательная рутина. Работы всегда с избытком, то есть нет объективной возможности сделать всю. Через год я не хочу увидеть, что делаю те же задачи и решаю те же проблемы. Я не Дорофеев и не Архангельский, рецепта счастья в статье не будет, но можно смело рассчитывать на пару неплохих советов и приемов.

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

Продолжаем цикл статьей «Календарь тестировщика», в этом месяце поговорим о тестировании безопасности. Многие не знают с чего начать и пугаются сложностей. Иван Румак, тестировщик безопасности веб-приложений в Контуре, поделился основами в поиске уязвимостей. Новички найдут в статье базовые знания, а опытным тестировщикам будет полезен раздел про обход защиты от CSRF.

В прошлом году Иван занял 4 место в программе поиска уязвимостей Mail.ru и вошел в призовые топ-100 соревнования Hack The World 2017.

В феврале я решил научить коллег-тестировщиков искать уязвимости и проверять релизы на баги безопасности. Из плана обучения я вынес в статью самые основы: с чего начать, что такое HTTP, а также сделал полный разбор одной уязвимости — как искать, защищаться и обходить защиту.

Апрельская статья из цикла «Календарь тестировщика» посвящена метрикам. Кирилл Раткин, тестировщик Контур.Экстерна, расскажет как повысить эффективность тестирования с их помощью и не уйти в крайности.

Как часто вам приходится что-либо оценивать? Наверное, каждый день. Хорошая или плохая сегодня погода, сносно ли ведет себя кот, нравится ли вам эта футболка. На работе вы оцениваете свои задачи и результаты: это сделано хорошо, а тут можно было лучше. Такие оценки часто основаны на субъективном ощущении. Но эти оценки не могут повысить эффективность процессов, и нужна более высокая детализация. Тогда на помощь приходят метрики.

Как вы можете охарактеризовать свои рабочие процессы и практики? Они хорошие? Плохие? Насколько? Почему вы так решили?

Не удержусь и процитирую слова лорда Кельвина:

«Если вы можете измерить то, о чем говорите, и выразить это в цифрах – значит, вы что-то об этом предмете знаете. Но если вы не можете выразить это количественно, ваши знания крайне ограничены и неудовлетворительны».

Никакой процесс не может считаться зрелым пока не станет прозрачным и управляемым.

Я видел две крайности:

1. Люди считают, что у них все хорошо/плохо и без радаров. «Ну это же и так понятно»(с).
2. Каждый шаг обвешан цифрами, но большая их часть лежит мертвым грузом и никак не используется.

Нагрузочное тестирование во многом схоже с учениями по ГО и ЧС. Лучше заранее понимать, как будет выглядеть та или иная ситуация, чем пытаться в панике сориентироваться. Помимо собственных тестов и собранных на production проблем, можно перенять опыт коллег по индустрии. Специально для проекта «Календарь тестировщика» Дмитрий Воротников, тестировщик Контура, на примере ЧП крупных IT-компаний вывел несколько простых, но важных правил тестирования сервиса.

Изменившийся профиль нагрузки

Когда говорят о нагрузочном тестировании обычно имеют ввиду capacity testing. У онлайн-магазинов есть Black Friday и Cyber Monday — время распродаж и экстремального увеличения нагрузки на все сервисы. В Контуре похожие скачки трафика бывают в последние дни отчетности в контролирующие органы. По какой бы причине ни выросло число посетителей, нельзя допустить недоступности операций, ошибки или увеличения времени ответа. С помощью тестирования емкости сервиса мы убедимся, что пользователи не будут злобно дергать мышкой или уходить к конкурентам, а смогут комфортно и продуктивно работать.

Проводя тестирование с профилем нагрузки, повторяющим типовой за последние месяц, год или два, можно столкнуться с проблемой, какая была у Amazon Simple Storage Service 15 февраля 2008 года. Доступ к данным в S3 регулируется AWS Authentication service. Запросы к нему зашифрованы и требуют на обработку больших вычислительных ресурсов. Amazon поддерживали столько серверов, сколько было необходимо для обработки нагрузки предыдущих двух лет. В отчетный день в 3:30 утра инженеры заметили, что количество аутентификационных запросов увеличилось. Это перегрузило инфраструктуру AWS и стало невозможно обрабатывать все запросы. Чтобы обработать возросшую нагрузку, пришлось вводить дополнительные мощности. До 6:48 все проекты, использовавшие S3, были недоступны.

«Календарь тестировщика» снова с вами! За 2017 год у тестировщиков Контура было 32 летучки отдела, 3 тест-сессии, 2 онлайн-просмотра конференций, 14 мастер-классов, приезд внешнего гуру тестирования с лекцией и тренингом и ещё много всего. Большинство мероприятий организовали сами тестировщики.

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

Знакомьтесь, авторы июльской статьи для «Календаря тестировщика» Андрей Марченко и Марина Третьякова, тестировщики-аналитики Контура. В этом месяце ребята расскажут о моделях рабочего процесса по тестированию аналитики, и как они начали тестировать аналитику до стадии разработки. Опыт ребят будет полезен менеджерам, тестировщикам и аналитикам некрупных продуктовых команд, которые не живут в рамках стартапа и для которых качество важнее скорости.

Модели рабочего процесса по тестированию аналитики

Модель 1

Тестировщик работает с аналитикой после того, как ему передали готовую задачу. Он проверяет задачу, читая аналитику, как документацию того, что сделал разработчик. Ошибаются абсолютно все, вне зависимости от уровня профессионализма. Дефекты могут быть в аналитике или в коде разработчика.

Минусы:

• дефекты в аналитике не будут выявлены раньше стадии тестирования,
• есть риск того, что задача из тестирования отправится снова в аналитику на доработку. Как следствие TimeToMarket задачи существенно увеличивается.

Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.

Плюсы:

• сокращается время тестировщика для задач, где не требуется аналитик (инфраструктурные, рефакторинг).

Модель 2

Тестировщик подключается к задаче еще до того, как ее передали в разработку. Он смотрит прототипы по задаче или просто читает документацию. Все вопросы по задаче тестировщик задает аналитику. Аналитик оперативно исправляет замечания. Тестировщик составляет приемочные тесты.

Продолжаем цикл «Календарь тестировщика». В этот раз ответим на вопросы: зачем тестировщику читать книги? Что лучше книг? Есть миллион статей про это. У тестировщиков Контура Виталия Рощупкина и Кати Пальчиковой есть ещё одно мнение. И проверенные ими способы: как найти время, как мотивировать себя и коллег.

Так выглядела библиотека тестеров Контура в 2017

И снова в нашей ленте «Календарь тестировщика». В этом месяце Марина Третьякова, тестировщик проекта Контур.Поставки, расскажет об оптимизации тестов. Марина разберет конкретные проблемы и способы их решения, а также посоветует, как оптимизировать свои тесты и сократить время на тестирование.

В октябрьском «Календаре тестировщика» Арина Разгоняева, Юля Агафонова и Лена Зырянова расскажут, как они собирают фидбэк. Мы субъективны, оценивая самих себя, поэтому спрашиваем о себе других. Можно встретиться с коллегой за чашкой кофе и узнать, что он о тебе думает. Можно подойти более обстоятельно и провести опрос 360 градусов. Мы используем оба варианта и некоторые другие практики. О них сегодня и поговорим.

Авторами ноябрьского «Календаря тестировщика» стали Оля Фазулзянова, тестировщик Контур.Экстерна, и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса тестировщиков. Девушки рассказали о парном тестировании, о задачах, которые оно помогает решить, и привели пример неудачного использования практики.

В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.

Если парное программирование настолько эффективно, то почему бы не применить аналогичные принципы в тестировании? Да, это можно сделать, парное тестирование существует давно и хорошо себя зарекомендовало. Но не стоит забывать, что любая практика является всего лишь инструментом для решения каких-либо задач.

В Википедии нет термина «парное тестирование», но есть определение для парного программирования, которое можно взять за основу. Тогда, на наш взгляд, мы получаем следующее.

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

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

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

Зачем мне это надо?

У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:

Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!

Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.

Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.

Мне очень грустно, когда я очередной раз слышу мнение, что тестировщик может достичь своего предела за 1,5 года, а дальше либо в автоматизацию, либо смена роли на менеджера, аналитика, разработчика и т. п. Когда твой каждый день — это просто повторение алгоритма: почитал аналитику, посмотрел прототипы, потестировал, запостил баги, перепроверил баги — то легко понять, почему ты устаёшь и разочаровываешься в профессии. Это же просто скучно!