Как вы думаете, должно ли тестирование производиться самим разработчиком или же на каком-то уровне (а может и на большинстве) его работу должен обязательно протестировать другой человек?
Тут наверное стоит разделить тестирование по категориям: на уровне алгоритма, класса, модуля, базовой функциональности интерфейса, юзабилити и т.д.
У меня на данный момент есть внутреннее убеждение, что на каком-то этапе конечно же работу разработчика ПО должен проверить другой человек.
Как, на ваш взгляд, должно производиться тестирование, начиная с написанного алгоритма, класса, кто и на каком этапе пишет автоматические тесты и т.д., проверяет ли кто-то другой качесто написанных тестов и т.д.?
Интересна будет не только, что говорит нам теория, но и ваша практика, опыт.

Здравствуйте, Димчанский, Вы писали:

Д>Как вы думаете, должно ли тестирование производиться самим разработчиком или же на каком-то уровне (а может и на большинстве) его работу должен обязательно протестировать другой человек?
Д>Тут наверное стоит разделить тестирование по категориям: на уровне алгоритма, класса, модуля, базовой функциональности интерфейса, юзабилити и т.д.
Д>У меня на данный момент есть внутреннее убеждение, что на каком-то этапе конечно же работу разработчика ПО должен проверить другой человек.
Д>Как, на ваш взгляд, должно производиться тестирование, начиная с написанного алгоритма, класса, кто и на каком этапе пишет автоматические тесты и т.д., проверяет ли кто-то другой качесто написанных тестов и т.д.?
Д>Интересна будет не только, что говорит нам теория, но и ваша практика, опыт.

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

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

Здравствуйте, Neila, Вы писали:

N>Здравствуйте, Димчанский, Вы писали:

N>Практика подсказывает, что тестирование на всех этапах должно производиться тестерами( спецыалистами по качеству, автотестерами и прочими).

N>Когда программист тестирует свой код, он не находит большого кол-ва багов.
Никто кроме программиста Unit тесты писать не будет.

N>Тут нужен нестандартный подход.
N>Вот например. В системе наблюдается утечка памяти. Но проявляется она только часа через 2.
N>И что, девелоперу ловить условия при которых наблюдается утечки и ждать по 2 часа?
N>Для этого и нужны тестеры.

А если программист написал код с ошибками (а это бывает регулярно) и не протестировал, то он узнает о некоторых из ошибок только через месяц, когда тестеры до него доберутся, а программист тем временем наколбасит еще мегабайт кода с ошибками?

Тестеры, конечно, нужны. Но Unit тесты должны писать разработчики.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Neila, Вы писали:

N>>Здравствуйте, Димчанский, Вы писали:

N>>Практика подсказывает, что тестирование на всех этапах должно производиться тестерами( спецыалистами по качеству, автотестерами и прочими).

N>>Когда программист тестирует свой код, он не находит большого кол-ва багов.
S>Никто кроме программиста Unit тесты писать не будет.

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

Выгод:
Допустим программист получает 1000 у.е.
Тестер 800 у.е

Программист сам пишет прогу и тесты 2 месяца. Допустим месяц прогу, месяц тесты. Получает 2000 у.е при некачественных тестах.
Программист + тестер делают это за месяц получаю 1800 + тесты качественные при сокращении времени.


N>>Тут нужен нестандартный подход.
N>>Вот например. В системе наблюдается утечка памяти. Но проявляется она только часа через 2.
N>>И что, девелоперу ловить условия при которых наблюдается утечки и ждать по 2 часа?
N>>Для этого и нужны тестеры.

S>А если программист написал код с ошибками (а это бывает регулярно) и не протестировал, то он узнает о некоторых из ошибок только через месяц, когда тестеры до него доберутся, а программист тем временем наколбасит еще мегабайт кода с ошибками?

Хм.. Допустим как это происходит у нас. Нас оповещают о исправления или дополнениях в коде. Мы целенаправленно ищем ошибку в исправленном. Так как тестер не один, и существуют машимы с разным набором исходных параметров, то шанс нахождения ошибки очень велик.
+ если исключить тестеров то ошибка найдется уже клиентами, что как сами понимаете не есть хорошо.



S>Тестеры, конечно, нужны. Но Unit тесты должны писать разработчики.

Здравствуйте, Димчанский, Вы писали:

Д>Как вы думаете, должно ли тестирование производиться самим разработчиком или же на каком-то уровне (а может и на большинстве) его работу должен обязательно протестировать другой человек?
Д>Тут наверное стоит разделить тестирование по категориям: на уровне алгоритма, класса, модуля, базовой функциональности интерфейса, юзабилити и т.д.
Д>У меня на данный момент есть внутреннее убеждение, что на каком-то этапе конечно же работу разработчика ПО должен проверить другой человек.
Д>Как, на ваш взгляд, должно производиться тестирование, начиная с написанного алгоритма, класса, кто и на каком этапе пишет автоматические тесты и т.д., проверяет ли кто-то другой качесто написанных тестов и т.д.?
Д>Интересна будет не только, что говорит нам теория, но и ваша практика, опыт.

Готовый продукт, юзабилити (удобство, понятность, логичность, дизайн) — однозначно должен смотреть кто-то другой. У программиста глаз замылен, ему просто в голову не придёт, что что-то неудобно-непонятно-можно было сделать иначе. Тут нужна свежая голова.

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

Здравствуйте, Neila, Вы писали:

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

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

N>Допустим на предприятии есть программер. Он написал класс. Если он-же будет писать еще и тесты к своему классу, то
N>1. Он может не подумать что класс не сработает при определенных услловиях
N>2. Он потратит большое кол-во времени, которое мог бы потратить на написание другого класса.

А если при написании теста он подумает, что может возникнуть такой и такой вот случай, и потом реализовать их при создании класса. Правильный подход — писать тесты до создания класса. В результате:
1. глаз еще не успевает замылиться.
2. до создания класса успеешь продумать особые случаи, которые иначе можешь забыть при написании кода класса.
3. Код потом писать оказывается легче и быстрее.

N>Выгод:
N>Допустим программист получает 1000 у.е.
N>Тестер 800 у.е

О как. А скупой платит сколько? Вообще я не считаю, что тестер находится где-то ниже программиста. Хорошего тестера найти будет ничуть не проще чем хорошего программиста. И пользы от него — не меньше.

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

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


Ну и незначительная мелочь, которая нервов попортит. Юнит тест не работает. Кто виноват? Это ошибка в коде или в тесте?

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


Мое мнение — юнит тесты — писать программисту, и нужны они главным образом самому программисту. Для упрощения отладки, рефакторинга и в целом для упрощения разработки и уменьшения общения с тестировщиками по мелочам.
Тестерам — функциональное тестирования всего приложения целиком, не влезая во внутренности.
Так гораздо лучше получается.

Здравствуйте, Neila, Вы писали:

N>Здравствуйте, samius, Вы писали:

S>>Никто кроме программиста Unit тесты писать не будет.

N>Не факт, можно выделить должность юнит-тестера. Если ты видишь чужой класс (пусть даже интерфейс класса) ты можешь сделать предположения , что этот класс не будет работать при определенных условиях.
N>Допустим на предприятии есть программер. Он написал класс. Если он-же будет писать еще и тесты к своему классу, то
N>1. Он может не подумать что класс не сработает при определенных услловиях
N>2. Он потратит большое кол-во времени, которое мог бы потратить на написание другого класса.
N>Если у нас есть юнит-тестер то написанием тестов занимается он.
N>1. Программист не тратит время.
N>2. Так, как задача юнит-тестера заключается в подборе случая в котором класс не сработает, он делает это более целенаправленно и соответственно качественно.
С этим согласен. Хотел спросить, всегда ли возможно написать unit-тесты для любого класса без вмешательства в код класса?
Если разработчик не заморочен на тестирование, он и не подумает над тем, как будут тестировать его код. Как следствие, код будет получатсья сильно связным и не поддающимся тестированию.

N>Выгод:
N>Допустим программист получает 1000 у.е.
N>Тестер 800 у.е

N>Программист сам пишет прогу и тесты 2 месяца. Допустим месяц прогу, месяц тесты. Получает 2000 у.е при некачественных тестах.
N>Программист + тестер делают это за месяц получаю 1800 + тесты качественные при сокращении времени.
Не верю я в то, что можно написать качественные тесты без соответствующего дизайна кода.
А если проект на год, то год прогу и год тесты? У меня цикл разработки гораздо короче (порядка нескольких минут). Соответственно, об большинстве ошибок я узнаю по мере написания, а не через месяц/год, когда уже буду заниматься другой программой в другой конторе.

Здравствуйте, Neila, Вы писали:

А у меня другой калькулятор. Основывается он на двух предпосылках:
1) Непосредственное кодирование занимает менее 50% времени (и этот показатель сильно завышен, иначе мы бы работали как машинистки -- 300 знаков в минуту)
2) Чтобы написать класс и/или тест к нему нужно потратить время на анализ требований к классу

Посчитаем? Думаю несложно сделать выводы.

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

Причем тесты нужно писать ДО кодирования:
а) Тесты ни что иное как формализация требований, при их написании моут проясниться некоторые моменты требования или появиться вопросы которые необходимо уточнить
б) Может возникнуть желание подогнать второе под первое: подгонять класс под тесты много лучше чем тесты под класс (даже больше -- подгонять класс под тесты (требования) и является задачей программиста)


СУВ, Aikin

Здравствуйте, Neila, Вы писали:


N>Не факт, можно выделить должность юнит-тестера. Если ты видишь чужой класс (пусть даже интерфейс класса) ты можешь сделать предположения , что этот класс не будет работать при определенных условиях.
N>Допустим на предприятии есть программер. Он написал класс. Если он-же будет писать еще и тесты к своему классу, то
N>1. Он может не подумать что класс не сработает при определенных услловиях
От этого лечит замер code coverage. Если в коде есть "особенности", которые не покрываются юнит-тестами, то это будет обнаружено.
Могут, конечно, встретиться случаи, когда в классе банально не реализована нужная функциональность, но это как раз покрывается интеграционным и функциональным тестированием.

N>Выгод:
N>Допустим программист получает 1000 у.е.
N>Тестер 800 у.е
Непонятно, почему тестер получает меньше.
N>Программист сам пишет прогу и тесты 2 месяца. Допустим месяц прогу, месяц тесты. Получает 2000 у.е при некачественных тестах.
N>Программист + тестер делают это за месяц получаю 1800 + тесты качественные при сокращении времени.
А два программиста напишут прогу за 1 месяц, 2000 и с хорошими тестами.
S>>А если программист написал код с ошибками (а это бывает регулярно) и не протестировал, то он узнает о некоторых из ошибок только через месяц, когда тестеры до него доберутся, а программист тем временем наколбасит еще мегабайт кода с ошибками?

Здравствуйте, Димчанский, Вы писали:

Д>Как вы думаете, должно ли тестирование производиться самим разработчиком или же на каком-то уровне (а может и на большинстве) его работу должен обязательно протестировать другой человек?
Д>Тут наверное стоит разделить тестирование по категориям: на уровне алгоритма, класса, модуля, базовой функциональности интерфейса, юзабилити и т.д.
Д>У меня на данный момент есть внутреннее убеждение, что на каком-то этапе конечно же работу разработчика ПО должен проверить другой человек.
Д>Как, на ваш взгляд, должно производиться тестирование, начиная с написанного алгоритма, класса, кто и на каком этапе пишет автоматические тесты и т.д., проверяет ли кто-то другой качесто написанных тестов и т.д.?
Д>Интересна будет не только, что говорит нам теория, но и ваша практика, опыт.

Практика:
1. Каждый программист пишет юнит тесты _до_ написания кода.
2. При исправлении найденной ошибки сначала пишется новый юнит тест, а только потом исправляется ошибка.
3. Выделяется отдельный программист, который досконально знает ожидания заказчика, т.е. то что программа должна делать. Он пишет интеграционные тесты.
3. Программирование ведется парами: два человека за одним компом, контроль написанного непрерывный.
4. Подмножество юнит тестов для изменяемого кода прогоняется при каждом билде.
5. Все юнит тесты и интеграционные тесты прогоняются при каждом чекине. Плюс при каждом чекине собирается и тестируется инсталляция продукта (устанавливается, сносится, проверяется что все подчищено).
6. Отдельные сервера тестирования непрерывно и круглые сутки гоняют model-based tests для текущего билда.
7. Интерфейс и юзабилити тестируется обычными тестерами-обезьянами.
8. Специалист по качеству (QA) не занимается тестированием, а отвечает за такую организацию процесса разработки, которая обеспечивает требуемый уровень качества. Он же (совместно с PM) определяет этот уровень для текущей фазы проекта.
9. Разрабатывается инфраструктура для автоматического сбора и анализа дампов при падении программы. На основе дампов и логов работает автоматический файлер багов, который распознает уже известные баги.
10. Ведется нормальный учет багов.

Тестирование в привычном виде "вот вам, тестеры, программа — потыкайте кнопки" практически бесполезно.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Neila, Вы писали:


N>>Не факт, можно выделить должность юнит-тестера. Если ты видишь чужой класс (пусть даже интерфейс класса) ты можешь сделать предположения , что этот класс не будет работать при определенных условиях.
N>>Допустим на предприятии есть программер. Он написал класс. Если он-же будет писать еще и тесты к своему классу, то
N>>1. Он может не подумать что класс не сработает при определенных услловиях
S>От этого лечит замер code coverage. Если в коде есть "особенности", которые не покрываются юнит-тестами, то это будет обнаружено.

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

Здравствуйте, MaxSem, Вы писали:
S>>От этого лечит замер code coverage. Если в коде есть "особенности", которые не покрываются юнит-тестами, то это будет обнаружено.
MS>Процент покрытия — слишком обманчивая цифирь. Он отражает лишь процент исполненных ветвей, но не адекватность проверки результатов их выполнения. Могут выйти грабли.
Не понял про адекватность. "Не сработает при определенных условиях" — это как раз проход по другой ветке кода.

Нет, конечно же есть и другие способы получить неожиданное поведение; выброс исключения позволяет "отбранчиться" в любой строчке. Но в большинстве случаев это корректное поведение: если у нас метод не рассчитан на получение null параметра, то он прекрасным образом вылетит, что согласуется с его контрактом. Как только контракт усложняется — появляется код, который обрабатывает эту ситуацию особым образом, и появляются тесты, которые проверяют, что всё корректно.

Можно прояснить ваш тезис?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, MaxSem, Вы писали:
S>>>От этого лечит замер code coverage. Если в коде есть "особенности", которые не покрываются юнит-тестами, то это будет обнаружено.
MS>>Процент покрытия — слишком обманчивая цифирь. Он отражает лишь процент исполненных ветвей, но не адекватность проверки результатов их выполнения. Могут выйти грабли.
S>Не понял про адекватность. "Не сработает при определенных условиях" — это как раз проход по другой ветке кода.

Не обязательно. К примеру (пример условный, так писать нельзя, но идею передаёт):

List<Student> retrieveStudents(Integer minAge, Integer maxAge) {
  String query = "SELECT * FROM students ";
  if(minAge != null) {
    query += "WHERE age >= " + minAge;
  }
  if(maxAge != null) {
    query += "WHERE age <= " + maxAge;
  }

  return execute(query);
}

При этом имея два теста, на minAge и на maxAge (которые покрывают 100% вышеприведенных строк) не покроют одну проблему — minAge и maxAge вместе не работают.

Здравствуйте, WFrag, Вы писали:

WF>При этом имея два теста, на minAge и на maxAge (которые покрывают 100% вышеприведенных строк) не покроют одну проблему — minAge и maxAge вместе не работают.
Круто, не подумал. Действительно, из покрытия всех веток не следует покрытие всех путей.

Ну, вообще code coverage — это "не закон, а рекомендация", как и пиратский кодекс. В том смысле, что из coverage < 100% следует однозначный вывод о необходимости доработки тестов, а вот из 100% делать выводов уже нельзя.
К "счастью", подавляющее большинство проектов находятся в состоянии, безнадежно далеком от 100%, поэтому обсуждаемая проблема для них столь же актуальна, как и вопрос "что делать с квартирой 1000м на садовом кольце".

Здравствуйте, Димчанский, Вы писали:

Д>Как вы думаете, должно ли тестирование производиться самим разработчиком или же на каком-то уровне (а может и на большинстве) его работу должен обязательно протестировать другой человек?
Д>Тут наверное стоит разделить тестирование по категориям: на уровне алгоритма, класса, модуля, базовой функциональности интерфейса, юзабилити и т.д.
Д>У меня на данный момент есть внутреннее убеждение, что на каком-то этапе конечно же работу разработчика ПО должен проверить другой человек.
Д>Как, на ваш взгляд, должно производиться тестирование, начиная с написанного алгоритма, класса, кто и на каком этапе пишет автоматические тесты и т.д., проверяет ли кто-то другой качесто написанных тестов и т.д.?
Д>Интересна будет не только, что говорит нам теория, но и ваша практика, опыт.
Практика говорит, что в любой промышленности при разработке нового изделия есть конструктор (архитектор), есть инженер-расчетчик, есть изготовитель, есть испытатель. И это все разные люди. В строительстве, например, аж три проекта: архитектурный, инженерный, проект производства работ. И все их делают разные люди. Так и должно быть, потому как разделение труда. Информационные технологии только встали на этот путь, поэтому сейчас кажется, что можно совмещать.

Не нужно смешивать строительство мостов/домов и программирование. Это ведет к неверным аналогиям и неверным выводам.
Практика показывает, что принятые в строительстве методы проектирования (waterfall-like) совершенно не работают при разработке ПО.

Здравствуйте, abibok, Вы писали:

A>Не нужно смешивать строительство мостов/домов и программирование. Это ведет к неверным аналогиям и неверным выводам.
согласен
A>Практика показывает, что принятые в строительстве методы проектирования (waterfall-like) совершенно не работают при разработке ПО.
откуда сведения что в строительстве waterfall-like, если времени на проектирования много, что сразу waterfall ?

C>откуда сведения что в строительстве waterfall-like, если времени на проектирования много, что сразу waterfall ?

Потому что проект здания очень детально прорабатывается до начала строительства и потом уже не изменяется. Небольшие отступления от проекта стоят очень дорого и не всегда возможны. Существенные отступления могут закончится заморозкой строительства и полной переделкой. Рефакторинг не возможен. Тестирование только в виде smoke приемочного "здание не пока не развалилось и коммуникации подключены — ок". По моему, чистый waterfall. Можете привести пример agile style стройки?

Здравствуйте, abibok, Вы писали:

C>>откуда сведения что в строительстве waterfall-like, если времени на проектирования много, что сразу waterfall ?

A>Потому что проект здания очень детально прорабатывается до начала строительства и потом уже не изменяется. Небольшие отступления от проекта стоят очень дорого и не всегда возможны. Существенные отступления могут закончится заморозкой строительства и полной переделкой. Рефакторинг не возможен. Тестирование только в виде smoke приемочного "здание не пока не развалилось и коммуникации подключены — ок". По моему, чистый waterfall. Можете привести пример agile style стройки?

Полностью согласен в том что сравнивать программирование и строительство нельзя и даже опасно.
Нужно только уточнить, что проектирование дома и строительство дома — это разные этапы.
Проектирование дома вполне может быть Agile. Строительство — только Waterfall
При разработке софта же проектирование и реализация очень взаимосвязаны и переплетены. Говорят, что японцы постигли дао ватерфола — сначала все спроектировать до последней-распоследней функции, потом взять и закодить, но процент успешных проектов у них не намного выше.