Тестирование

← →
StriderMan © (2006-10-27 09:44) [0]

Мастера!
Назрел у меня вопрос: как у Вас обстоят дела с тестированием софта? Я имею ввиду не собственные тулзы, коих у каждого вагон, а тот коммерческий софт который многие из вас разрабатывают. Этот вопрос меня заинтересовал, т.к. пообщавшись с некоторыми программистами, узнал что тестирование их ПО находится на зачаточном уровне, и вообще подходы разные совершенно. Еще вопрос меня заинтересовал, т.к. в программеры сам пришел из тестировщиков.

Вобщем-то вопросов несколько:
1. Есть ли тестировщики. (не просто бета-тестеры, а люди специально нагибающие программу и так и сяк). Если да, то насколько они эффективны и какое количественное соотношение программеров к тестерам
2. Ведутся ли баг-листы, если да, то какими средствами
3. Выпускаете ли вы бета-релизы, или к клиенту софт поступает полностью оттестированым
4. Часто ли бывают серьезные косяки в релизах
5. Какие собственные находки в тестировании можете озвучить

=======отвечу сам:
1. тестеры есть. примерно 3 тестера на 5 программеров, специального подчинения нет, тестят что скажут. Эффективность хорошая, иногда править не успеваем.
2. Да, TestTrack Pro
3. Нет
4. Редко, но бывают
5. Начинающие тестеры находят больше багов, опытные тестеры - меньше пропускают критических ошибок, сами могут предполагать заведомо багливые места.

← →
Anatoly Podgoretsky © (2006-10-27 09:48) [1]

Плохо обстаят, или сами или лохотрон.

← →
StriderMan © (2006-10-27 10:21) [2]

Похоже вопросы тестирования у мастеров действительно на зачаточном уровне.

← →
Jeer © (2006-10-27 10:42) [3]

StriderMan © (27.10.06 10:21) [2]
Я тебя заверю, что существует целая индустрия разработки тестирующего софта.

← →
VICTOR_ (2006-10-27 10:48) [4]

1. Профессиональных нет. Тестирует как правило постановщик задачи.
2. Да, собственная разработка.
Прототип
http://www.joelonsoftware.com/articles/fog0000000029.html
3. В крупных проектах - клиент получает и бета-релизы
4. Редко
5. Собственных нет - в теории уже все хорошо описано. Из реально помагающего в работе
- автоматическая рассылка всей истории ошибок по почте тем, кто на это подписан
- быстрый поиск по содержимому ошибки(полезно при поиске уже описанной ошибки)

← →
Суслик © (2006-10-27 10:48) [5]

> 1. Есть ли тестировщики. (не просто бета-тестеры, а люди
> специально нагибающие программу и так и сяк). Если да, то
> насколько они эффективны и какое количественное соотношение
> программеров к тестерам
> 2. Ведутся ли баг-листы, если да, то какими средствами
> 3. Выпускаете ли вы бета-релизы, или к клиенту софт поступает
> полностью оттестированым
> 4. Часто ли бывают серьезные косяки в релизах
> 5. Какие собственные находки в тестировании можете озвучить

1. Нет, сами тестируем + манажер (он же служба поддержки) - нас всего 4
2. Веду самостоятельно средствами word. Для некоторых проектов юзаем gmail. Скоро будем юзать bugzilla.
3. Полностью оттестирован? А такое бывает? Клиенту даем то, что не содержит ошибок (по нашем мнению есно).
4. Не было ни разу.
5. Просмотр кода при checkin"е в репозитарий.

← →
Игорь Шевченко © (2006-10-27 10:54) [6]

1. Есть
2. Ведутся
3. к клиенту софт поступает полностью оттестированым
4. Нет
5. Никаких

← →
StriderMan © (2006-10-27 10:55) [7]

> Jeer © (27.10.06 10:42) [3]
> Я тебя заверю, что существует целая индустрия разработки
> тестирующего софта.

Я в курсе. Туда же можно отнести контроль версий наверное

> Суслик © (27.10.06 10:48) [5]
> 5. Просмотр кода при checkin"е в репозитарий

поподробнее можно? не уловил.

← →
Суслик © (2006-10-27 11:01) [8]

> > 5. Просмотр кода при checkin"е в репозитарий
>
> поподробнее можно? не уловил.

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

← →
StriderMan © (2006-10-27 11:08) [9]

> Суслик © (27.10.06 11:01) [8]
> нужно долго и внимательно смотреть на то, что сделал.
> а то, что сделал очень хорошо видно при заливке

Я обычно в конце дня сливаю то что правил. А это как правило до нескольких десятков модулей, все не пересмотреть.

в систему
> versioncontol.

Это конкретный софт или любой? я юзаю VSS

← →
Суслик © (2006-10-27 11:21) [10]

> это как правило до нескольких десятков модулей, все не пересмотреть.

не делай так :)
вкратце.
Обычно ты если, что-то делаешь, то делаешь что-то конкретное: правишь конкретный баг, делаешь конкретную доработку или еще что.
Если у тебя уже устоявшаяся система, которая постепенно и плавно дорабатывается, улучшается (т.е. период первоначального становления пройден), то скорее всего ты именно так и делаешь, как сказано выше: т.е. делаешь что-то конкретное.
В этом случае - сделал конкретное, залей, напиши комментрий к тому, чо сделал, при заливке пересмотри то, что сделал.
Да, бывают случаи, когда приходится менять очень много модулей:например переименования модулей, классов, методов. Тут все не пересмотришь. В этом случае следует разделить заливку на две. Пример, допустим, тебе нужно пофиксить некий баг, в ходе фиксенья бага ты понял, что определенный класс должен быть переименован. Тогда делаешь так:
1. Переименовываешь класс по проекту, *без* смены функционала класса.
2. Заливаешь, описывая что и почему заливаешь. Модули не просматриваешь.
3. Правишь баг.
4. Заливаешь, описывая что и почему заливаешь. Модули просматриваешь.

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

> Это конкретный софт или любой? я юзаю VSS

Subversion форева!

← →
StriderMan © (2006-10-27 11:27) [11]

> Суслик © (27.10.06 11:21) [10]

пасибо за советы. А то у нас отслеживание изменений по принципу поиска " какой ..дак это сломал" :)

← →
Суслик © (2006-10-27 11:28) [12]

> пасибо за советы. А то у нас отслеживание изменений по принципу
> поиска " какой ..дак это сломал" :)

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

← →
Игорь Шевченко © (2006-10-27 11:28) [13]

StriderMan © (27.10.06 11:27) [11]

А разве при помещении в систему контроля версий авторство нельзя узнать ?

← →
Суслик © (2006-10-27 11:32) [14]

subverions кстати позволяет узнать кто и когда поменял конкретную строчку в конеретном файле.
во как:)

← →
Курдль © (2006-10-27 11:33) [15]

> Игорь Шевченко © (27.10.06 11:28) [13]
> А разве при помещении в систему контроля версий авторство
> нельзя узнать ?

Именно так оно и происходит! Время от времени все с замиранием сердца ожидают, когда админ CVS извлечет на свет это великое знание: "какой ..дак это сломал" :)

← →
Суслик © (2006-10-27 11:34) [16]

subverions кстати позволяет переименовывание и перемещение файлов/каталогов.
во как:)

ps. Это не реклама (он все равно фришный) - просто делюсь удовольствием от пользования сего продукта.

← →
Суслик © (2006-10-27 11:35) [17]

> subverions кстати позволяет переименовывание и перемещение
> файлов/каталогов.

subverions кстати позволяет отслеживать переименовывание и перемещение
файлов/каталогов.

← →
StriderMan © (2006-10-27 11:38) [18]

> Игорь Шевченко © (27.10.06 11:28) [13]
> А разве при помещении в систему контроля версий авторство
> нельзя узнать ?

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

> Суслик © (27.10.06 11:32) [14]
> subverions кстати позволяет узнать кто и когда поменял конкретную
> строчку в конеретном файле.

Вот этого в VSS нету.

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

ответственный - руководитель проекта. А проект достаточно большой.

← →
Суслик © (2006-10-27 11:41) [19]

> [18] StriderMan © (27.10.06 11:38)

> ответственный - руководитель проекта. А проект достаточно
> большой.

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

> Вот этого в VSS нету.

ясное дело.

← →
Суслик © (2006-10-27 11:42) [20]

> > [18] StriderMan © (27.10.06 11:38)

Если задача большая в ходе которой проект становится нерабочим, то для этого есть ветки - сиди в отдельной ветке, как доделаешь сольешься.

← →
Игорь Шевченко © (2006-10-27 11:43) [21]

StriderMan © (27.10.06 11:38) [18]

> Можно, но для этого нужно проползти по всем версиям и найти
> в какой добавился/исчез кусок кода, тогда можно установить
> кто эту версию залил.

Не понимаю

← →
StriderMan © (2006-10-27 11:48) [22]

> Игорь Шевченко © (27.10.06 11:43) [21]
> Не понимаю

Обнаружили ошибку в работе. нашли кусок кода в котором баг реализован. Далее надо найти версию, в которой этот кусок кода в модуле появился и по версии определить "какой ...дак ...". Для этого надо просмотреть всю историю изменений модуля. можно сократить время поиска методом половинного деления :)

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

> Обнаружили ошибку в работе. нашли кусок кода в котором баг
> реализован. Далее надо найти версию, в которой этот кусок
> кода в модуле появился и по версии определить "какой ...дак
> ...". Для этого надо просмотреть всю историю изменений модуля.
> можно сократить время поиска методом половинного деления
> :)

история строк из subversion тебе бы очень помогла в этом

> Игорь Шевченко © (27.10.06 11:49) [23]
> Я понял. Вы при внесении изменений сопроводиловку не пишете.
> ССЗБ.

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

Я работаю в большой софтверной компании (сотни программистов).
Имею (точнее имел) отношение к разработкам автоматизированных систем тестирования наших продуктов. Собственно, я об этом уже рассказывал, нет смысла повторяться http://home.earthlink.net/~akonshin/Workflow_in_PTC.html
Если есть более конкретные вопросы, то задавайте - отвечу.

Писать нужно всегда. Подробно не нужно - можно по коду понять, сравнив измененные модули.
Думаю, что рациональней всего делать так:
1. Пришло время заливать.
2. Описываешь, что и по какому поводу менял (номер бага или еще что).
3. Просматриваешь измененные модули.
4. Понимаешь, что ты намереваешься залить именно те модули, которые были по изменены по сути, описанной в п.2. Если затесались дополнительные модули, то либо корректируешь п.2 или разбиваешь на две заливки.
5. В заливаемых модулях если тебе видится, что так будет всем понятней, то вписываешь комментирии в местах изменений, или добавляешь описание в п.2.
6. Заливаешь.

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

1. Есть. Эффективны. Соотношение в частном случае ни о чём не скажет, поскольку количество тестировщиков должно зависеть от объёмов тестирования, IMHO. Объём — в литрах :o)
2. Ведутся. MS Outlook :-)
3. Не могу ответить на этот вопрос.
4. Частоту в герцах мерять? А серьёзность — в каких попугаях? :-)
5. Никаких.

> 4. Частоту в герцах мерять? А серьёзность — в каких попугаях?
> :-)

частота: багов/релиз
серьезность: (клиентов, которые требуют немедленно исправить)/клиентов

1. Нет. Программист сам тестер, если ему не облом.
2. Нет, разве что наскальные зарисовки на использованных A4, возможно, будет внедрена моя spe.
3. Нет, все что прошло через "испорченный телефон" и вернулось к заказчику считается релизом.
4. Верный вопрос звучит так - часто ли бывают "серьезные" релизы?
5. Писать программу так, чтобы не особо путаться в коде.

PS
Реалии украинских НИИ.

Тестирование Найти похожие ветки