Немного некорректно использование термина actor, потому что оно употребляется при использование use cases. User story не просто так названа, мы говорим именно про пользователя, потому что за ним скрывается человек, понять которого нам предстоит.
Кроме того, если вы говорите про экспертов, то хотелось бы видеть экспертов именно в agile.
К кнопкам никаких претензий нет, а вот Express Checkout все таки немного муторная штука. В случае реальных товаров нужно же собирать, например, адрес доставки, и тут начинается…
Нет, на хабре анонса мы не делали, только на сайте agile russia и в одноименной группе на facebook. Плюс в том, что мы эту встречу проводим регулярно, следующая возможно будет в январе-феврале
о, а по какому принципу у вас строится exploratory тестирование? SBTM или что-то свое? Как я понимаю, на вход помимо всего тестировщики получают и скетчи?
Спасибо за статью, но она все же спорная, потому что очень категоричная, даже для меня =)
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.
Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?
Часть вещей я не написал потому что это секрет фирмы =) В первую очередь это касается того, как мы проводим анализ и определяем текущий уровень компании. Модель строится на существующих в индустрии практиках. Например, когда мы говорим о разработке это касается следующих параметров:
наличие VCS и как с ним идет работа
практики тестирования (unit, integration,...)
работа с Continuous Integration
гибкость архитекутры
качество кода
и так далее
Если говорит об анализе, то нас интересует как именно команда работает на требованиями, как они строят видение продукта и прочее.
По большому счету правильнее назвать наш процесс assessment`ом, но так уж вышло что прицепилось слово аудит.
Как я писал — у нас есть внутренняя модель зрелости компаний с 7 показателями. Ключевым критерием является то, как быстро команда может реализовывать идеи бизнесы и доносить их до клиента. Отсюда собственно и вытекают метрики и критерии.
Обычно, мы обговариваем набор метрик, по котором и видно, как происходит работы. Обратную связь мы собираем постоянно, потому что цель не отсидеть часы и сделать только то, что в них описано, а решить насущные проблемы.
Тогда нужно слушать вот этот доклад, это именно про DevOps для java в российском проекте для ростелекома.
Или тот же HeadHunter тоже исповедует принципы devops
Это был один из самых первых проектов для меня. Писали систему для шедулинга (создание расписания для логистики в данном случае), а эта система отвечала в компании заказчика за внутреннюю бюрократию — счета, платежи и так далее. Так и работали — мы делаем расписание и считаем стоимость перевозок и если ок, то пользователь нажимал большую кнопку и генерировались нужные документы. Надо сказать, что система работала на редкость стабильно.
Мы использовали страйп до 2017 и основных проблемы с нашей стороны были такие:
У них нет интеграции с PayPal
На тот момент у них был очень глупый механизм восстановления непрошедих платежей
Только один процессор, который нельзя поменять - FirstData
И самое главное - очень бедный репортинг, почему не прошел платеж
Кроме того, если вы говорите про экспертов, то хотелось бы видеть экспертов именно в agile.
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.
Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?
Если говорит об анализе, то нас интересует как именно команда работает на требованиями, как они строят видение продукта и прочее.
По большому счету правильнее назвать наш процесс assessment`ом, но так уж вышло что прицепилось слово аудит.
Или тот же HeadHunter тоже исповедует принципы devops