Сообщений в теме: 8

[akiselev87]

Доброго времени суток!
Работаю аналитиком более 6 лет, а вот в разработку/тестирование влезал слабо. Можете ли ответить на несколько моих вопросов (я уже ходил в гугл, если что...):
1- Какие тесты обычно создает программист? Как они называются?
2- Могут ли эти же тесты писать QA?
3- У аналитиков есть тестирование требований (когда один аналитик вычитывает постановку другого и проверяет её на корректность/полноту/и тп), если подобное у тестировщиков по тест кейсам?
4- В гит или свн ведь не коммитят екзешники, а коммитят исходники? Тогда получается, что каждый тестировщик делает сборку на своей машине и потом тестирует приложение?
5- В момент коммита пишутся регрессионные тесты? Программистом или тестировщиком?
6- Понимаю что такое бранч и транк, а вот как из этого добра берется релиз (как я понимаю,в оидн счастливый момент транк им и становится) и как они хранятся?

Буду рад даже очень кратким ответам, спасибо!

[Petrov.Sergey]

Доброго времени суток!
Работаю аналитиком более 6 лет, а вот в разработку/тестирование влезал слабо. Можете ли ответить на несколько моих вопросов (я уже ходил в гугл, если что...):
1- Какие тесты обычно создает программист? Как они называются?
2- Могут ли эти же тесты писать QA?
3- У аналитиков есть тестирование требований (когда один аналитик вычитывает постановку другого и проверяет её на корректность/полноту/и тп), если подобное у тестировщиков по тест кейсам?
4- В гит или свн ведь не коммитят екзешники, а коммитят исходники? Тогда получается, что каждый тестировщик делает сборку на своей машине и потом тестирует приложение?
5- В момент коммита пишутся регрессионные тесты? Программистом или тестировщиком?
6- Понимаю что такое бранч и транк, а вот как из этого добра берется релиз (как я понимаю,в оидн счастливый момент транк им и становится) и как они хранятся?

Буду рад даже очень кратким ответам, спасибо!

1) Юнит-тесты.
2) Да, если функции имеют "выход наружу".
3) не слышал.
4) Про коммиты экзешников не слышал ни разу. "каждый тестировщик делает сборку на своей машине и потом тестирует приложение?" Видимо, так и получается. Я, правда, ни разу не имел дела со сборкой на локальной машине - как правило, централизованная сборка на сервере (автоматически) или собственная сборка также на сервере (тоже автоматически).
5) В момент коммита происходит изменение кода в репозитории. А что Вы имели в виду?
6) Релиз - срез транка, который пойдёт на бой. "Срез" - это выборка (подмножество всех) коммитов, выполненных после STABLE-версии, для наката на новую ветку, которая пойдёт на бой.
К примеру, в транке сейчас лежат коммиты по 10 задачам, выполненным после формирования STABLE-версии, из которых только 7 идут на бой. Тимлид программистов выполняет подготовку - выделяет новую ветку (копия боя), накатывает на неё все коммиты по выбранным 7 задачам, осуществляет мёрж кода (часто вручную) и проверяет работоспособность новой ветки. В хороших конторах эта новая ветка разворачивается на сервере "препрода", чтобы тестеры прогнали регресс и новую функциональность на препроде. После "ОК" новая ветка становится веткой STABLE, а старая как-нибудь переименовывается (хранить одну old-ветку для быстного отката на предыдущую версию). Все более ранние STABLE-ветки убиваются.

[Vader]

1. Обычно - никакие. Но, если повезет, то - юнит тесты.
2. Могут, если хватает навыков. Но это миф.
3. Да, если на это хватает времени. Но это тоже миф.
4. При нормальном подходе к вопросу, все собирается в системе непрерывной интеграции, но можно, конечно, и на коленке собирать, а потом слать друг дружке по скайпу
5. В момент коммита файлики заливаются в репозиторий, а регрессионные тесты начинают писать, когда из этих файликов перестает собираться хоть что-нибудь вразумительное. Кстати, юнит тесты начинают писать примерно в это же время
6. Не для всех момент релиза является счастливым. Сам релиз берется оттуда откуда его можно взять в момент наступления дедлайна или в момент, когда произносится специальное релизное заклинание "Нам же вечером отдавать, блядь!". Если вас больше интересует техническая сторона вопроса, то место и способ "взятия" релиза целиком и полностью зависит от фантазии команды, которая пишет код - "отпочковывание" транка в релизную ветку, добавления куда-нибудь какого-нибудь тега и т.п.

[akiselev87]

Коллеги, большое спасибо!
На данный момент появился ещё один вопрос - если у меня система имеет 3 "версии" - для юр лиц, физ лиц и смешанная, то как мне хранить код?
У меня должен быть основной транк, где лежит код, общия для все 3 направлений и ветки, в которых реализованы отдельные фичи отдельным кодом?
Или у меня все равно 1 транк и разграничение по версиям системы идет на уровне тегов?
Или вообще транка нет, а есть 3 сильные ветки, которые порождают свои ветки и свои ветки с релизами?

Извиняюсь, если вопрос криво поставлен, но, надеюсь, что мысль моя понятна...

[Vader]

А вы спрашивали у тех кто пишет\будет писать код (судя по вопросам, это не вы), как им удобнее все это хранить и поддерживать?
И зачем вам при описанном положении вещей разные ветки? Гораздо эффективнее выключать ненужные фичи лицензионным ключом, чем распиливать продукт на 100500 версий.

[akiselev87]

Да, про это я не сообразил...
Вообще, я пока больше в теории пытаюсь понять процесс.

[Лелик32]

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

Это смотря, что за проект и над чем работаем. Я не вижу смысла в непрерывной интеграции, если тестировщик подключается к процессу только после передачи ему предрелизной сборки. ИМХО, непрерывная интеграция нужна там, где сложный проект и где тестирования идет каждый день (сегодня тестируют -> сегодня фиксят -> завтра утром собирают новый билд -> завтра тестируют и т.д.).

[Vasiliy]

6- Понимаю что такое бранч и транк, а вот как из этого добра берется релиз (как я понимаю,в оидн счастливый момент транк им и становится) и как они хранятся?

Буду рад даже очень кратким ответам, спасибо!

Тут могут быть варианты в зависимости от выпускающей политики компании.

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

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

P.S. Есть компании, где работают только с транком.

[Vader]

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

Это смотря, что за проект и над чем работаем. Я не вижу смысла в непрерывной интеграции, если тестировщик подключается к процессу только после передачи ему предрелизной сборки. ИМХО, непрерывная интеграция нужна там, где сложный проект и где тестирования идет каждый день (сегодня тестируют -> сегодня фиксят -> завтра утром собирают новый билд -> завтра тестируют и т.д.).

CI - не только и не столько инструмент тестировщика, сколько инструмент программиста, да и, вообще, всех причастных. Потому что:
1. Красиво написанный код, который невозможно собрать, потому что программист Василий начал использовать новый суперфреймворккоторыйрешитвсенашипроблемы, но забыл положить его в репозиторий, никому не нужен.
2. Нервный проджект менеджер или заказчик, которому очень нужен билд, но он не может его получить, потому что программист Иван в отпуске, а программист Петр страдает от похмелья и раньше 13:00 не появится, тоже никому не нужен.
3. Дополнительные траты на лицензии компиляторов\ide\библиотек только для того, чтобы тестировщик мог собрать у себя на коленке билд, тоже нафиг не нужны.

В общем, есть, конечно, проекты, которым CI без надобности - один человек, одна неделя, write-only код. Но мне кажется, что ТС не о таких проектах говорит.

И да, я работал на проекте длительностью в год, на котором тестировщикам приходилось собирать билды самостоятельно, и я не могу назвать этот опыт положительным.