Вход в систему

10-я конференция SQA Days - день второй

maksiq аватар

Второй день конференции SQA Days был не хуже первого. На первом слоте я делал доклад про совмещение ролей Аналитика и Тестировщика. Фишкой было использование V-диаграмм для визуализации ролей. Надо сказать, что статья - анонс доклада почти месяц была на форуме software-testing.ru и вызвала обсуждения. Мне возражали и по поводу Agile и по поводу совмещения ролей, которые представляются слишком разными для одного человека. А на конференции это возражений не вызвало. На практике тестировщик занимается еще и аналитикой во многих компаниях. Доклад вызвал интерес и после него я отвечал на вопросы в холле почти целый слот. Презентация выложена здесь.

Дальше я слушал доклад Александра Калугина, который рассказывал про организацию тестирования одной командой нескольких проектов. И блиц Ольги Николаевой про внедрение внутренних инструментов автоматизации в IT-компаниях и их развитие.

Еще был замечательный доклад Екатерины Каменевой про организацию тестирования, при которой основная нагрузка переложена на разработчиков и автоматические тесты. Там вообще была показана очень интересная схема процесса, при которой команда разработчиков более чем из 20 человека поделена на мини-команды по 2-3 человека, каждая из которых берет отдельную фичу, выясняли требования у PM и проговаривая тестирование с QA, которых всего трое. А сами QA занимаются выходным тестированием и организуют процесс. При этом спецификации требований и тест-кейсов нет, все поддерживается на общении. Причем раньше они это писали, она показывала - а потом отказались. Однако, при этом тестировщики знают о действиях друг друга, а разработчики - знают о тестировании своих фич, поэтому рисков потери информации нет. Тем не менее, это определенный разрыв шаблона, и в вопросах ее раз восемь спросили - как же так, а вдруг кто заболеет - а она повторяла, что есть дублирование. Еще один разрыв шаблона касался качества такого тестирования - на что она вполне обоснована сказала, что в этом проекте они обеспечивают требуемое заказчиками качество при высокой скорости разработке, в других проектах - у них другая организация. То есть процесс адаптирован сознательно, заказчики получают возможность непрерывных усовершенствований по необходимости вместо недельных билдов, которые были раньше. В целом доклад и сама Екатерина - очень понравились.

Был неплохой блиц Анны Скуминой про ретроспективу по тестированию проекта - как она анализирует статистику, что готовит на будущее. Она - единственный тестировщик на проекте и то, что она проводит эту рефлексию - вызывает уважение.

В финале Орлов и Панкратов устроили шоу с пусканием самолетиков и представлениями, рассказывая про жизненный цикл коммуникативных дефектов, которые как баги - просто у людей. И жизненный цикл - аналогичен. В принципе, это неплохая аналогия для описания процесса работы с психологией понятным IT-языком.

А в обед в главном зале был круглый стол сообществ тестировщиков из разных городов. Собственно, стола не было - участники сидели на краю сцены, вплотную к залу. Молодые сообщества рассказывали success story, более старые - обменивались опытом по различным форматам мероприятий. Потому что через некоторе время интерес обычно ослабевает, если формат не меняется. Но форматов - много,и в целом сообщества развиваются.

Подводя итоги, хочу сказать, что это - наиболее живая и энергичная конференция из тех, на которых я был. Много молодых и энергичных людей. Это площадка, на которой молодые могут рассказать о своей работе, поделиться достижениями и проблемами, получить признание. И это - важно для молодых, это - самореализация. А еще - я услышал любопытную аналогию. Собрались водители самолета, парохода, автомобиля, самосвала и велосипеда - и общаются на тему вождения обобщенных транспортных средств. С фаном и увлечением, хотя транспорт - сильно разный. И это общение - вызывает желание двигаться дальше, рождает идеи.

Поделиться

Комментарии

galogen аватар

По поводу Вашего, Максим,

По поводу Вашего, Максим, доклада. Интересный. Четкий, без воды. Идея понятна. Более того, она соответствует практике. Почему бы не признать это явным? Правда, мне кажется, тут получается некое маскирование ситуации, может я и ошибаюсь: аналитик-юниор = тестировщик, т.е. доля вопросов тестирования существенна выше. По роли он будет проверяющим работы, которую выдвинул аналитик-сеньор и выполнил разрабтчик. При проверки ему потребуется бизнес-контекст задачи и навыки тестировщика. Бизнес-контекст должен предоставить старший аналитик, возможно даже стратегию и тактику проверки - т.е. некий сценарий проверки, а аналитик-юниор  вначале просто идет по чек-листу. Такой способ ничем не отличается от разделения ролей аналитика и тестировщика, потому аналитик-проверяющий все-таки должен быть по определению и автором работы, только в случае юниора не очень критичной. А это значит. что и старший аналитик будет проверяющим в работах, где он автор. Мы приходим к тому, что навыки аналитика должны находится в консенсусе с анализом и тестированием(верификацией). Есть ли тут противоречие? На первый взгляд нет, но по своему опыту знаю, что у тестировщика постепенно складывается критическое мышление по отношению к качеству решения задач, а аналитик смотрит только на соответствие требованиям и здравый смысл. Аналитик критикует тестировщика за его привязанность деталям работы системы, а тестировщик не всегда согласен с точкой зрения здравого смысла и бизнес-контекста. Кроме того, вопросы автоматизированного тестирования сложно возлагать на аналитика, так как приземляет аналитический кругозор к поверхности плоской реализации :)

 

maksiq аватар

Тут вопрос темпов роста и организации в целом.

Для нас позиция юниора - временная, от человека ожидают интенсивного роста и набора опыта за 2-6 месяцев с переходом к полноценной аналитической работе. При этом негатив и противостояние уходит. Мы стараемся достаточно быстро ввести начинающего аналитика в контекст задач, чтобы он начала активно участвовать во встречах с заказчиком, естественно, для начала вместе с более опытным аналитиком. Понятно, что для этого ему нужно начальное освоение системы - поэтому его еще забрасывают тестированием.

galogen аватар

Максим, могли бы вы ответить

Максим, могли бы вы ответить на пару вопросов?

1. существует ли у Вас автоматизированное тестирование? 2. Как у Вас организован процесс тестирования (ну хотя бы в общих красках)? Спасибо

maksiq аватар

Могу ответить

У нас для многих проектов есть автоматические тесты уровня бизнес-логики, они подключены к Cruise control и запускаются после сборки, которая настроена по commit. Автоматических тестов интерфейса нет, но для web-приложений будем это налаживать. А тестирование включает два процесса. Во-первых, после разработки задача получает статус fixed и далее ее проверяет аналитик-тестировщик на отдельном экземпляре системы, ставит verified. При этом "смежные" области тоже проверяются. Далее она может быть пронесена отдельно на тестовый сервер у заказчика - тогда ее проверяет еще IT-служба заказчика. А еще - после компоновки версии в целом проверяется по некоторым сценариям, включающим основные кейсы. Объем проверки зависит от объема версий, что определяется особенностями проекта. Если версии выпускаются еженедельно, то проверяем только основныце кейсфы, если раз в пару месяцев - то тестов больше. Потом версия проносится на тестовый сервер заказчика и проверяет он, дальше пронос на боевые сервера. Примерно так.

galogen аватар

Спасибо, Максим. А как по

Спасибо, Максим. А как по вашему опыту совмещение аналитиков и тестировщиков сказалось на общем качестве проектов (проекта)? Действительно ли это повторяемый и прогнозируемый (управляемый) результат? Или скорее вы находитесь в стадии эксперимента.

Мы тоже реально не ставим на тестирование интерфейсов. Если это и происходит - издержки архитектуры самой тестируемой системы и тестового набора. Бизнес-логику как раз впервую очередь и тестируем (я имею в виду не процедурную низкоуровневую, а уровня бизнес-задачи (use case), Это жизненная необходимость - много больших, объемных изменений в сжатые сроки. Облегчает дело - монопроектность, хотя кастомизация есть, но все-таки тестируется только одна конфигурация, хотя и несколько последовательных релизов.

ВАши автотесты производятся теми же аналитиками, или в команде разработчиков есть отдельная группа автотестеров?

maksiq аватар

Совмещаем лет пять, будем и дальше

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

Что касается автотестов, то их пишут те же разработчики.  Сценарии обсуждаются с аналитиком. Объем автотестов - завивсит от проекта, все-таки ручного тестирования тоже немало.

Поделиться

Поделиться
RSS-материал