Насколько я знаю такое решение помогает самому приложению (WCF подхватывает проксик), и возможно если приложение уже установлено.
Если у вас чистая машина, то пробиться через проксик не получится, потому что стандартный dfsvc.exe это не умеет, а свой код на машину вы еще не закачали.
Есть решение с тем чтобы перебить стандартный загрузчик ClickOnce. Но оно мне не нравится, поскольку убивает на корню всю прелесть ClickOnce установки, т.к. надо по сути патчить .NET.
Причем, проблема довольно старая и до сих пор не поправлена, хотя фикс вроде не сложный совсем.
Разработчики пишут функционаольные невизуальные тесты на внутренние механизмы и иногда модульные тесты. Эти тесты гоняются при каждом чекине и предназначены для быстрой проверки что в системе ничего не сломали. Результат приходит очень быстро и разработчики сразу могут поправить функционал.
Тестировщики пишут функциональные-UI тесты для имитаций реальных действий пользователей и нефункциональные тесты (время выполнения действий, трафик, количество запросов и т.д.). Ограниченное число этих тестов гоняется на стенде все время, результат от такого прогона приходит за 2-3 часа. Все тесты команды тестирования гоняются ночью и результаты известны на следующий день.
У вас в статье не раскрыты моменты с тем, как требования доходят до тестеров.
PO вынужден 2 раза объяснять story или все ходят на все митинги?
Когда PO рассказывает стори, присутствуют все заинтересованные: команда, которая будет стори делать, и представитель команды тестирования, который будет эту стори прорабатывать и в дальнейшем заниматься ее тестированием. В проработку стори входит состявление карты тестирования и проработка конкретных тестов. Кроме того через ответственного тестировщика идут все документы по этой стори: технические проекты, изменения и т.д.
У Вас выходит, что тестеры хотели развиваться в разработке, а вы им не дали?
Почему не дали, как раз наоборот. Один из тестировщиков стал в итоге полноценным разработчиком, вполне успешно работает сейчас в команде.
Все же ситуации, когда тестировщик развивается в разработке (пишет автоматические тесты, какие то скрипты и т.д.), и когда он становится полноценным разработчиком, несколько разные. У нас тестировщики в итоге хотели стать полноценными разработчиками и уйти из тестирования в принципе.
Ну и, чтобы тестировщик хорошо вписался в команду, он должен быть матерым спецом. Нужно это, чтобы его просто не задавили в команде авторитетом и знаниями. На момент организации команд и организации тестирования ребята у нас были в большинстве своем не такими опытными. Если следовать scrum, то люди должны быть с очень неплохими скилами, поэтому тут мы несколько отошли от концепции.
Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.
Вообще автоматические тесты у нас пишут и разработчики, и тестировщики. Причем они независимы. Сделано так, чтобы не было «Этот функционал все равно у тестировщиков покрывается, тест писать не будем». Прогон автотестов от разработчиков был и до организации команды тестирования, технологии для этого уже были отработаны. Так что нет, нам нужна была именно команда тестирования, которая будет тестировать конкретные пользовательские кейсы.
У нас и нет выделенного отдела, у нас есть команда тестирования. Команда нужна чтобы в целом развивались технологии тестирования, чтобы знания передавались, аккумулировались. Получилась некая сервисная команда, которую ни scrum, ни agile в принципе не отвергают. Например, те же Devops может вполне работать в scrum оказывая услуги по разворачиванию.
Если у вас чистая машина, то пробиться через проксик не получится, потому что стандартный dfsvc.exe это не умеет, а свой код на машину вы еще не закачали.
Есть решение с тем чтобы перебить стандартный загрузчик ClickOnce. Но оно мне не нравится, поскольку убивает на корню всю прелесть ClickOnce установки, т.к. надо по сути патчить .NET.
Причем, проблема довольно старая и до сих пор не поправлена, хотя фикс вроде не сложный совсем.
Тестировщики пишут функциональные-UI тесты для имитаций реальных действий пользователей и нефункциональные тесты (время выполнения действий, трафик, количество запросов и т.д.). Ограниченное число этих тестов гоняется на стенде все время, результат от такого прогона приходит за 2-3 часа. Все тесты команды тестирования гоняются ночью и результаты известны на следующий день.
Когда PO рассказывает стори, присутствуют все заинтересованные: команда, которая будет стори делать, и представитель команды тестирования, который будет эту стори прорабатывать и в дальнейшем заниматься ее тестированием. В проработку стори входит состявление карты тестирования и проработка конкретных тестов. Кроме того через ответственного тестировщика идут все документы по этой стори: технические проекты, изменения и т.д.
Почему не дали, как раз наоборот. Один из тестировщиков стал в итоге полноценным разработчиком, вполне успешно работает сейчас в команде.
Все же ситуации, когда тестировщик развивается в разработке (пишет автоматические тесты, какие то скрипты и т.д.), и когда он становится полноценным разработчиком, несколько разные. У нас тестировщики в итоге хотели стать полноценными разработчиками и уйти из тестирования в принципе.
Ну и, чтобы тестировщик хорошо вписался в команду, он должен быть матерым спецом. Нужно это, чтобы его просто не задавили в команде авторитетом и знаниями. На момент организации команд и организации тестирования ребята у нас были в большинстве своем не такими опытными. Если следовать scrum, то люди должны быть с очень неплохими скилами, поэтому тут мы несколько отошли от концепции.
Вообще автоматические тесты у нас пишут и разработчики, и тестировщики. Причем они независимы. Сделано так, чтобы не было «Этот функционал все равно у тестировщиков покрывается, тест писать не будем». Прогон автотестов от разработчиков был и до организации команды тестирования, технологии для этого уже были отработаны. Так что нет, нам нужна была именно команда тестирования, которая будет тестировать конкретные пользовательские кейсы.