Comments 17
Ручной тестировщик или точнее человек пишущий сценарии для ручных тестировщиков (их можно нанимать по пять копеек за пучок) это часто единственный человек на проекте знающий как на самом деле должны работать и взаимодействовать друг с другом все фичи. Со стороны пользователя.
Разработчики таким знанием как правило не обладают. Да и зачем оно нам?
Джейсон переложен качественно. Интеграционные тесты написаны прилично и потверждают что джейсон переложен качественно, а все падения правильные и предусмотренные. Отстаньте на этом от меня.
Если вылезет что джейсон перекладывается не так как надо (в жизни всякое бывает) приходите. Поправлю и добавлю тест и на этот случай. Или не приходите. Код хороший и любой из команды поправит.
А вот бас фактор надо поднимать. Настю в помощь к Кате наймите что ли.
Разработчики таким знанием как правило не обладают. Да и зачем оно нам?
Джейсон переложен качественно. Интеграционные тесты написаны прилично и потверждают что джейсон переложен качественно, а все падения правильные и предусмотренные. Отстаньте на этом от меня.
Если вылезет что джейсон перекладывается не так как надо (в жизни всякое бывает) приходите. Поправлю и добавлю тест и на этот случай. Или не приходите. Код хороший и любой из команды поправит.
А вот бас фактор надо поднимать. Настю в помощь к Кате наймите что ли.
Ручной тестировщик или точнее человек пишущий сценарии для ручных тестировщиков (их можно нанимать по пять копеек за пучок)…Раздувание количества людей в команде не идет на пользу — рабочие встречи на большее количество участников начинают идти медленнее, появляются роли модераторов встреч.
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
… это часто единственный человек на проекте знающий как на самом деле должны работать и взаимодействовать друг с другом все фичи. Со стороны пользователя.Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач. Разработчики пользуются спросом на рынке труда, чего не сказать о верстальщиках — можно посмотреть количество вакансий.
Разработчики таким знанием как правило не обладают. Да и зачем оно нам?
Джейсон переложен качественно. Интеграционные тесты написаны прилично и потверждают что джейсон переложен качественно, а все падения правильные и предусмотренные.По опыту, когда тебе приходит ~3 пулл-реквеста в день, не сильно тратишь время, чтобы разобраться с покрытием тестами — для этого надо чуть-чуть, но погрузиться в бизнес-логику решаемой задачи (зачастую это из другой команды).
Анализатор в отчете показал покрытие кода близкое к 100%, и ладно, поэтому подтвердить полноту тестов никто не может, кроме автора пулл-реквеста.
Раздувание количества людей в команде не идет на пользу — рабочие встречи на большее количество участников начинают идти медленнее, появляются роли модераторов встреч.
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
2 человека это прямо такое драматичное увеличение? Два в основном ради бас фактора. Или у вас двух людей не хватит чтобы тест кейсы писать и проверять за остальными то что они там нашли?
А остальных в команду включать не надо. Пусть только с тестированием и общаются.
Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач. Разработчики пользуются спросом на рынке труда, чего не сказать о верстальщиках — можно посмотреть количество вакансий.
Разработчик написал код, сделал тест на него. Я предпочитаю интеграционные, но это не важно. Все, работа окончена.
Проводить регрессию и смотреть не развалится ли случайная фича из-за включения новой фичи это уже не его дело. Развалится может логически, это ни одним тестом не поймаешь.
Проверять а точно ли в финальной сборке все подошло друг к другу как ожидалось и точно ли оно ведет себя так как ожидает пользователь тоже не дело разработчика. Разработчик джейсон правильно переложил, а что там пользователю надо вообще пофиг. Интерфейс приложения разработчик может не открывать месяцами.
Анализатор в отчете показал покрытие кода близкое к 100%, и ладно, поэтому подтвердить полноту тестов никто не может, кроме автора пулл-реквеста.
Такая цифра говорит что вероятно метрику накручивают. Скорее всего специально, потому что за это есть какие-то бонусы. А тесты там проверяют что 2+2=4, а не более реальные случаи что все не взрывается при взаимодействии нескольких систем.
Юнит тесты с покрытием под 100% нужны для тестирования сложных алгоритмов. Вот честно говоря сколько процентов вашего кода это такие алгоритмы? Дай бог пара процентов. Скорее даже меньше.
Остальные 98% кода надо проверять интеграционно. Баги они не в алгоритме круда. А во взаимодейсвии всего со всем.
2 человека это прямо такое драматичное увеличение? Два в основном ради бас фактора. Или у вас двух людей не хватит чтобы тест кейсы писать и проверять за остальными то что они там нашли?Наем дополнительных ручных тестировщиков в ~20 команд — это довольно долгое и затратное мероприятие по уменьшению бас фактора. Быстрее, дешевле и выгоднее для компании вложиться в самотестирование задач разработчиками.
А остальных в команду включать не надо. Пусть только с тестированием и общаются.
Проверять а точно ли в финальной сборке все подошло друг к другу как ожидалось и точно ли оно ведет себя так как ожидает пользователь тоже не дело разработчика.Верно, интеграционное (финальное) тестирование лучше оставлять для QA.
Разработчик джейсон правильно переложил, а что там пользователю надо вообще пофиг. Интерфейс приложения разработчик может не открывать месяцами.Для бэкенда — да, но нынешние приложения это не только бэкенд, есть ещё и фронтенд, который, внезапно, не выйдет сделать с закрытыми глазами.
Юнит тесты с покрытием под 100% нужны для тестирования сложных алгоритмов.А также для подтверждения того, что бизнес-логика компонента работает корректно, несмотря на внесения изменений разными командами.
Раздувание количества людей в команде не идет на пользу — рабочие встречи на большее количество участников начинают идти медленнее, появляются роли модераторов встреч.
Всегда существует вариант не собирать всю толпу, а только лидов для синхронизации, или вовсе отказаться от бюрократических встреч;)
Расширяет широту мысления, прокачивает разработчика — помимо навыков QA, будет более полная декомпозиция будущих проектов, более точные временные оценки задач.
Ну ладно когда из backend пытаются сделать fullstack-программиста, но
Дешевле обучить разработчиков тестированию, нежели увеличивать бюрократию.
вы правда не задумывались о закладываемой мине в виде несовместимости психотипов и образа мышления в программировании и тестировании?
Всегда существует вариант не собирать всю толпу, а только лидов для синхронизации, или вовсе отказаться от бюрократических встреч;)К сожалению, без встреч вроде дейли, ретро, обсуждений требований по проектам — никак.
вы правда не задумывались о закладываемой мине в виде несовместимости психотипов и образа мышления в программировании и тестировании?Цель сделать QA из разработчиков не преследовалась, поэтому проблем никаких нет?
Хм... а я правильно понял, что в новой схеме тестировщики и разработчики снова начали работать отдельно друг от друга?
Большую часть времени — да.
Какие-то взаимодействия теперь в основном на этапах ревью требований, декомпозиции проекта, ревью чеклиста командой и интеграционном тестировании.
Какие-то взаимодействия теперь в основном на этапах ревью требований, декомпозиции проекта, ревью чеклиста командой и интеграционном тестировании.
Какие у Вас прогнозы по срокам, в течение которых разработчики начнут терять скилл тестирования, который они обрели за период совместной работы с тестировщиком?
Прогноза нет, думаю нужно смотреть за метриками — количеством открытых багов, вызванных ошибками в реализации бизнес-логики из существующих требований (не багов, вызванными недоработкой требований).
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
Некоторая синхронизация с QA остается в моменте ревью чеклиста командой, этого должно хватать.
Я смог более конкретно сформулировать, что же именно оставило меня в недоумении после прочтения статьи.
Вопрос: в статье описывается одна модель разработки, которая выручила в сложной ситуации, - совместная работа разработки и тестирования. Но при переходе к выводам говорится: "в итоге мы поменяли нашу схему на..." - и приводится другая модель разработки, где они снова отделены друг от друга. Логика конкретно этого перехода и осталась непонятной. Если не секрет, почему вы решили перейти на третью модель?
Как только в команду придет второй новичок-программист, все начнет медленно и незаметно сыпаться.
По поводу делать продукт быстрее — есть вопросы. Теперь у вас программисты сами тестируют свой код по тест кейсам, сколько на это уходит времени от времени разработки? Не бывает ли такого, что задача условная перекрасить кнопку (со временем разработки полчаса), а тестирование занимает полдня (проверить эту кнопку во всех случаях). Не вырос ли из-за нововведения ФОТ (программисты обычно получают в несколько раз больше чем ручные тестировщики, которые по тест кейсам работают), нет ли жалоб от программистов что им не особо нравится тест кейсы тыкать по 10 раз в день?
Хотелось бы если честно подробностей.
Хотелось бы если честно подробностей.
По поводу делать продукт быстрее — есть вопросы. Теперь у вас программисты сами тестируют свой код по тест кейсам, сколько на это уходит времени от времени разработки?По тест-кейсам тестирования не появилось — ранее до передачи в тестирование, разработчики точно также проверяли свои задачи с каким-то набором входных данных. Расширилось количество наборов — стало больше юнит/интеграционных тестов. Времени к выполнению задачи это прибавило совсем немного, гораздо больше времени тратилось на фиксы после переоткрытия задачи и последующее написание этих же тестов.
…
нет ли жалоб от программистов что им не особо нравится тест кейсы тыкать по 10 раз в день?
Не бывает ли такого, что задача условная перекрасить кнопку (со временем разработки полчаса), а тестирование занимает полдня (проверить эту кнопку во всех случаях).На это должны быть юнит-тесты, которые и проверят кнопку. Если это легаси и тестов нет, то это закладывается в оценку задачи.
Не вырос ли из-за нововведения ФОТ (программисты обычно получают в несколько раз больше чем ручные тестировщики, которые по тест кейсам работают)Вырос, ответ есть в статье.
Очень хороший опыт! Рад что ваша команда разработки тоже смогла стать более самостоятельной и меньше зависеть от других специализаций.
Мы затронем эту тему 30 мая 11.codefest.ru/lecture/1813 в рамках конференции Codefest.
Мы затронем эту тему 30 мая 11.codefest.ru/lecture/1813 в рамках конференции Codefest.
Sign up to leave a comment.
Сколько стоит избавиться от ручного тестирования?