Есть небольшая проблема: учебник не по тестированию. В первых семи из ста блоков тестирование не упоминается вообще. Это очередная попытка собрать и коротенько описать все знания отрасли, что по определению провальная затея.
Если эту статью прочел начинающий, мой совет: вместо этого учебника, по верхам бегающего по всем темам, лучше основательно заняться темами, на которые в нем есть обзор: DBA, архитектура nix систем, программирование и многое-многое другое. По каждой из этих тем есть приличные обучения, книги, курсы.
Очень удобно не называть компанию, можно придумывать всякое.
Классная фразеология и нагнетание: "подшивают в дело", "отряд", " агитпроп"
Нестыковки в сюжете. Так поступать выйдет разве что с джунами, которые другого мира не видели, и с другими людьми не общаются, и от интернета их отключили... Система сломалась бы еще на этапе "попытаться загрузить большим количеством разных проектов с разным контекстом". А со встречи с "отрядом" взрослый специалист вышел бы, весело хохоча.
Кажется, история выросла из нескольких случаев, когда не очень сильным сотрудникам три руководителя зараз предметно объясняли, почему им не повысят зарплату в ответ на шантаж уходом. Со стороны сотрудника это действительно могло выглядеть как нападение целым отрядом.
Кажется, я понял, где у нас возникло недопонимание. Есть этапы: тест задачи и тест релиза. Мой вопрос был — почему красными тестами не занимаются на этапе теста задачи?
В том, что нестабильные тесты не должны держать релиз, я с вами соглашусь. Кстати, вы так и не сказали, сколько их.
Постойте, я же не говорю про отсутствие багов. Я говорю про красные тесты. Разве перед выпуском фичи нельзя исправить ошибки, уже найденные тестами и поднять тесты? Или с таким темпом это проблематично?
Проверку релиза мы начинаем с проверки автотестов и скринтестов.
То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?
Кстати, а какой процент стабильности тестов? Сколько упадут случайно на прогон?
Сколько времени занимает полный ручной регресс? Как часто он используется?
Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?
Как выяснилось, мероприятия подобного рода в РФ проводили не так много раз, и идей позаимствовать негде.
Важное качество тестировщика — внимательность.
Из действующих сейчас: ежегодные соревнования тестировщиков на Урале, уже восемь, предпоследнее проходило одновременно в трех городах: Питере, Екб и Новосибе. В 2019 году было уже три соревнования. О них рассказывали на конференциях, Дампе и Течтрейне.
Лет семь назад такое часто было в Питере, делало сообщество. Пару лет назад активно продвигался testathon.
С организаторами всего перечисленного несложно связаться и они с радостью расскажут о том, как делать такие штуки.
Кристина, побейте того, кто рекомендовал вам книги по профессии. Из четырех только один приличный автор (я о Канере), и то у него есть более приличные и актуальные книги.
Расскажу немного «секретной» информации о собеседованиях на тестировщика.
А где «секретная» информация?
Тогда в проекте только зарождалось автотестирование
А как обстоят дела сейчас с автоматизацией? Очень интересно.
Автор оправдывает атмосферу расслабленности и вялости
А я видел, как демотивирует и замедляет разработку ваш подход и тоже страдаю, когда вижу спринтеров с горящими жопамии, не умеющими играть дольше, чем в год.
Александр, наш спор на уровне мировоззрений и ни к чему не приведет. Аргументы вида «вот оно так потому что вы демотивируете!»
Вы будете оценивать сроки и считать свои команды крутыми и успешными. Я оценивать сроки не буду и тоже буду считать свои команды крутыми и успешными. Чистый эксперимент поставить не получится. Зрители повеселятся.
А контур, конечно да, ничего не создал и ничего не запустил и вообще на ладан дышит. Скорее всего из-за такого подхода. Всё плохо.
Еще и еще раз. Я говорю о том, что нужно спрашивать не срок, а упражнения из списка. Они полезны. Срок ложь.
По поводу мотивации, убитой сроками оценки — и опять не так. В моей и не только команде с мотивацией все ок. И она не зависит от коммита в дату. Зачем вы безапелляционно обобщаете? Прямо как я в заголовке. А еще я знаю команды, демотивированные необходимостью играть в сроки.
И да. Контур я тоже люблю.
Есть небольшая проблема: учебник не по тестированию. В первых семи из ста блоков тестирование не упоминается вообще. Это очередная попытка собрать и коротенько описать все знания отрасли, что по определению провальная затея.
Если эту статью прочел начинающий, мой совет: вместо этого учебника, по верхам бегающего по всем темам, лучше основательно заняться темами, на которые в нем есть обзор: DBA, архитектура nix систем, программирование и многое-многое другое. По каждой из этих тем есть приличные обучения, книги, курсы.
Очень удобно не называть компанию, можно придумывать всякое.
Классная фразеология и нагнетание: "подшивают в дело", "отряд", " агитпроп"
Нестыковки в сюжете. Так поступать выйдет разве что с джунами, которые другого мира не видели, и с другими людьми не общаются, и от интернета их отключили... Система сломалась бы еще на этапе "попытаться загрузить большим количеством разных проектов с разным контекстом". А со встречи с "отрядом" взрослый специалист вышел бы, весело хохоча.
Кажется, история выросла из нескольких случаев, когда не очень сильным сотрудникам три руководителя зараз предметно объясняли, почему им не повысят зарплату в ответ на шантаж уходом. Со стороны сотрудника это действительно могло выглядеть как нападение целым отрядом.
В том, что нестабильные тесты не должны держать релиз, я с вами соглашусь. Кстати, вы так и не сказали, сколько их.
И ещё. Если тестировщик дежурит и занимается релизами — на сколько он выпадает из тестирования текущих задач? Это не проблема?
То есть задача в релиз может попасть с красными тестами? Зачем допускать такие задачи к релизу?
Кстати, а какой процент стабильности тестов? Сколько упадут случайно на прогон?
Сколько времени занимает полный ручной регресс? Как часто он используется?
Ручной тестировщик разбирает упавшие тесты? Почему этого не делает программист? Как вы пришли к этому решению?
Правильно ли я понял, что 5 в неделю?
А что рассказать?
А о чем статья? Вы написали тесты?
Важное качество тестировщика — внимательность.
Из действующих сейчас: ежегодные соревнования тестировщиков на Урале, уже восемь, предпоследнее проходило одновременно в трех городах: Питере, Екб и Новосибе. В 2019 году было уже три соревнования. О них рассказывали на конференциях, Дампе и Течтрейне.
Лет семь назад такое часто было в Питере, делало сообщество. Пару лет назад активно продвигался testathon.
С организаторами всего перечисленного несложно связаться и они с радостью расскажут о том, как делать такие штуки.
А где «секретная» информация?
А как обстоят дела сейчас с автоматизацией? Очень интересно.
Только потому, что вы так считаете?
Без сроков нельзя брать ответственность?
Команды офигенные, работают бодро. Спорить о степени крутости и обсуждать мощь продуктов я не буду.
Кстати, чем похвастаете вы?
Наверное хорошо, что теперь эти сотни разработчиков вместе с тестировщиками делают крутые штуки с драйвом, но без вас.
А я видел, как демотивирует и замедляет разработку ваш подход и тоже страдаю, когда вижу спринтеров с горящими жопамии, не умеющими играть дольше, чем в год.
Александр, наш спор на уровне мировоззрений и ни к чему не приведет. Аргументы вида «вот оно так потому что вы демотивируете!»
Вы будете оценивать сроки и считать свои команды крутыми и успешными. Я оценивать сроки не буду и тоже буду считать свои команды крутыми и успешными. Чистый эксперимент поставить не получится. Зрители повеселятся.
А контур, конечно да, ничего не создал и ничего не запустил и вообще на ладан дышит. Скорее всего из-за такого подхода. Всё плохо.
Еще и еще раз. Я говорю о том, что нужно спрашивать не срок, а упражнения из списка. Они полезны. Срок ложь.
По поводу мотивации, убитой сроками оценки — и опять не так. В моей и не только команде с мотивацией все ок. И она не зависит от коммита в дату. Зачем вы безапелляционно обобщаете? Прямо как я в заголовке. А еще я знаю команды, демотивированные необходимостью играть в сроки.
И да. Контур я тоже люблю.
Автор совсем не такой, как вы описываете… Автор специально привел ссылки на источники в начале, где есть объяснения. В частности перезакладывания.
Кажется, я чем то задел ваши эмоции и этим вызвал кучу толкований меня и достаточно резких высказываний.
Думаю, конструктивно не получится, а жаль.
"Без оценки сроков бизнес просто умрет."
Что же вы пишете про все бизнесы сразу? Жил, живет и будет жить бизнес и без оценки сроков. И речь не только про контур.
Дальше вы делаете ряд заявлений и претензий, отвечая на которые я буду доказывать, что я не верблюд.
Ответственность с разработки я снимать не предлагаю. Предлагаю перестать обманывать. Себя в первую очередь.