Привет,
не нашел ответа в MSF V3 Whitepapers, поэтому спрашиваю у вас.
В MSF функциональное тестирование начинается в фазе стабилизации или уже в фазе разработки?
И как тестируются ежедневные билды, с помощью unit тестов или тестеры каждый день одно и то же проверяют?
Тестирование в MSF
Автор ghusta, 26 сен 2005 16:59
Сообщений в теме: 14
#1
ghusta
-
- Members
-
- 11 сообщений
Новый участник
- ФИО:Artyom Krasnopyorov
- Город:Riga
Отправлено 26 сентября 2005 - 16:59
#2
ghusta
-
- Members
-
- 11 сообщений
Новый участник
- ФИО:Artyom Krasnopyorov
- Город:Riga
Отправлено 27 сентября 2005 - 17:20
всем спасибо, ответ нашелся 
#3
serega
-
- Members
-
- 355 сообщений
Опытный участник
- Город:Москва
Отправлено 28 сентября 2005 - 11:22
всем спасибо, ответ нашелся
И какой, мне тоже интересно?
#4
ghusta
-
- Members
-
- 11 сообщений
Новый участник
- ФИО:Artyom Krasnopyorov
- Город:Riga
#5
Case
-
- Members
-
- 7 071 сообщений
Основатель
- ФИО:Панкратов Вячеслав
- Город:Украина, Киев.
Отправлено 28 сентября 2005 - 21:30
Ответили мол "up 2 you" и "как можно раньше"? Классный ответ.
Классный ответ.
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#6
ghusta
-
- Members
-
- 11 сообщений
Новый участник
- ФИО:Artyom Krasnopyorov
- Город:Riga
Отправлено 29 сентября 2005 - 06:32
Ответили мол "up 2 you" и "как можно раньше"?
других ответов не было, так что и такие тоже норм ;)
правда не совсем ясно, как же всё-таки тестить ежедневные билды, если кто сталкивался расскажите :)
#7
serega
-
- Members
-
- 355 сообщений
Опытный участник
- Город:Москва
Отправлено 29 сентября 2005 - 06:44
правда не совсем ясно, как же всё-таки тестить ежедневные билды, если кто сталкивался расскажите :)
Народ, задавайте вопросы более конретно: что для вас является билдом, какие задачи преследует ежедневное тестирование и надо ли вообще их тестить ежедневно?
Невозможно дать универсальный совет на все случаи жизни
#8
ghusta
-
- Members
-
- 11 сообщений
Новый участник
- ФИО:Artyom Krasnopyorov
- Город:Riga
Отправлено 29 сентября 2005 - 08:32
ок, каюсь :)
под ежедневным билдом я понимаю, полную сборку системы, в которую включены все новые фичи, которые успели сделать к этому времени и исправленные баги. обычно билды делаются по ночам или вечерами, чтобы утром уже можно было с ними работать, т.е. проверять исправили баги или нет, и правильно или нет работает вся система в целом.
для чего билды делать каждый день? ну, хотябы для того, чтобы была уверенность, что система работает. я работаю в проекте, где билды делаются раз в неделю, а за неделю вносят много изменений, и бывает, что новый билд довольно плохой: в одном месте исправили, а в двух - сломали. но за то тестерам не нужно каждый день проверять одну и ту же функциональность.
а вопрос мой вот такой: если кто сталкивался с ежедневными билдами, то каждый билд тестеры руками проверяли или большая часть это unit тесты?
под ежедневным билдом я понимаю, полную сборку системы, в которую включены все новые фичи, которые успели сделать к этому времени и исправленные баги. обычно билды делаются по ночам или вечерами, чтобы утром уже можно было с ними работать, т.е. проверять исправили баги или нет, и правильно или нет работает вся система в целом.
для чего билды делать каждый день? ну, хотябы для того, чтобы была уверенность, что система работает. я работаю в проекте, где билды делаются раз в неделю, а за неделю вносят много изменений, и бывает, что новый билд довольно плохой: в одном месте исправили, а в двух - сломали. но за то тестерам не нужно каждый день проверять одну и ту же функциональность.
а вопрос мой вот такой: если кто сталкивался с ежедневными билдами, то каждый билд тестеры руками проверяли или большая часть это unit тесты?
#9
serega
-
- Members
-
- 355 сообщений
Опытный участник
- Город:Москва
Отправлено 29 сентября 2005 - 08:42
Я придерживался следующей стратегии при частом выпуске билдов.
Сначала приемочные тесты - проверяется основная функциональность, чтобы удостовериться, что билд "живой"
Затем основные исправленные ошибки и доработки.
И потом, в зависимсоти от расписания сборок, происходит проверка либо всего функционала, либо ожидается следующая сборка, в которой запланировано итеграционное/системное тестирование.
Сначала приемочные тесты - проверяется основная функциональность, чтобы удостовериться, что билд "живой"
Затем основные исправленные ошибки и доработки.
И потом, в зависимсоти от расписания сборок, происходит проверка либо всего функционала, либо ожидается следующая сборка, в которой запланировано итеграционное/системное тестирование.
#10
Clauster
-
- Members
-
- 1 913 сообщений
Профессионал
- ФИО:Худобородов Валерий
- Город:Espoo
Отправлено 29 сентября 2005 - 11:46
Нет, не каждый. Часто бывает такое, что за день несколько сборок происходит. Билд имеет смысл брать на тестирование при добалении новой функциональности, необходимости закрытия багов и т.п. А вообще у всех по-разному. Так что сами в скором времени определитесь.а вопрос мой вот такой: если кто сталкивался с ежедневными билдами, то каждый билд тестеры руками проверяли или большая часть это unit тесты?
#11
Green
-
- Members
-
- 1 233 сообщений
Профессионал
- ФИО:Гринкевич Сергей
- Город:Москва
Отправлено 29 сентября 2005 - 14:28
Ежедневные билды - это для разработчиков.
У тестировщиков должен быть свой ритм работы. При приемке билда в тестирование всегда существует рутинная процедура по приемке билда в тестирование, которая должна включать smoke test. Если она занимает и не очень большую часть рабочего времени, то все равно в итоге это выливается в большие временные потери.
Например, на прием билда в тестирование тратится 1 час. По итогам недели потеря составит 4 часа (1 час оправдан, если ежедневные билда сравнивать с недельным циклом).
У тестировщиков должен быть свой ритм работы. При приемке билда в тестирование всегда существует рутинная процедура по приемке билда в тестирование, которая должна включать smoke test. Если она занимает и не очень большую часть рабочего времени, то все равно в итоге это выливается в большие временные потери.
Например, на прием билда в тестирование тратится 1 час. По итогам недели потеря составит 4 часа (1 час оправдан, если ежедневные билда сравнивать с недельным циклом).
Гринкевич Сергей
#12
serega
-
- Members
-
- 355 сообщений
Опытный участник
- Город:Москва
Отправлено 30 сентября 2005 - 06:46
Ежедневные билды - это для разработчиков.
Спорное утверждение, а если это изменения, которые должны срочно отразиться на рабочей базе у заказчика?
#13
Dimon
-
- Members
-
- 110 сообщений
Активный участник
- ФИО:Dimon Makhno
- Город:Украина, Харьков
Отправлено 30 сентября 2005 - 09:25
Мне кажется, что действительно нужно понять что имеется ввиду под билдом.
В нескольких местах очень часто используется понятие сборки. И важность сборки определяется версией, которую принято обозначать через точку:
major.minor.build.revision
major и minor больше относится к релизу и RC.
Так, вот по моему опыту, revision, именно о них и говорит Green действительно, чаще всего относятся только к разработчикам, иногда в ввиде исключения, или нарушения планов, проверку проводит тестер.
А вот каждый build обязан пройти через Test Lab или QA Lab, взависимости от того на сколько большая система, или проверяемый модуль, переодичность может быть как каждый день, так и раз в неделю.
У меня случались внешние проекты, что у заказчика уходило до 2х суток, чтобы только собрать билд. Это без проведения приемочных тестов (Smoke например). И проход по билду регрессионных тестов, занимал около недели.
А случались ситуации (проекты), когда вообще отсутствовало понятие revision, вся система маленькая, и можно делать билды на тестирование по несколько раз в день.
И процесс получается довольно сбитый:
1. Приходит билд
2. Тестер проверяет оговоренные пофиксы
3. _Если нету_ следующего билда, тестер продолжает проверку.
Кто-то осудит, за неиспользованние регрессионных тестов, но на маленьких проектах (которые часто встречаются для embedded applications), такая тактика довольно таки оправданна и эффективна.
В нескольких местах очень часто используется понятие сборки. И важность сборки определяется версией, которую принято обозначать через точку:
major.minor.build.revision
major и minor больше относится к релизу и RC.
Так, вот по моему опыту, revision, именно о них и говорит Green действительно, чаще всего относятся только к разработчикам, иногда в ввиде исключения, или нарушения планов, проверку проводит тестер.
А вот каждый build обязан пройти через Test Lab или QA Lab, взависимости от того на сколько большая система, или проверяемый модуль, переодичность может быть как каждый день, так и раз в неделю.
У меня случались внешние проекты, что у заказчика уходило до 2х суток, чтобы только собрать билд. Это без проведения приемочных тестов (Smoke например). И проход по билду регрессионных тестов, занимал около недели.
А случались ситуации (проекты), когда вообще отсутствовало понятие revision, вся система маленькая, и можно делать билды на тестирование по несколько раз в день.
И процесс получается довольно сбитый:
1. Приходит билд
2. Тестер проверяет оговоренные пофиксы
3. _Если нету_ следующего билда, тестер продолжает проверку.
Кто-то осудит, за неиспользованние регрессионных тестов, но на маленьких проектах (которые часто встречаются для embedded applications), такая тактика довольно таки оправданна и эффективна.
Граммотность - то качество, которым я не обладаю.
#14
Green
-
- Members
-
- 1 233 сообщений
Профессионал
- ФИО:Гринкевич Сергей
- Город:Москва
Отправлено 30 сентября 2005 - 10:51
Ежедневные билды - это для разработчиков.
Спорное утверждение, а если это изменения, которые должны срочно отразиться на рабочей базе у заказчика?
Спасибо Dimon-у (
), совершенно справедливое уточнение.
Что касается вопроса Seregi, то я бы не хотел работать при таком процессе, где собранный билд должен срочно очутиться на продакшине у заказчика. Это должно быть исключением, чем правилом. А, как известно, именно они (исключения) подтверждают именно их (правила).
Гринкевич Сергей
#15
serega
-
- Members
-
- 355 сообщений
Опытный участник
- Город:Москва
Отправлено 30 сентября 2005 - 11:14
Что касается вопроса Seregi, то я бы не хотел работать при таком процессе, где собранный билд должен срочно очутиться на продакшине у заказчика. Это должно быть исключением, чем правилом. А, как известно, именно они (исключения) подтверждают именно их (правила).
Никто не хочет, но бизнес часто диктует правила, идущие в разрез со здравым смыслом. Вот и думайте либо срочно патч выложить, либо пойти на принцип и испортить отношения с клиентом.
Это касается не только IT индустрии
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных
