По направлению Life у нас 11 разработчиков, 5 аналитиков и 2 гордых тестировщика) Наша команда, а если смотреть чуть шире, то все управление информационных технологий по направлению Life - это "дочка" большой компании классического страхования, поэтому во многом мы зависимы от коллег) наши 200 с небольшим кейсов - лишь крошечная часть их большой регрессионной модели, насчитывающей более 2,5к кейсов
Что касается времени на тестирование ТЗ и просто тестирование itself - тут не могу сказать вам точно, разве что получится плюс-минус километр, бывают задачи на 20 минут, поменять что-то в печатной форме, заменить алгоритм проставления агентов, а бывают на 2 -3 дня с полным изменением логики и всех связанных процессов, также и с техническими заданиями, простое на один функциональный модуль или одну несложную доработку или ТЗ на интеграцию нескольких информационных систем с доработкой каждой из них.
Отличный вопрос про подписание идеального ТЗ, вообще, довольно редко такое происходит, ведь если идти по процессу от ТЗ к разработке через тестирование, а не наоборот, сложно набедокурить))) но, буду честной, случатся, что аналитик правит ТЗ уже по результатам разработки, потому что в последний момент бизнес-пользователи захотели сделать чуть иначе. Если же что-то кардинально меняется, тут уже аналитики встают на стражу и не пропускают ТЗ в разработку, забирают к себе на до-анализ и далее только через нас, тестировщиков, отдают в работу
Про автотесты. Как говорила выше, мы зависимы от головной компании и все, что хотим заавтоматить, передаем им: принимаем решение, пишем параметризированные кейсы, ставим задачу на исполнителя в головной компании, ждем, принимаем работу
Аналитики создают отдельную ветку, дорабатывают спецификацию и отправляют на ревью разработчикам. Дальше мяч на их стороне: идет этап ревью, при необходимости отправляют на доработку. Все изменения мержат уже разработчики после окончательного согласования, иногда в этой же ветке проводят реализацию внутренней логики метода, когда она описана и освободились ресурсы
Очень здорово, что переходите на новую модель работы со спецификацией! Процесс непростой, это правда, мы его обкатывали не один месяц, но оно того стоит
В задачах спецификацию не храним, очень сложно потом синхронизировать ее с общей частью, на моем опыте никто из аналитиков после реализации задачи этого не делал (забывали, не хотели, нет времени и еще 1001 причина). Вместо этого вся документация ведется в базе знаний. В таске описываем верхнеуровнево пункты, которые нужно сделать (создать сущность1, реализовать метод2), а для более детальной информации прикрепляем ссылки на страницы в доке и выделяем цветом дельту, которую нужно реализовать.
Что касается задач на интеграцию: для клиентов (в нашем случае фронтов) или смежных команд достаточно при таком подходе отдать swagger, там вся исчерпывающая информация, которая им необходима. Для разработки бека к swagger еще прикладываем описание внутренней логики, которая также хранится в базе знаний
Самих баз знаний 2: swagger (хранится в git) и wiki
Привет! Спасибо за комментарий! Ответ от Елизаветы: Насчет трудозатрат — спорный момент, тут все зависит от уровня квалификации аналитика и его опыта работы с OpenAPI. На первых этапах, действительно, казалось, что внедрение этого процесса увеличивает сроки реализации задачи. Но со временем, когда команда набила руку, всё стало идти гораздо быстрее, и по времени это практически не отличается от написания спецификаций вручную в документации.
Что касается полиморфизма и наследования — пока такой проблемы не возникало. Спасибо за предупреждение, будем внимательнее к этому моменту.
А вот про генерацию клиентов — отличное дополнение! Мы как раз используем эту функциональность для создания клиентов и тестирования наших бэкэнд-сервисов, что реально упрощает жизнь.
В общем, вы в точку попали с комментариями. Спасибо, что поделились!
Сформулируйте свой вопрос корректнее, пожалуйста :) Скорее всего, он относится к данному фрагменту текста, но непонятно, что конкретно вас удивило :)
"При онбординге нового участника команды сокращается погружение, поскольку даёт возможность быстрого обращения за информацией (текущее общение, история сообщений, поиск по сообщениям)".
Спасибо за обратную связь :)
Привет и спасибо за вопросы! Ответ автора:
По направлению Life у нас 11 разработчиков, 5 аналитиков и 2 гордых тестировщика)
Наша команда, а если смотреть чуть шире, то все управление информационных технологий по направлению Life - это "дочка" большой компании классического страхования, поэтому во многом мы зависимы от коллег) наши 200 с небольшим кейсов - лишь крошечная часть их большой регрессионной модели, насчитывающей более 2,5к кейсов
Что касается времени на тестирование ТЗ и просто тестирование itself - тут не могу сказать вам точно, разве что получится плюс-минус километр, бывают задачи на 20 минут, поменять что-то в печатной форме, заменить алгоритм проставления агентов, а бывают на 2 -3 дня с полным изменением логики и всех связанных процессов, также и с техническими заданиями, простое на один функциональный модуль или одну несложную доработку или ТЗ на интеграцию нескольких информационных систем с доработкой каждой из них.
Отличный вопрос про подписание идеального ТЗ, вообще, довольно редко такое происходит, ведь если идти по процессу от ТЗ к разработке через тестирование, а не наоборот, сложно набедокурить))) но, буду честной, случатся, что аналитик правит ТЗ уже по результатам разработки, потому что в последний момент бизнес-пользователи захотели сделать чуть иначе. Если же что-то кардинально меняется, тут уже аналитики встают на стражу и не пропускают ТЗ в разработку, забирают к себе на до-анализ и далее только через нас, тестировщиков, отдают в работу
Про автотесты. Как говорила выше, мы зависимы от головной компании и все, что хотим заавтоматить, передаем им: принимаем решение, пишем параметризированные кейсы, ставим задачу на исполнителя в головной компании, ждем, принимаем работу
Привет!) Ответ от автора:
Аналитики создают отдельную ветку, дорабатывают спецификацию и отправляют на ревью разработчикам. Дальше мяч на их стороне: идет этап ревью, при необходимости отправляют на доработку. Все изменения мержат уже разработчики после окончательного согласования, иногда в этой же ветке проводят реализацию внутренней логики метода, когда она описана и освободились ресурсы
Очень здорово, что переходите на новую модель работы со спецификацией! Процесс непростой, это правда, мы его обкатывали не один месяц, но оно того стоит
Привет!) Ответ от автора:
В задачах спецификацию не храним, очень сложно потом синхронизировать ее с общей частью, на моем опыте никто из аналитиков после реализации задачи этого не делал (забывали, не хотели, нет времени и еще 1001 причина). Вместо этого вся документация ведется в базе знаний. В таске описываем верхнеуровнево пункты, которые нужно сделать (создать сущность1, реализовать метод2), а для более детальной информации прикрепляем ссылки на страницы в доке и выделяем цветом дельту, которую нужно реализовать.
Что касается задач на интеграцию: для клиентов (в нашем случае фронтов) или смежных команд достаточно при таком подходе отдать swagger, там вся исчерпывающая информация, которая им необходима. Для разработки бека к swagger еще прикладываем описание внутренней логики, которая также хранится в базе знаний
Самих баз знаний 2: swagger (хранится в git) и wiki
Привет! Спасибо за комментарий! Ответ от Елизаветы: Насчет трудозатрат — спорный момент, тут все зависит от уровня квалификации аналитика и его опыта работы с OpenAPI. На первых этапах, действительно, казалось, что внедрение этого процесса увеличивает сроки реализации задачи. Но со временем, когда команда набила руку, всё стало идти гораздо быстрее, и по времени это практически не отличается от написания спецификаций вручную в документации.
Что касается полиморфизма и наследования — пока такой проблемы не возникало. Спасибо за предупреждение, будем внимательнее к этому моменту.
А вот про генерацию клиентов — отличное дополнение! Мы как раз используем эту функциональность для создания клиентов и тестирования наших бэкэнд-сервисов, что реально упрощает жизнь.
В общем, вы в точку попали с комментариями. Спасибо, что поделились!
Привет! Статью написала Лиза Акманова, старший аналитик ГК Юзтех)
Добрый день! Написали вам в личные сообщения, проверьте, пожалуйста.
Вам спасибо за обратную связь! Готовим новую публикацию, следите за уведомлениями :)
Вам спасибо! Рады, что информация пригодилась!
Спасибо! Обязательно продолжим эту серию статей!
Вам спасибо за обратную связь!
Спасибо вам! А можете подробнее рассказать о его использовании?
Спасибо, рады быть полезными :)
Спасибо за то, что прочитали!
Сформулируйте свой вопрос корректнее, пожалуйста :) Скорее всего, он относится к данному фрагменту текста, но непонятно, что конкретно вас удивило :)
"При онбординге нового участника команды сокращается погружение, поскольку даёт возможность быстрого обращения за информацией (текущее общение, история сообщений, поиск по сообщениям)".
Интересное наблюдение, спасибо!
@mariner@VanishMax Спасибо, что поделились!
Здорово, спасибо вам за прочтение, и что поделились своим опытом и наблюдениями! :)
@Maxim_Kirilov вторая часть статьи доступна по ссылке - https://habr.com/ru/company/usetech/blog/702454/
Интересно узнать, угадали ли вы о следующих героях :)
Спасибо за обратную связь и за вашу точку зрения!
Опубликуем вторую часть на следующей неделе. Посмотрим, верны ли ваши предположения :)