погугли как под непетю попали крупные датацентры в сша

Та че ты приципился к Пете? будто других вариантов нет проипать инфу.

Вообще никак, какой смысл тогда его как пойнт валидный выставлять

А если атомный взрыв?

Это никак не выделяет другие варианты выгодно хранения тестов

доступность и удобство

единая база

Непетя или ransomware одинаково нагнет любую слабозащищенную инфраструктуру

версионирование в базе

прямой досту, а не через одну тулу на другую

это выделяет

Будь то твой TFS

Или файл в гите

так как экономит время, а время это деньги

Every tool for the right job.

файл в гите требует гита, акка в гите, локального синка, тулзы для работы с файлом

Be as small as you can

Не нужно тащить монструозный тфс туда, где можно обойтись гуглодоками

Не нужно тащить монструозный тфс туда, где можно обойтись гуглодоками

можно, смотря какая цель

Можно, но не нужно. Цель не принимать решения за которые потом придётся платить много «. В реальности не видел проблем с тем, что на проекте мои тест кейсы были в экселе, а не в тфс :₽

гуглодоки для коммерческого использования (если компания думает о защите бизнес данных) тоже стоят денег

тулза - это средство

изнчала была речь о перенести чеклист

Окей, гуглодоки не нужны, я уточню : Эксель в гите

вот и вопрос - зачем

Окей, гуглодоки не нужны, я уточню : Эксель в гите

а это уже извращение просто )))

разве что ты один тестировщик в команде

Нет , не извращение . Оппонируй!

Нет , не извращение . Оппонируй!

на тренинге болтона, потом

но писал уже

Вопрос не в только в хранение сейчас.Человек ушел - гуглдок улетел.Гугл док неподконтролен компании в принципе. Информация в тесткейсах может не иметь разрешения на хранения извне.

Вопрос не в только в хранение сейчас.Человек ушел - гуглдок улетел.Гугл док неподконтролен компании в принципе. Информация в тесткейсах может не иметь разрешения на хранения извне.

ну это техническая проблема, хранить на клауде ок

речь не про личный акк, ессесно

Да и в топку гуглодоки, суть в чем: нужно выбирать тул исходя из размера проблемы с тесткейсами

Да и в топку гуглодоки, суть в чем: нужно выбирать тул исходя из размера проблемы с тесткейсами

нет, исходя их задачи, которую нужно решить в принципе

написать кейсы

TFS тащить в компанию из 10 человек — нужно быть ярым мазохистом, например

конвертировать кейсы

иметь кейсы вообще - не задача, а средство

Не обязательно мазохистом.Если задачам компании отвечает ТФС - значит можно.Я видел что тащили в компанию и из 5 человек.

речь не про личный акк, ессесно

Объяснить бы это остальным)

был в компании из 10 человек, где юзали ТФС

Когда начинается обсуждение какой инструмент лучше,все резко начинают забывать про банальную безопасность данных,bus фактор и тд.С таким же успехом я могу сказать что Jira для больших компаний - мазахизм еще больший

Когда начинается обсуждение какой инструмент лучше,все резко начинают забывать про банальную безопасность данных,bus фактор и тд.С таким же успехом я могу сказать что Jira для больших компаний - мазахизм еще больший

А вы сравнивали безопасность данных jira vs crocagile? Я бы послушал. Или при чем тут бас фактор, например

Вот пример.Компания живет на ТФС локальном.А одному начальнику не понравилось и он перевел свой отдел на свой облачный VSTS. Дальше продолжать?)

Ну, продолжите, чай, тут не все телепаты и умеют читать мысли

Вы конечно уповаете на то, что облако это дефакто не секьюрно? А что если ваши dba / админы не умеют делать бэкапы TFS или умеют их похерить? Что если аптайм локальных серверов настолько хуже облака, что надеяться на сходимости этих SLA не придётся даже за 10 лет? Выбор средств разработки — это вопрос доверия и соответствия требованиям. Из того что начальник выбрал vsts — нет никаких моментальных выводов

Давайте говорить честно, в большинстве случаев тестирование использует инфраструктуру, которая есть у разработчиков. И обычно тестирование в численном меньшинстве. Так что используешь то же, что и разработчики, а если тебе под свои какие-то нужды - выбираешь рабочее решение, которое можно реализовать минимальными силами.

Я с трудом представляю ситуацию, когда в компанию поташат TFS только для тестирования.

Давайте говорить честно, в большинстве случаев тестирование использует инфраструктуру, которая есть у разработчиков. И обычно тестирование в численном меньшинстве. Так что используешь то же, что и разработчики, а если тебе под свои какие-то нужды - выбираешь рабочее решение, которое можно реализовать минимальными силами.

Так и есть, иногда могут купить тебе TestRail ещё и включить его в ci/cd

Но пока нет — можно отлично жить и с эксельками, хотите эксельки в облаке? Рассчитывайте риск потери данных, придумывайте аккаунты и репликацию данных, чтобы уход Пети не поставил работу раком

Пока он не покинет компанию. И не заберет учетку с собой.Это не вопрос доверия только. Если дба админы не умеют делать бэкапы,то они банально не дба админы.Так же как и админы. Бэкап бд не умеет делать только ленивый и эникейщик. Аптайм локальных серверов - это к Джире , это она только требует к себе особого обращения, так как джава машина любвеобильна во все времена. А по поводу TFS только для тестирования да. Но его возьмут для разрабов с заделом на будущее

Не хотите эксельки в облаке? Эксельки в офлайне. Риски? Невозможность одновременной работы. Придумайте флоу когда решаются разные задачи разными тестировщиками

Как заставить программистов проверять свой код хотя бы минимально, что результат хотя бы запускается. Прежде чем они отсылают свою хрень QA?

Пока он не покинет компанию. И не заберет учетку с собой.Это не вопрос доверия только. Если дба админы не умеют делать бэкапы,то они банально не дба админы.Так же как и админы. Бэкап бд не умеет делать только ленивый и эникейщик. Аптайм локальных серверов - это к Джире , это она только требует к себе особого обращения, так как джава машина любвеобильна во все времена. А по поводу TFS только для тестирования да. Но его возьмут для разрабов с заделом на будущее

Что значит не заберёт учётку с собой? Можете объяснить на примере? И почему например при этом он юридически не начинает нести за это ответственность

Как заставить программистов проверять свой код хотя бы минимально, что результат хотя бы запускается. Прежде чем они отсылают свою хрень QA?

запретить вливать бранчи в продакш или мастер ветку пока не пройдут все тесты)

TDD же

запретить вливать бранчи в продакш или мастер ветку пока не пройдут все тесты)

А если это trunk based development?

У нас под каждую таску своя бранч. В мастер заливается только перед самим уже релизом

С чегойто?Какую юридическую ответственность?) Все зависит от NDA а NDA порой дырявое.Потому что забрать учетку не означает забрать данные.Данные потерялись - поди докажи что он преднамеренно сделал это. Замучаешься запросы делать в майкро и остальным

trunk - и этим все сказано

С чегойто?Какую юридическую ответственность?) Все зависит от NDA а NDA порой дырявое.Потому что забрать учетку не означает забрать данные.Данные потерялись - поди докажи что он преднамеренно сделал это. Замучаешься запросы делать в майкро и остальным

Какой-то зоопарк, есть ещё фирмы где такое происходит?

Есть что самое забавное.Есть без NDA фирмы.Есть фирмы, где права выдают руководители отделов в систему, а не через доменку и тд.Где сиквеля голыми задницами торчат наружу)У каждой фирмы есть свой зоопарк)

У нас под каждую таску своя бранч. В мастер заливается только перед самим уже релизом

у нас аналогично под каждую таску свой бранч, но релиз как таковой может быть в любое время, хоть каждый день или несколько раз в день. и доступы на мерж закрыты у всех, кроме учетки, которая подцеплена в дженкинсе. влить можно только через него и только когда пройдут все тесты, в том числе и те, которые разработчик обязан написать/поправить на тот код, который он добавил/изменил

это в целом замедляет скорость разработки, зато сильно повышает скорость доставки на прод, так как тестирование уже проведено

У нас нет юнитов. А по правам так же

причем тут юниты? юниты юнитами, а обычные тесты так же гонятся на каждый чих

Поискать другую компанию я бы советовал

Это всегда отличный план)

Не всегда

Нет идеальных компаний)нет идеальных процессов)

Я с трудом представляю ситуацию, когда в компанию поташат TFS только для тестирования.

мы используем СилкЦентрал дла тесткейсов и автотестов и коннектим к джире, стоимость выше ТФС

Как заставить программистов проверять свой код хотя бы минимально, что результат хотя бы запускается. Прежде чем они отсылают свою хрень QA?

никак, нужно договориться и объяснить почему это увеличит тестируемость продукта

заставить нельзя

мы используем СилкЦентрал дла тесткейсов и автотестов и коннектим к джире, стоимость выше ТФС

Я так понимаю, это специализированное средство для тестов. Это уже немного другая весовая категория. TFS это скорее "all inclusive" решение для всего.

Я так понимаю, это специализированное средство для тестов. Это уже немного другая весовая категория. TFS это скорее "all inclusive" решение для всего.

ты можешь, если я не ошибаюсь, купить только лицуху для тестменеджера

но да, это может быть нецелесообразно

потому нужно вернуться к вопросу - какая цель, какую проблему нужно решить?

потому нужно вернуться к вопросу - какая цель, какую проблему нужно решить?

На тестирование прилетает багованый продукт с неработающим кодом. Т.е. иногда даже пытаться ломать нечего, потому что это не запускается. Кидание таски туда сюда и проверка поломано ли реально занимает кучу ненужного времени

На тестирование прилетает багованый продукт с неработающим кодом. Т.е. иногда даже пытаться ломать нечего, потому что это не запускается. Кидание таски туда сюда и проверка поломано ли реально занимает кучу ненужного времени

Можно, конечно, биться головой об стену, и долго, упорно и постоянно всем объяснять, чем такой подход плох, и как сделать лучше. Но если кроме вас это никого не волнует, и у вас не права "навязать свои правила" - то скорее всего это никак не решить.

Стоит просто начать итальянскую забастовку))

На тестирование прилетает багованый продукт с неработающим кодом. Т.е. иногда даже пытаться ломать нечего, потому что это не запускается. Кидание таски туда сюда и проверка поломано ли реально занимает кучу ненужного времени

Пишите чеклист для разработчика, который он должен пройти прежде чем отдать задачу в тестирование

На тестирование прилетает багованый продукт с неработающим кодом. Т.е. иногда даже пытаться ломать нечего, потому что это не запускается. Кидание таски туда сюда и проверка поломано ли реально занимает кучу ненужного времени

...иногда даже пытаться ломать нечего... Хорошие цели тестирования)))))

Пишите чеклист для разработчика, который он должен пройти прежде чем отдать задачу в тестирование

Да беда в том, что они такие "да-да, всё проверили ,посмотрели". Но нет.

...иногда даже пытаться ломать нечего... Хорошие цели тестирования)))))

Ну так))

Да беда в том, что они такие "да-да, всё проверили ,посмотрели". Но нет.

Что всё? Конкретные проверки им пишите

На тестирование прилетает багованый продукт с неработающим кодом. Т.е. иногда даже пытаться ломать нечего, потому что это не запускается. Кидание таски туда сюда и проверка поломано ли реально занимает кучу ненужного времени

и как ты решишь это тесткейсами?

Да беда в том, что они такие "да-да, всё проверили ,посмотрели". Но нет.

Для таких вещей может помочь идея нажимать вместо одной копки— другую. Только сегодня и только сейчас! Кнопка, запускающая смоук тест, не пропустите! Не нажмется, если к фиче нет смоук тест файла / юнит теста! Феерично! Безотказно! P.s если дело в забывчивости, то только при помощи автоматизации процесса и контроля формальных требований можно избавиться от банально неработающих билдов

Пока не пофиксит — такие билды не должны попадать в тестирование

Пока не пофиксит — такие билды не должны попадать в тестирование

да, вот такие задачи кейсы решают

Но с наплевательским отношением в любом случае далеко не уехать

Но с наплевательским отношением в любом случае далеко не уехать

+++

Да беда в том, что они такие "да-да, всё проверили ,посмотрели". Но нет.

Это вопрос к процессам в компании, прожигание ресурсов и отсутствие нормального воркфлоу. Это решается не на уровне qa. А лидов, руководителей и т.д.

Но с наплевательским отношением в любом случае далеко не уехать

опять же, наплевательство на аспекты чего либо может означать что либо аспекты невалидны, либо есть смысл подумать о том, чтобы эти аспекты кетчились теми, кому они важны

Это вопрос к процессам в компании, прожигание ресурсов и отсутствие нормального воркфлоу. Это решается не на уровне qa. А лидов, руководителей и т.д.

Я бы поспорил , я как QA даю фидбек , что мне в sdlc не нравится и замедляет процесс / делает его ошибкоопасным. Предлагаю решение, дальше уже идёт обсуждение (горизонтальное с коллегой-коллегами, если это не порождает сложностей ; если не получается , то вертикальное , начальству)

В здоровом коллективе который завязан на каком-то процессе сообщать и предлагать идеи оптимизации может любой. Потому что это и его боль отчасти. Дальше уже зависит от менеджмента, как будет выделяться ресурс на оптимизацию и как будет ответственность назначаться