Давайте обратную связь один на один, а не группе людей, даже если собираетесь говорить только хорошее.… Говорить о своих проблемах, просить совета, задавать вопросы на людях намного труднее, чем в разговоре с глазу на глаз.
Раньше в Епаме на Performance review было больше народа — сотрудник, его начальник и HR-партнер (из приколов — в нашем офисе эти встречи все равно назывались one-2-one). Что-то поменялось или кто-то из троих не считается за человека?)
Не знаю к какой категории отнести. Наверное к категории друзей, но в описании речь только о людях вроде. В игре Arcanum был компаньон-собака, которую можно было спасти в одном из городов от избивавшего ее хозяина. Лично я привязался к ней гораздо больше, чем к изначальному компаньону Вирджилу :-)
KPI мы используем не для того, чтобы отследить, работает или нет.
Может не так выразился. В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Из интересного — вы предлагает в описывать в стратегии и правила/рекомендации/требования к тест-дизайну. Такого не практиковали, будет возможность можно опробовать. Как минимум один случай всплыл в памяти, когда это бы пригодилось команде.
+ тест-план или тестовая стратегия решает дополнительно еще одну задачу, для вас, может быть не актуальную — возможность ротации, безболезненной смены команды или замену людей в команде. Имхо, в том виде, что у вас документ эту задачу решит очень даже неплохо.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
Стратегия тестирования = тест-план в вашем подходе?
Для того, чтобы все участники проекта понимали роль тестирования
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Эту задачу (в том числе и для руководства) лучше решает что-то типа тест-плана за 10 минут, одностраничного тест-плана
Подробное перечисление видов тестирования с обоснованием того, зачем оно применяется не излишнее ли? Имхо, полезней описать что мы тестируем, а что не тестируем в нашем приложении (Например расписать из каких модулей/функционала состоит наше приложение и что из этого мы тестируем. Зачастую не функциональные требования остаются за скобками и тестирование говорит, что производительностью мы не занимаемся. Либо указываются ограничения для интеграций — например тестирование только на заглушках или эмуляторах)
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами)
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей
В таком виде выглядит именно как самоцель, имхо. Слишком уж громоздкий документ выйдет, если следовать инструкции. И времени сожрет на создание и актуализацию не мало. Решить задачи можно более простым доком.
многие вещи оказываются уже придуманными, печаль. В тех деревнях где я родился и жил самая автоматизированная система на паркингах — это мужик, который веревочку, пропущенную черз блок, руками поднимает и опускает.
Вообще, идея родилась из предложения использовать голограмму и возражения на это, что через нее можно проехать.
На въезде вешаем роликовые жалюзи. На нижний край жалюзи вешаем противовес, чтобы на ветру не колыхалось.
Жалюзи опущены. На полотне нарисована приветственная картинка и инструкция об оплате, схема парковки и т.п.
После оплаты жалюзи сворачиваются освобождая проезд.
Риск понятен, который Вы обозначили, как и любой риск с ним можно работать. Например планировать работы.
Если автотесты сломались, их чинят. В зависимости от причин слома — автоматизатор или тестировщик.
Один SAPовец, один сишник, остальные разработчики БД, в основном Oracle, такой бэкграунд.
Я не знаю как можно с помощью этого автоматизировать тестирование. Только м.б. извращенные варианты какие-то.
У вас свой подход, ни в коем случае не оспариваю правильность. Для себя вижу риск в неконтролируемом развитии фреймворка при таком подходе.
Технически могут, наверное. На момент внедрения не рассматривали такой подход:
1. Считали, что нужен человек, который будет как-то управлять развитием фреймворка
2. Разработка была загружена, дополнительные задачи сказались бы на основных
3. Разработка в двух командах из трех шла на технологиях сильно отличных от используемых в автоматизации (продукты на платформе SAS).
В целом утверждение, что разработчик автотестов не нужен скорее ложное, если под таким человеком мы подразумеваем кого-то, кто занимается разработкой фреймворка.
Автоматизированные проверки на «человеческом языке» это прям тренд современной автоматизации)
Проблема в том, что разработанный фреймворк гарантированно слишком сложен для понимания тестировщиком, который за 2 недели познал прелести программирования.
Да, он сможет написать проверку, более прокаченный — сможет прописать страницы и локаторы. Но вот доработать фреймворк (например, захотелось нам в одном тесте в БД залезть или сообщение в MQ кинуть) сможет только специальный человек. 2 недель обучения с нуля для этого не хватит.
Т.е. на мой взгляд, полностью Ваша проблема не решена.
Решали аналогичную задачу на маленькой команде(3 проекта). В итоге получился такой работающий механизм:
Один человек, автоматизатор с опытом занимается:
1. Запуском автоматизации на проекте
2. Обучением тестировщиков азам работы с фреймворком в части создания сценариев
3. Развитием фреймворка, реализацией новых фич в нем по запросам от команд.
Тестировщики на проектах занимаются:
1. Написанием непосредственно автоматизированных проверок
2. Следят за покрытием автоматизированных проверок и анализируют результаты прогона тестов.
Есть ряд вопросов, будет интересно узнать.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Как соблюдается баланс между новыми фичами и правкой багов?
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
По задумке — о том, что при подготовке к собеседованию можно использовать некоторый алгоритм, который поможет структурировать и собеседование и принятие последующих решений.
Чего не хватает, по вашему мнению, статье? Чтобы вопроса «о чем это?» у читателей не возникало?
А сколько команд из общего числа не использует построенный конвейер? Наверняка есть такие, кто не хочет (или это обязательное требование?) или не может. Какой-нибудь rocket-science на уникальных технологиях, к которому сложно прикрутить CI/CD. С продуктами SAS, в свое время, намучались и решили лучше не трогать, себе дороже делать CI оказалось.
Ну и мини-вопрос, какую технологию контейнеризации рассматриваете сейчас для внедрения?
Раньше в Епаме на Performance review было больше народа — сотрудник, его начальник и HR-партнер (из приколов — в нашем офисе эти встречи все равно назывались one-2-one). Что-то поменялось или кто-то из троих не считается за человека?)
Может не так выразился. В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Из интересного — вы предлагает в описывать в стратегии и правила/рекомендации/требования к тест-дизайну. Такого не практиковали, будет возможность можно опробовать. Как минимум один случай всплыл в памяти, когда это бы пригодилось команде.
+ тест-план или тестовая стратегия решает дополнительно еще одну задачу, для вас, может быть не актуальную — возможность ротации, безболезненной смены команды или замену людей в команде. Имхо, в том виде, что у вас документ эту задачу решит очень даже неплохо.
Стратегия тестирования = тест-план в вашем подходе?
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Эту задачу (в том числе и для руководства) лучше решает что-то типа тест-плана за 10 минут, одностраничного тест-плана
Подробное перечисление видов тестирования с обоснованием того, зачем оно применяется не излишнее ли? Имхо, полезней описать что мы тестируем, а что не тестируем в нашем приложении (Например расписать из каких модулей/функционала состоит наше приложение и что из этого мы тестируем. Зачастую не функциональные требования остаются за скобками и тестирование говорит, что производительностью мы не занимаемся. Либо указываются ограничения для интеграций — например тестирование только на заглушках или эмуляторах)
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
В таком виде выглядит именно как самоцель, имхо. Слишком уж громоздкий документ выйдет, если следовать инструкции. И времени сожрет на создание и актуализацию не мало. Решить задачи можно более простым доком.
Вообще, идея родилась из предложения использовать голограмму и возражения на это, что через нее можно проехать.
Жалюзи опущены. На полотне нарисована приветственная картинка и инструкция об оплате, схема парковки и т.п.
После оплаты жалюзи сворачиваются освобождая проезд.
Если автотесты сломались, их чинят. В зависимости от причин слома — автоматизатор или тестировщик.
Я не знаю как можно с помощью этого автоматизировать тестирование. Только м.б. извращенные варианты какие-то.
У вас свой подход, ни в коем случае не оспариваю правильность. Для себя вижу риск в неконтролируемом развитии фреймворка при таком подходе.
1. Считали, что нужен человек, который будет как-то управлять развитием фреймворка
2. Разработка была загружена, дополнительные задачи сказались бы на основных
3. Разработка в двух командах из трех шла на технологиях сильно отличных от используемых в автоматизации (продукты на платформе SAS).
Автоматизированные проверки на «человеческом языке» это прям тренд современной автоматизации)
Проблема в том, что разработанный фреймворк гарантированно слишком сложен для понимания тестировщиком, который за 2 недели познал прелести программирования.
Да, он сможет написать проверку, более прокаченный — сможет прописать страницы и локаторы. Но вот доработать фреймворк (например, захотелось нам в одном тесте в БД залезть или сообщение в MQ кинуть) сможет только специальный человек. 2 недель обучения с нуля для этого не хватит.
Т.е. на мой взгляд, полностью Ваша проблема не решена.
Решали аналогичную задачу на маленькой команде(3 проекта). В итоге получился такой работающий механизм:
Один человек, автоматизатор с опытом занимается:
1. Запуском автоматизации на проекте
2. Обучением тестировщиков азам работы с фреймворком в части создания сценариев
3. Развитием фреймворка, реализацией новых фич в нем по запросам от команд.
Тестировщики на проектах занимаются:
1. Написанием непосредственно автоматизированных проверок
2. Следят за покрытием автоматизированных проверок и анализируют результаты прогона тестов.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Как соблюдается баланс между новыми фичами и правкой багов?
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
Чего не хватает, по вашему мнению, статье? Чтобы вопроса «о чем это?» у читателей не возникало?
Ну и мини-вопрос, какую технологию контейнеризации рассматриваете сейчас для внедрения?