Привет, Друзья! Тема заголовка, как мне кажется, не перестаёт болеть ни у одного тестировщика на протяжении всей его жизни. Кто-то для себя уже нашел простой ответ об идеальном соотношении разработчиков к тестировщикам, кто-то только на пути. А кто-то нашел какое-то своё просветление, о котором мы сегодня в общем-то и поговорим. Проходите опросик и добро пожаловать под кат.
Время прочтения около 7 минут.
3829 просмотров
Какое соотношение тестировщики/разработчики вам кажется оптимальным?
Больше чем 1 к 5 (6 и более разработчиков на одного тестировщика)
Показать результаты
Переголосовать
Проголосовать
Я надеюсь, вы уже прошли опрос выше. Если да, тогда можно глянуть на результаты такого же опроса у меня в телеграм-канале. Интересно будет сравнить.
Ну да, ну да. Опрос провокационный. Кто-то скажет мне (точнее, уже говорил): «Кирилл, это какой-то неправильный опрос, тут нет многих пунктов». Я осознанно убрал некоторые соотношения и вариант «угодить всем», от части, потому что хотел бы посмотреть именно на те цифры, которые зачастую обсуждаются на кухнях, в коридорах или на созвонах с топ-менеджерами; а от части потому, что именно вариант «угодить всем» я хотел обсудить в этой статье.
ANDROID Ошибка приложения | в приложении произошла ошибка | ошибка google | вылетает программа
Опрос в телеграм канале aboutqa (Cold turkey)
Ну что ж, затянувшаяся преамбула закончилась, погнали к рассуждениям.
Для начала я хотел бы кое в чем признаться. Дело в том, что если меня выдернуть на улице (или во сне) и спросить «Какое оптимальное соотношение тестировщиков к разработчикам?», я, не моргнув глазом, отвечу: «Ну наверное 1 к 3». Мой опыт работы в тестировании до 2019 года говорил мне, что 1 к 3 — это плюс-минус нормальное соотношение. Да, иногда где-то тестировщиков чуть больше, где-то чуть меньше, но медиана проходит где-то возле 1/3.
Я уже задавался этим вопросом ранее и, как ни странно, нашел только одну более-менее нормальную статью по теме. Статья, по-моему, значительно старше, чем 2017 г. Мне кажется я читал её в далёком 2011. Тем не менее ссылку дам на издание расширенное и дополненное.
Для тех, кому лень читать ещё одну статью, коротко скажу вывод: волшебной таблетки нет, каждому проекту своё количество тестировщиков; где-то 1qa к 20dev это слишком много, а где-то 5qa к 1dev это слишком мало.
Вывод кажется очевидным, спорить с ним не готов и не собираюсь, более того, всячески его придерживаюсь.
Своей же статьёй я бы, пожалуй, рискнул чуть расширить алгоритм, выдаваемый в статье Натальи Руколь, на примере своих проектов в Exante.
Но перед этим я вынужден сослаться на еще одну статью, которая мне показалась интересной за счёт микроисследования, которое в ней описывается.
Опять же, для тех, кому английский не мил – перескажу главные мысли.
Во-первых, автор подчеркивает те же принципы, проговоренные в статье выше: количество тестировщиков на проекте зависит от сложности проекта, количества поддерживаемых платформ и навыков тестировщиков.
Во-вторых, в статье приводится интересный график, основанный на статистике компании, которая и опубликовала статью. Компания занимается тестированием в режиме аутсорс. И по их личной статистике (которая, в свою очередь, довольно обширна) получается, что соотношение в районе 60% (6 тестировщиков к 10 разработчикам) будет оптимальным с точки зрения соотношения цена/качество. Тем не менее, если готовы переплачивать, то при достижении соотношения равного 90% (9 qa/10dev) уровень качества достигает плато и дальнейшее добавление новых тестировщиков не будет приводить к повышению качества.
ЭТО САМАЯ ПЕРВАЯ ИГРА В ПЛЕЙ МАРКЕТЕ! #Shorts
Какие бы выводы можно было сделать? Ну, самый главный вывод – «оранжевая» зона у каждой компании на самом деле своя. Посчитать её очень тяжело, если только не менять количество тестировщиков (с зафиксированной командой разработки) и не смотреть, что происходит на проекте. Тем не менее кажется, что 6 или 5 тестировщиков на 10 разработчиков (то есть примерно 1 к 2) – действительно довольно продуктивное и комфортное соотношение (на этом месте я снова полез посмотреть на результаты своего опроса. А вы?).
Чего во всех статьях нет, так это отсылок к методологиям разработки. Когда вы разрабатываете один и тот же продукт итеративно с релизами раз в 2 месяца, по скраму с двухнедельными спринтами или по канбану с подходом «каждая фича – новый релиз» – оптимальное соотношение разработчиков к тестировщикам будет меняться. По моему мнению, чем более гибкая разработка и частые релизы у вас на проекте – тем больше тестировщиков нужно проекту.
Что ещё не учитывается? Возможно, кто-то из вас уже нашел ответ на этот вопрос и горит желанием написать о нём в комментариях. Не спешите – обсудим. Не учитывается автоматизация тестирования. Вне зависимости от того, есть ли у вас выделенный автоматизатор или у вас T-shaped тестировщики-автоматизаторы, программирование тестов (и поддержание тестового фреймворка) отнимает время, а значит количество тестировщиков в команде должно быть больше.
А теперь, кажется пора поделиться историей про то, как мы работали и работаем в Exante.
Конечно, подсчёт тестировщиков по головам не обошел стороной и нашу компанию. В своё время тестировщиков и разработчиков действительно считали штуками и делили одно число на другое. Получали некое соотношение, а потом говорили «должно быть 1/3».
Какие были проблемы в связи с этим? Ну, думаю и так понятно. В команде разработки могло быть три синьористых синьора с опытом работы в компании более четырёх лет, а в команде тестировщиков – три джуна с опытом меньше года. Я сейчас утрирую, но вы понимаете, что получалось соотношение 1 к 1, а качество продукта и скорость тестирования не увеличивались.
Так же мы напоролись на то, что автоматизация выпадала из скоупа работы тестировщиков на проекте и становилась тестовым долгом на который уходило время тестировщиков-автоматизаторов. Таким образом capacity снижался, а соотношение QA/Dev не изменялось.
Фултайм автоматизаторы, которые автоматизировали регресс и, по сути, облегчали жизнь ручным тестировщикам, тоже попадали под раздачу. Их считали как «целого одного тестировщика», однако такой тестировщик не вносил свой вклад в тестирование новых фич, он занимался другими делами. Кстати, тест-менеджеры тоже порой считались за боевую единицу, а их в нашей компании было 3 (из 11 сотрудников QA отдела, в своё время).
Напоследок добавлю, что можно было даже жонглировать проектами. То есть, допустим на одном проекте соотношение было 1 к 2 (и всё равно не хватало), а на другом 1 к 4 и всё было супер. Но при усреднении получалось, что соотношение 1 к 3 и «куда ещё столько тестировщиков?»
Могу сказать только одно, ребят – здорово, что эти времена в далёком-далёком прошлом. Сейчас мы используем друге подходы.
В первую очередь – каждый проект живёт своей жизнью, и мы осознаём, что количество тестировщиков на каждом проекте должно быть подсчитано отдельно.
Здорово, что эти времена уже в прошлом
Дальше – мы не учитываем автоматизацию в этих расчётах. Автоматизаторы занимаются своими делами, от них ожидаются свои результаты, но если мы хотим ускорять разработку проектов (а значит и тестирование) мы должны ориентироваться на релизное тестирование в рамках скоупа спринта.
Там, где как таковых спринтов нет – важно смотреть на количество задач в тестировании.
И да, собственно простая в своей гениальности мысль заключается в том, чтобы смотреть вообще не на количество разработчиков, а на количество задач. Ведь именно их обслуживают тестировщики.
Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов
Как бы банально это не звучало, но большинству людей нравится, чтобы все было просто. Особенно, когда дело касается новых продуктов. По сути, потенциальная ценность, которую ваш продукт или сервис может привнести в жизни в ваших клиентов, не имеет никакого значения, если люди не смогут использовать его так, как этого хочется им, они почти наверняка пройдут мимо и обратят внимание на другие решения.
Напрашивается вывод — прежде чем начинать продавать свой продукт целевым клиентам, вы должны убедиться в том, что они смогут работать с ним так, как и намеревались изначально.
Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.
Что такое пользовательское приемочное тестирование?
Пользовательское приемочное тестирование — процесс, в ходе которого вы просите группу людей использовать продукт, сервис или часть софта с его полным функционалом.
Известное также как бета-тестирование, UAT служит трем основным целям:
- Определить, работает ли продукт в реальных ситуациях так, как задумывалось при его создании.
- Определить, были ли обозначены все доступные функции.
- Проверить продукт на наличие багов и сбоев, которые мешают ему выполнять свои основные функции.
Далее в статье мы еще поговорим о важности UAT, но сперва давайте быстро разберем разные типы такого тестирования.
5 типов пользовательского приемочного тестирования
1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:
Эта страница не очень удачно выглядит в русской реализации, но, тем не менее, она выполняет свою функцию. Быстро и без особых усилий создать свой лендинг пейдж для бета-тестирования вашего нового продукта можно с помощью нашей платформы. Для этого достаточно выбрать любой бесплатный шаблон и адаптировать его под себя:
2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.
3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.
4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.
5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.
Почему пользовательское приемочное тестирование играет столь важную роль
Итак, UAT является неотъемлемой частью процесса создания продукта. Тем не менее, вы должны фокусироваться на таких тестах не только при их фактическом проведении, но и на всех этапах разработки:
Как видно из диаграммы выше, пользовательское приемочное тестирование нацелено на то, чтобы все изначальные требования к продукту были соблюдены.
Думайте о конечном пользователе
Ценность вашего продукта определяется только людьми, которые будут с ним работать.
Хотя это звучит весьма очевидно, в процессе разработки продукта о таком нюансе можно запросто забыть. Не учитывая то, как ваши конечные пользователь будут взаимодействовать с вашим продуктом, вы рискуете столкнуться со многими проблемами или даже отклониться от намеченного пути. И точно также, не зная, чего на самом деле конечные пользователи хотят от вашего продукта, вы рискуете снабдить его совершенно ненужными функциями.
Несмотря на то, что удерживать фокус на клиентах в ходе разработки можно по-разному, акцентируя внимание на UAT, вы гарантированно сможете убедиться в том, что все усилия по вашему продукту делаются с мыслью о конечном пользователе.
Кроме того, это поможет вам сделать процесс разработки менее произвольным, поскольку каждое изменение или улучшение будет сопровождаться вопросом: «Как эта функция поведет себя в ходе пользовательского приемочного тестирования?».
Подтвердите product/market fit
Положительные результаты, полученные бета-тестерами во время вашего UAT, могут подтвердить не только наличие рынка для вашего продукта, но и то, что потребители в рамках этого рынка будут успешно использовать ваше решение.
Когда продукт готов к проведению UAT?
Прежде чем начинать UAT, команда разработчиков должна соблюсти ряд предварительных условий.
Остановимся на этих критериях более подробно.
Бизнес-требования должны быть готовы
Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:
- прийти к согласию между заинтересованными сторонами;
- обеспечить основу, которая бы объясняла поставщику технологических услуг, каким должен быть продукт, чтобы удовлетворить потребности бизнеса и клиентов;
- обеспечить исходные данные для следующей стадии проекта;
- описать, как потребности бизнеса/клиентов будут удовлетворены за счет продукта.
Продукт должен функционировать на своих предельных возможностях
Пользовательское приемочное тестирование не является синонимом функционального теста. UAT не предназначено для выявления сбоев, ошибок, зависаний и прочих проблем.
Вместо этого, с помощью таких тестов вы должны проверять юзабилити продукта, когда он работает так, как вы и задумывали изначально. Иными словами, если на текущий момент ваше решение нуждается в каких-то очевидных доработках, оно не готово к UAT.
Проблемы должны фиксироваться, исправляться и тестироваться
По ходу разработки продукта вы почти наверняка столкнетесь с перечисленными выше проблемами. Чтобы подготовить свое решение к UAT, ваша команда должна не только исправлять эти просчеты, но и фиксировать их в специальном лог-файле.
Этот лог-файл должен содержать следующую информацию:
- с чем конкретно связана проблема;
- как проблема была устранена;
- доказательство того, что в отношении проблемы было проведено тестирование;
- результат исправления.
Такой подход обеспечивает максимальную прозрачность и наглядность в контексте разработки продукта для всех заинтересованных сторон.
Команда по тестированию системы должна дать добро
На данном этапе производственного процесса, когда все остальные критерии уже были соблюдены, команда разработчиков и другие заинтересованные стороны должны подтвердить готовность продукта к бета-запуску для ограниченного количества пользователей.
Зачем нужно пользовательское тестирование: кейс от Feedly
6 шагов успешного пользовательского приемочного тестирования
Процесс UAT включает в себя следующие этапы:
1. Проанализируйте бизнес-требования
Как было сказано ранее, прежде чем переходить к разработке продукта, вам необходимо позаботиться о документации по бизнес-требованиям. Но помимо этих документов, вам нужно собрать следующее:
- Устав проекта
- Бизнес-кейсы использования продукта
- Диаграммы технологических процессов
- Спецификации к системным требованиям (для SaaS-продуктов)
Анализируя эти документы, вы сможете начать разработку тестовых сценариев — важнейшего аспекта всех последующих шагов процесса.
2. Разработайте UAT план
На этой стадии вы определяете такие логистические критерии UAT, как:
- условия входа и выхода (то есть когда продукт готов к UAT и когда тестирование будет считаться завершенным);
- кто будет участвовать в тестировании и какая роль будет отводиться им в течение всего процесса;
- график и продолжительность тестирования;
- как будут собираться, анализироваться и задействоваться тестовые данные.
3. Определите тестовые сценарии и кейсы
Вам нужно будет продумать конкретные задачи для своих бета-тестеров и подготовить учебные материалы, которые бы помогали им пройти этот путь.
По сути, вы должны разрабатывать такие тестовые сценарии так же, как и свой onboarding-процесс. Таким образом вы убедитесь в том, что ваше бета-тестирование соответствует тому, как продукт будет использоваться в реальных условиях.
4. Подготовьте тестовые данные
Разумеется, вы также должны наладить процесс, который бы позволял вам эффективно собирать и подготавливать тестовые данные. Кроме этого, вам нужно быть уверенными в том, что используемая вами информация всегда будет оставаться конфиденциальной (особенно учитывая то, что GDPR уже вступил в силу в Европе).
5. Проведите тест
В ходе тестирования члены QA команды работают с бета-пользователями, чтобы завершить обозначенные тестовые задачи. Как только юзер достигает точки выхода, его просят оценить полученный опыт как позитивный или негативный.
Если большая часть ответов оказывается положительной, команда может уверенно двигаться вперед и выводить продукт на рынок, создав посадочную страницу, открытую уже для всех желающих. Если же это не так — разработчикам придется внедрять в продукт необходимые изменения.
Также стоит отметить, что хотя к этому моменту ваш сервис уже должен нормально функционировать, во время UAT ваши бета-тестеры могут столкнуться с непредвиденными проблемами. Если это произойдет, вам нужно будет приостановить тестирование и возобновить его после устранения неполадок.
6. Подтвердите достижение бизнес-целей
Как только бета-пользователи дадут вам положительную обратную связь, вам нужно будет подготовить документацию, которая послужит официальным сигналом для вывода вашего продукта на рынок.
Эта документация включает:
- план тестирования
- UAT сценарии и тестовые кейсы
- результаты пользовательских тестов
- лог-файл с проблемами (то есть баги, сбои, неполадки и т. д.), обнаруженными в ходе разработки и тестирования продукта
Затем эти документы представят на встрече по UAT, где будут присутствовать все заинтересованные стороны. Помимо рассмотрения самих документов, участники собрания должны будут убедиться в том, что продукт действительно готов к запуску и что закулисные бизнес-процессы компании гарантируют его стабильную работу.
По материалам: fieldboom.com, Источник картинки: deadheading
Источник: lpgenerator.ru
Е9.15. сколько участников тестирования прошли больше трёх тестов
В качестве ответа укажите, сколько участников тестирования прошли больше трёх тестов. В электронной таблице содержатся вещественные числа – количество баллов, которое набрали участники тестирования. В первой строке указаны дисциплины, во второй – максимальный балл за тест по дисциплине, в левом столбце – фамилии участников. Считается, что тест пройден, если участник тестирования набрал больше 60% от максимального балла.
Источник: «Евгений Джобс»
https://vk.com/eugenyjobs
Решение:
Затем скопируйте эту формулу в P4:AC33
Затем скопируйте эту формулу в AD4:AD33
AD3 =СЧЁТЕСЛИ(AD4:AD33;»>3″) = 18
Ответ: 18
Источник: informatikaexpert.ru