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