пятница, 26 февраля 2016 г.

Опросник по автоматизации

Намедни поставили задачу - составить набор простых вопросов признаков, по которым можно получить как можно больше полезной информации о уровне автоматизации тестирования в команде, степени участия в ней тестировщиков и качестве самой автоматизации.

Получился достаточно большой опросник, представляю его вашему вниманию. Попытался сам честно ответить на все вопросы для своего проекта. Там, где чаще да, чем нет - отвечал да.

Ваши версии? Ваши предложения? Буду пополнять или менять список.


Процесс
Ручное тестирование проходит на версии приложения с зелеными тестами (ручная работа применяется ПОСЛЕ автоматизации) - да
Наблюдает за результатами прохождения тестов тот, кто будет чинить приложение и тесты. - да
Тестировщики пишут недостающие кейсы для полного набора автоматизации тестирования фичи (неважно, кто при этом пишет сами тесты, тестеры или разрабы) - да
Весь объем тестов по фиче пишется до релиза - да
Весь объем тестов по фиче пишется до вливания фичи в общий код - да
Релиз происходит при условии 100% зеленых тестов (либо каждый(!) упавший тест проверяется вручную) - да
Существует ветка, в которую заливается код и в которой больше 50% сборок со 100% зелеными тестами - нет
Тестировщики регулярно проводят ревью кода приложения - нет
Тестировщики регулярно проводят ревью кода тестов - да
Разработчики пишут unit тесты - да
Разработчики пишут тесты на поднятом приложении без использования GUI - да
Разработчики пишут тесты на поднятом приложении с использованием GUI - да
Тестировщики пишут unit тесты - да
Тестировщики пишут тесты на поднятом приложении без использования GUI - да
Тестировщики пишут тесты на поднятом приложении с использованием GUI - да
План изменений в процессе и архитектуре автоматизации существует в виде артефакта - нет
Хотфиксы(срочное исправление, проходящее через процесс тестирования) случаются раз в полгода - да
Хотфиксы случаются раз в месяц - да
Хотфиксы случаются раз в неделю - нет
Хотфиксы случаются раз в день - нет
Факапы(срочное исправление, НЕ проходящее через процесс тестирования) случаются раз в полгода - да
Факапы случаются раз в месяц  - да
Факапы случаются раз в неделю - нет
Факапы случаются раз в день - нет

Техника
Все тесты проходят за сутки с момента запуска (при условии наличия очереди) - да
Все тесты проходят за 4 часа с момента запуска (при условии наличия очереди) - нет
Все тесты проходят за час с момента запуска (при условии наличия очереди) - нет
Используется современная cvs: git или mercurial - да
Юнит тестов больше, чем тестов на поднятом приложении без использования GUI - нет
Тестов на поднятом приложении без использования GUI больше, чем тестов с использованием GUI - да
Релизы новой функциональности происходят раз в неделю - да
Релизы новой функциональности происходят раз в день - нет
Релизы новой функциональности происходят чаще раза в день - нет
Сборка стенда на ветке происходит по 1й кнопке - да
Регулярно, автоматически (по коммитам) происходит сборка проекта в определенной ветке - да
Регулярно, автоматически (по коммитам, если проект компилируется) идут тесты на проект в определенной ветке - да
Регулярно, автоматически (по коммитам, если прошли тесты)  происходит релиз приложения в бой - нет
Тестировщики могут и при необходимости чинят приложение - нет
Тестировщики могут и при необходимости чинят тесты - да
Тестировщики могут и при необходимости проводят настройку инфраструктуры - да



15 комментариев:

  1. У меня возникли проблемы с ответами на некоторые вопросы =)

    "Ручное тестирование проходит на версии приложения с зелеными тестами (ручная работа применяется ПОСЛЕ автоматизации)" - ручная работа применяется по возможности после автоматизации, но зеленых версий практически не существует, т.к. тесты пишутся сразу и могут долго оставаться упавшими, если проверяют какую-нибудь очень низкоприоритетную вещь.

    "Наблюдает за результатами прохождения тестов тот, кто будет чинить приложение и тесты." - это разные люди. За результатами тестов глобально следит тестировщик, который и будет чинить тесты. Программист, который будет чинить приложение, следит только за результатами небольшого набора тестов (запуская их у себя локально), который написал ему в баге тестировщик.

    "Тестировщики могут и при необходимости чинят приложение" - могут, но не чинят - это "да" или "нет"?


    А про хотфиксы и факапы я бы переформулировала с "случаются раз в..." на "случаются раз в ... и чаще". И "тесты проходят за ..." на "тесты проходят меньше, чем за ..."

    ОтветитьУдалить
    Ответы
    1. 1. За результатами тестов глобально следит тестировщик, который и будет чинить тесты. Программист, который будет чинить приложение, следит только за результатами небольшого набора тестов (запуская их у себя локально), который написал ему в баге тестировщик."

      Это печально. Для того и вопрос чтоб выявить такое. В этой петле обратной связи тестировщик лишний, происходит дублирование работы - с одними и теми же тестами разбираются 2 человека. Еще и баги заводят в трекер.

      2. "могут, но не чинят "
      Это я не учел

      Удалить
    2. Я вижу проблему в том, что у программиста нет возможности самостоятельно точно определить, какие из уже написанных тестов касаются его фичи, чтобы запустить их перед тем, как отдать в тестирование.

      В целом происходит так:
      Есть полный набор тестов, который выполняется около часа. За результатами его прогона дженкинсом следит тестировщик. Ну то есть если что-то упало, смотрим, оно упало, потому что тесты не очень, или потому что программисты сломали.
      А когда программист тратит на реализацию фичи 15 минут, ему нецелесообразно запускать все тесты, ну или даже ждать час, пока их дженкинс выполнит. Поэтому он отдает свою фичу в тестирование (тем более на саму фичу тесты не написаны ещё). Тестировщик пишет тесты, проверяет, возвращает задачу программисту с описанием багов и списком тестов (это могут быть тесты как из вновь написанных, так и существовавшие ранее), которые находят эти баги.

      Да, у нас нет отдельной ветки на каждую фичу, нам это оказалось не очень удобно. Минус это или нет вопрос другой. С заведением ветки на каждую фичу у нас оказывалось слишком много мерж-конфликтов. Да, да, это тоже проблема, и проблема постановки и распределения задач, а идеальных менеджеров у нас нет. В общем, так или иначе, у программиста нет возможности запустить все тесты и посмотреть, что ничего нового не упало.

      Пишу это всё и понимаю, что блиииин, какой-то отстой у нас) Расскажи, как на твой взгляд должны быть построены процессы, чтобы не было дублирования, про которое ты говоришь.

      Удалить
    3. В моем идеальном мире - все ответы зеленые, а все тесты ходят 15 минут.

      В моем проекте разработчики почти(60-70%) всегда отдают в тестирование ветку с написанными новыми и поднятыми старыми тестами.

      У нас все фичи в своих ветках, конфликты редки (знаю, так как сам сливаю протестированный код в общую ветку).

      "С заведением ветки на каждую фичу у нас оказывалось слишком много мерж-конфликтов." - либо ну очень особая ситуация, либо глупость и вранье. Конфликты не зависят от количества веток и будут существовать в любой модели слияния, кроме одновременной онлайн работы

      Удалить
    4. А вообще тут с коллегами тестерами мутим регулярные собрания автоматизаторов. В частности с выделением и обсуждением целевых состояний, этапов и путей достижения.

      Удалить
    5. "В моем проекте разработчики почти(60-70%) всегда отдают в тестирование ветку с написанными новыми и поднятыми старыми тестами." Программисты сами пишут все тесты? Или только юнит, но правят любые? А тестировщики тесты пишут? Я так понимаю, что все тесты в общей ветке зеленые, так что сразу ясно, что всё что упало, упало из-за нового кода? В проекте не существует минорных багов, которые будут исправлены когда-нибудь, но сейчас ломают тесты?
      (Пока писала этот абзац, сто раз задумалась о качестве своих тестов, да)

      Насчет конфликтов: один программист добавляет в некий объект новое поле (ну и какую-то логику работы с ним), а другой в то же время к тому же объекту добавляет какую-нибудь, допустим логику рассчета вычисляемого поля. Если они работают в одной ветке, они регулярно (или как миниум перед тем как запушить) пулятся, разруливают конфликты, если таковые возникают, так что их локальные версии не расходятся слишком сильно.

      Удалить
    6. "Программисты сами пишут все тесты?" Да.
      "Все тесты в общей ветке зеленые" Падают 5 из 4000 регулярно. Безуспешно боремся.

      Багов в проекте три. Или два. У нас принято не врать. Если баг не чинится 2 недели - это не баг и мы его не чиним никогда. Если это баг - мы его чиним сейчас и выпускаем с ближайшим или следующим релизом.

      Конфликты. Ты сама сказала, что они будут энивей. Вопрос кто и когда их разрешает. У нас над фичей могут работать по 2-4 человека. Единица вливания - фича.

      Что хочется отметить - все эти вкусные плюшки стоят серьезных трудозатрат. Но без них - нереально работать.

      Удалить
    7. "А тестировщики тесты пишут?" - пишут какие потребуется. Реальна ситуация, когда разработчик занят и просит написать тестера все виды тестов. При этом помогая разрешить сложности с api и т.п. Это по сложным или срочным фичам. По сути - создается отдельная рабочая группа вне рамок обычного процесса.

      Удалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. "Если баг не чинится 2 недели - это не баг и мы его не чиним никогда." Первая мысль была: "неплохой подход", вторая: "когда у нас недавно менеджеры вдруг позакрывали часть задач/багов из бэклога, аргументируя тем, что "что-то у нас там много задач висит, а пользователи с этим к нам не обращались", мы все (разработчики) были возмущены и часть багов таки вернули и отдали в работу".
    А как у вас такие баги закрываются? С комментарием "не будем фиксить"? Ну для того, чтобы их потом снова не завели?

    Конфликты будут, да, вопрос не столько в том, кто и когда, а в том, сколько на это будет потрачено времени. "над фичей могут работать по 2-4 человека. Единица вливания - фича." - думаю, это ключевой момент. У вас фича, скорее всего, - достаточно большой кусок логики (с такими мы тоже работаем в отдельных ветках чаще всего), у нас обычно нет такого разбиения (и да, это пожалуй снова можно расценить как проблему менеджмента задач). Мне сейчас пришло осознание, как правильно использовать работу с ветками в этом отношении, спасибо =)

    ОтветитьУдалить
    Ответы
    1. "А как у вас такие баги закрываются?
      - у нас нет трекера, мы не заводим баги, а сразу чиним.

      "Чтоб их потом не завели" - проблемы нет. Баги ищутся и чинятся в рамках фичи. Очень мало плавает снаружи, ситуация крайне редка.

      Удалить
    2. Этот комментарий был удален автором.

      Удалить
    3. > зеленых версий практически не существует, т.к. тесты ... могут долго оставаться упавшими

      Зеленых версий нет. Тесты могут долго оставаться упавшими. Да это же проблема! Более того, эта проблема может подорвать доверие к автотестам. И возможно, уже подорвала:
      "А чего их чинить, они же всё равно чушь показывают"

      > могут, но не чинят - это "да" или "нет"?

      Вопрос не в том, занимаются ли они починкой приложения каждодневно. Вопрос в том, занимаются ли они починкой приложения тогда, когда в этом есть необходимость. Если могут, но при необходимости не делают, то почему?

      > это разные люди

      Это тоже проблема. Программист и автоматизатор - это два разных человека. У этих двух разных человеков - две разные зоны ответственности. Это иногда (а может даже часто) вредит общему делу.

      В идеальном мире программист пишет и приложение, и юнит-тесты, и тесты без UI, и тесты через UI. Это приводит к положительному эффекту: если программисту проще сделать что-то на уровне юнит-тестов, он не будет делать это через UI тесты. А в первом случае он просто скажет: "Писать UI тесты не моя работа, а писать юнит-тесты нет времени / напишем когда-нибудь потом / другая отговорка".

      Но не переживайте сильно по этому поводу. Если в вашей компании уже сложился вариант 1 (а в большинстве компаний сложился вариант с разделением труда), вам навряд ли стоит пытаться его сломать.

      Удалить
  4. В каком идеальном проекте, оказывается, я работаю...

    Извините, не сдержался.

    ОтветитьУдалить