Comments 13
Откровенно сказать, тестировщики из разработчиков не очень. Проверять свой же код — сплошное мучение: «Он и так работает, я же его только что написал»
Откровенно сказать, когда тестируешь свой код, то подсознательно понимаешь слабые места и стараешься на них сильно не давить. Этакий щадящий режим.
Откровенно сказать, когда тестируешь свой код, то подсознательно понимаешь слабые места и стараешься на них сильно не давить. Этакий щадящий режим.
На оптимальную структуру тестирования очень сильно влияет орзанизация разработки в целом, а также как продукт доставляется к пользователям, как пользователи выбирают и покупают продукт, какова структура релизов.
Когда наиболее эффективным в SCRUM оказывается выделенный отдел тестирования, весьма вероятно что в остальных аспектах проект по каким-то причинам тоже не очень agile.
Когда наиболее эффективным в SCRUM оказывается выделенный отдел тестирования, весьма вероятно что в остальных аспектах проект по каким-то причинам тоже не очень agile.
У нас и нет выделенного отдела, у нас есть команда тестирования. Команда нужна чтобы в целом развивались технологии тестирования, чтобы знания передавались, аккумулировались. Получилась некая сервисная команда, которую ни scrum, ни agile в принципе не отвергают. Например, те же Devops может вполне работать в scrum оказывая услуги по разворачиванию.
Если работает, то хорошо. Я просто не понял, я прочитал команда — team — scrum team (kanban or anything). Значит люди занимаются разработкой но ни в одну группу SCRUM не входят.
Я старый идеалист скептик — devops оказывающий услуги по разворачиванию я называю внутренним сервис деском :)
Для себя мы нашли правильным поместить тестировщиков в SCRUM группы, у нас разработчики очень хорошо и критически тестируют, пока плохова-то автоматизируют — над этим мы работаем. Тестировщиков очень хочется наконец превратить из людей только предоставляющих сервис в людей в перую очередь организующих и обучающих. Да, ещё у нас есть группы по дисциплинам: UI/UX, тестирование, архитектура, безопасность, настольные игры и другие (которые возникают и работают пока у них есть что обсуждать между членами несколькими SCRUM команд)
Кстати, тестировщики начинающие программировать — это хорошо, если они продалжают понимать что, как и почему правильно тестировать. К сожалению, зачастую, люди перемещаются из тестировщихов в программисты отнють не потому что они хорошие тестировщики.
Я старый идеалист скептик — devops оказывающий услуги по разворачиванию я называю внутренним сервис деском :)
Для себя мы нашли правильным поместить тестировщиков в SCRUM группы, у нас разработчики очень хорошо и критически тестируют, пока плохова-то автоматизируют — над этим мы работаем. Тестировщиков очень хочется наконец превратить из людей только предоставляющих сервис в людей в перую очередь организующих и обучающих. Да, ещё у нас есть группы по дисциплинам: UI/UX, тестирование, архитектура, безопасность, настольные игры и другие (которые возникают и работают пока у них есть что обсуждать между членами несколькими SCRUM команд)
Кстати, тестировщики начинающие программировать — это хорошо, если они продалжают понимать что, как и почему правильно тестировать. К сожалению, зачастую, люди перемещаются из тестировщихов в программисты отнють не потому что они хорошие тестировщики.
Разработчики у Вас тестируют код, который написали сами или тестируют код коллег (напр. во время CodeReview)?
Как правило, последнее более результативно в силу незамыленности глаза.
Как правило, последнее более результативно в силу незамыленности глаза.
Код ревью он проходит отдельно от тестирования.
Разработчики тестируют и своё и чужое, специфика нашего продукта — он очень большой и старый, поэтому основные проверки на отсутствие регрессии это ручное тестирование. Подобное тестирование не вызывает сложностей у разработчиков, наоборот зачастую они знают больше о деталях поведения системы если они недавно что-то меняли в этой части, тогда они легче могут заметить проблемы возникающие за границами основных сценариев на который они сейчас смотрят.
Сложности такого подхода которые я вижу:
— чтобы человек чувствовал себя комфортно тестируя, когда его основная специализация программирование, процесс должен быть организован так, чтобы это было очевидно что в текущий момент именно этими действиями он приносит максимальное количество пользы (при том что все вокруг также равномерно и эффективно загружены).
— если человек проводит чересчур много времени занимаясь делами не связанными с его основной специализацией он очень сильно устаёт и перестаёт чувствовать себя занятым профессиональной деятельностью.
Разработчики тестируют и своё и чужое, специфика нашего продукта — он очень большой и старый, поэтому основные проверки на отсутствие регрессии это ручное тестирование. Подобное тестирование не вызывает сложностей у разработчиков, наоборот зачастую они знают больше о деталях поведения системы если они недавно что-то меняли в этой части, тогда они легче могут заметить проблемы возникающие за границами основных сценариев на который они сейчас смотрят.
Сложности такого подхода которые я вижу:
— чтобы человек чувствовал себя комфортно тестируя, когда его основная специализация программирование, процесс должен быть организован так, чтобы это было очевидно что в текущий момент именно этими действиями он приносит максимальное количество пользы (при том что все вокруг также равномерно и эффективно загружены).
— если человек проводит чересчур много времени занимаясь делами не связанными с его основной специализацией он очень сильно устаёт и перестаёт чувствовать себя занятым профессиональной деятельностью.
У вас в статье не раскрыты моменты с тем, как требования доходят до тестеров.
PO вынужден 2 раза объяснять story или все ходят на все митинги?
Если следовать Scrum, то тестер должен быть в одной команде с разработчиком, они же делают общее дело. При этом их число должно быть примерно 2 к 1, т.е. 1 тестер на 2х разработчиков.
У Вас выходит, что тестеры хотели развиваться в разработке, а вы им не дали?
Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.
PO вынужден 2 раза объяснять story или все ходят на все митинги?
Если следовать Scrum, то тестер должен быть в одной команде с разработчиком, они же делают общее дело. При этом их число должно быть примерно 2 к 1, т.е. 1 тестер на 2х разработчиков.
У Вас выходит, что тестеры хотели развиваться в разработке, а вы им не дали?
Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.
У вас в статье не раскрыты моменты с тем, как требования доходят до тестеров.
PO вынужден 2 раза объяснять story или все ходят на все митинги?
Когда PO рассказывает стори, присутствуют все заинтересованные: команда, которая будет стори делать, и представитель команды тестирования, который будет эту стори прорабатывать и в дальнейшем заниматься ее тестированием. В проработку стори входит состявление карты тестирования и проработка конкретных тестов. Кроме того через ответственного тестировщика идут все документы по этой стори: технические проекты, изменения и т.д.
У Вас выходит, что тестеры хотели развиваться в разработке, а вы им не дали?
Почему не дали, как раз наоборот. Один из тестировщиков стал в итоге полноценным разработчиком, вполне успешно работает сейчас в команде.
Все же ситуации, когда тестировщик развивается в разработке (пишет автоматические тесты, какие то скрипты и т.д.), и когда он становится полноценным разработчиком, несколько разные. У нас тестировщики в итоге хотели стать полноценными разработчиками и уйти из тестирования в принципе.
Ну и, чтобы тестировщик хорошо вписался в команду, он должен быть матерым спецом. Нужно это, чтобы его просто не задавили в команде авторитетом и знаниями. На момент организации команд и организации тестирования ребята у нас были в большинстве своем не такими опытными. Если следовать scrum, то люди должны быть с очень неплохими скилами, поэтому тут мы несколько отошли от концепции.
Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.
Вообще автоматические тесты у нас пишут и разработчики, и тестировщики. Причем они независимы. Сделано так, чтобы не было «Этот функционал все равно у тестировщиков покрывается, тест писать не будем». Прогон автотестов от разработчиков был и до организации команды тестирования, технологии для этого уже были отработаны. Так что нет, нам нужна была именно команда тестирования, которая будет тестировать конкретные пользовательские кейсы.
Какие тесты пишут разработчики, тоже функциональные? В статье вы говорили, что у вас есть тестировщики, которые занимаются именно автоматизацией, зачем тогда разработчикам тратить время на написание тестов?
Разработчики пишут функционаольные невизуальные тесты на внутренние механизмы и иногда модульные тесты. Эти тесты гоняются при каждом чекине и предназначены для быстрой проверки что в системе ничего не сломали. Результат приходит очень быстро и разработчики сразу могут поправить функционал.
Тестировщики пишут функциональные-UI тесты для имитаций реальных действий пользователей и нефункциональные тесты (время выполнения действий, трафик, количество запросов и т.д.). Ограниченное число этих тестов гоняется на стенде все время, результат от такого прогона приходит за 2-3 часа. Все тесты команды тестирования гоняются ночью и результаты известны на следующий день.
Тестировщики пишут функциональные-UI тесты для имитаций реальных действий пользователей и нефункциональные тесты (время выполнения действий, трафик, количество запросов и т.д.). Ограниченное число этих тестов гоняется на стенде все время, результат от такого прогона приходит за 2-3 часа. Все тесты команды тестирования гоняются ночью и результаты известны на следующий день.
Об организации тестирования в команде, сделавшей отличный продукт.
Инженеры по тестированию — часть команды разработки, где также есть системный аналитик, системный инженер и два инженера технической поддержки. Сначала соотношение было 0 к 1-му, потом 2 к 7-ми, сейчас 3 человека занимаются тестированим и 11 разработкой. Большой кабинет, общий митинг. Требования уточняются у системного аналитика и группы аналитики.
Важнейший вид тестирования — функциональное тестирование, автотесты на основные сценарии. Тестирование по требованиям и исследовательское. Тесты пишутся для сценариев, проверенных сейчас и которые стоит проверять в будущем. Из нефункциональных видов: нагрузочное, защищённости, конфигурационное.
Группа разработки — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие различными знаниями, навыками. Обмен знаниями повсечастный.
Инженеры по тестированию — часть команды разработки, где также есть системный аналитик, системный инженер и два инженера технической поддержки. Сначала соотношение было 0 к 1-му, потом 2 к 7-ми, сейчас 3 человека занимаются тестированим и 11 разработкой. Большой кабинет, общий митинг. Требования уточняются у системного аналитика и группы аналитики.
Важнейший вид тестирования — функциональное тестирование, автотесты на основные сценарии. Тестирование по требованиям и исследовательское. Тесты пишутся для сценариев, проверенных сейчас и которые стоит проверять в будущем. Из нефункциональных видов: нагрузочное, защищённости, конфигурационное.
Группа разработки — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие различными знаниями, навыками. Обмен знаниями повсечастный.
Sign up to leave a comment.
Группа тестирования в Scrum-проекте