Как минимум с тем, что сложно понимать какие именно ветки для каких сервисов нужно собирать, чтобы подготовить среду тестирования. Помимо этого, у сервиса есть задача решать коммуникационные проблемы в условиях ограниченных ресурсов, более подробно этот процесс описан в сценариях в статье.
Производится тестирование всего блока функционала, затронутого изменениями.
Как вы это отслеживаете? Один кусок кода может затронуть многие места в других участках. неужели вы как-то документируете какие куски кода используете в других?
Важный момент — все сценарии, в том числе групповые, обкатывались на представителях групп внутри компании.
Я правильно понял, что по сути ваши тестировщики теперь должны войти в роль и тестировать приложение, играя роль определенной группы пользователей? Если да, то чем тогда это отличается от конкретных сценариев использования? Зачем делить на группы, если и так одна из задач тестировщика — предусмотреть возможные варианты использования сервиса (которые как раз и включают в себя варианты той или иной группы)?
Вы рассчитываете на тех пользователей, которые уже используют ваш продукт. В комментариях правильно было написано по поводу того, что нет группы пользователей, которые интересуются сервисом и хотят знать о нем больше. Как же расширение аудитории? А может быть еще какие-то группы упущены из виду?
Насколько я знаю, у нас схема работы с заказчиками не такая, что мы предоставляем им отчет о реально затраченном времени и о том, сколько они нам оплатили. В описанной схеме действительно стоит проблема точного учета времени. Но тогда нужно и метрики пересматривать, возможно, что-то новое вводить или убирать старое. В любом случае, это проблема не работы с API, а работы людей с баг-трекерными системами.
Есть и приложение для мобильных устройств, в котором можно так же запускать таймер. Но да, смысла в точном логировании не много — я писал об этом в комментарии выше.
Понятное дело, что до секунды высчитывать сколько ты потратил или как оценил задачу не следует. Но учет времени — это полезное знание, из которого можно сделать определенные выводы.
По мне, не так очевидно. Битрикс хорош для ведения задач в простых ситуациях, например, там нельзя задачам задавать трекер при создании, для создания пользовательских полей потребуется время разработчика на допил, нельзя указать версию, в которой находится задача без каких-то дополнительных усилий. Мы все эти функции тоже используем и они нам необходимы, поэтому битрикс тут явно проигрывает.
Приятно неожиданно встретить земляка на просторах хабра. Немного не в тему вопрос — с каких кафедр посылают учиться заграницу и как организован этот процесс у нас (если есть такая информация, конечно)?
Ну и еще что хотелось бы узнать — я прочитал о том, какие технологии есть для организации работы института, а вот об учебных процессах узнал не очень много. Хочется подробностей о том, как система работает.
Понравилась идея про перезапуск — действительно, иногда тесты падают из-за каких-то левых причин. Однако про создание копии БД — не совсем верно. На нашем последнем проекте результаты выполнения тестов на созданной БД и на реальной отличались, причем заметно. Я не говорю, что создание и работа с тестовой БД — это плохой подход, наоборот. Но стоит учитывать, что пользователи будут работать не с тестовыми данными.
Как минимум с тем, что сложно понимать какие именно ветки для каких сервисов нужно собирать, чтобы подготовить среду тестирования. Помимо этого, у сервиса есть задача решать коммуникационные проблемы в условиях ограниченных ресурсов, более подробно этот процесс описан в сценариях в статье.
Как вы это отслеживаете? Один кусок кода может затронуть многие места в других участках. неужели вы как-то документируете какие куски кода используете в других?
Я правильно понял, что по сути ваши тестировщики теперь должны войти в роль и тестировать приложение, играя роль определенной группы пользователей? Если да, то чем тогда это отличается от конкретных сценариев использования? Зачем делить на группы, если и так одна из задач тестировщика — предусмотреть возможные варианты использования сервиса (которые как раз и включают в себя варианты той или иной группы)?
Вы рассчитываете на тех пользователей, которые уже используют ваш продукт. В комментариях правильно было написано по поводу того, что нет группы пользователей, которые интересуются сервисом и хотят знать о нем больше. Как же расширение аудитории? А может быть еще какие-то группы упущены из виду?
Ну и еще что хотелось бы узнать — я прочитал о том, какие технологии есть для организации работы института, а вот об учебных процессах узнал не очень много. Хочется подробностей о том, как система работает.