Требуется тестировщик программного обеспечения

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

maximkr,
оффтопик, но из того, что ты написал можно сделать вывод: с TDD плотно не работали, знания по наслышке. Лень мне ребатить все пункты, коротко о главном:
1. Тесты не несут в себе какой-то сложной логики, есть входные данные, есть ожидаемый результат - тестирование - проверка попадания результата в допустимый интервал. т.о. мысль об сопоставимости по сложности написания основного кода и тестов, мягко говоря, преувеличение.
2. Тесты - это хорошая, краткая (по теме) документация кода. Вы же не пренебрегаете комментариями?
3. В зависимости от того насколько tightly coupled ваш код тесты выявляют неработоспособный код до этапа production. Пример: есть 100к строк кода, потребовалось изменить несколько небольших кусков. Итог: run time error - очевидно при изменении кода не учли какие-то нюансы. Решение - поиск бага вручную, хотя если бы были тесты данный процесс ускоряется на порядки.
4. Да у unit тестов своя "target audience" но она близко не лежит с тем что написано выше.
Ну и закрывающая мысль напоследок. Каждый кодер мыслит категориями unit тестов на подсознательном уровне. Никто же не пишет программы от начала и до конца ни разу не запустив их! Прблема в том , что написание кода задача не линейная а скорее рекурсивная и отследить все тонкости имплементации отдельно взятого unit-а либо тяжело либо невозможно (team work, off-site programming). А кому же хочется обнаружить после долгих дней ковыряния с одним куском, что "собака порылась" совсем в другом месте

Re: re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Мне тоже лень меряться у кого больше опыта в тестировании, пропустим этот этап

Это не совсем так:
1) Hibernate 3.1.3 - на 4.1 МБ исходника имеем 1.9 МБ тестов. При том что не самое сложное для автоматизации тестирования приложение.
2) Некоторые вещи проверить не проще чем сделать. Например, вычисление синуса.
3) Ожидаемый _кем_ результат ? Если программистом - оно никому не интересно, если клиентом - это тестом не проверишь.

Такая документация не заменяет нормальную никак. Если нормальную все равно придется писать (или не придется) - зачем париться с тестами ?

Ну может быть иногда они и выявляют, но в куче случаев проблема в другом и unit test ее выявить принципиально не сможет. Зачем тратить на это время ?

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

Вот и у нас аналогичная ситуация - тесты даже запускать не хочется, не то что писать.

Да, поэтому и популярны unit tests в open source, т.е. в коде который пишется программистами для программистов, по большей части.

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

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

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Что значит "плотно"? Работали, не пошло.

Мое мнение: unit-тестирование - совершенно неоправдывает себя при написании коммерческого прикладного софта. Юнит-тестированием тестируются, соответственно, юниты Логика обработки данных. Коммерческие прикладные приложения пишутся не с нуля, а строятся на готовых пакетах, опенсорсных или коммерческих же (у нас много чего разного используется, много чего - именно куплено). И чего в таком случае нужно юнит-тестировать?
Далее: у нас, в частности, web-приложение. Там используется j2ee, j2se, jsp, struts, базы данных+драйвера к ним, javascript, dhtml. Глючат чаще всего не какие-то конкретные компоненты, а связки между компонентами. Например, из скрипта не создается база данных или создается с ошибками. Нафиг тут юнит-тест, она и так или создается или нет. Глючит javascript, причем не самописный, а именно купленный. Или отваливаются css.
Было бы, кстати, интересно посмотреть нашу статистику, какого рода ошибок у нас больше всего.

Во-о-т. А тестировщик по-прежнему нужен. На $2/per hour, без юнит-тестов, без умения программировать, без знания рефакторинга, экстремального программирования, паттернов, code coverage и т.п.
Желательно - со знанием как установить MS SQL, Oracle и т.п.

Re: re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Или программиста, который собирается её писать Написание тестов собственно до написания самого кода (когда программист ещё не знает деталей реализации, а значит и не будет неосознанно обходить слабые места) весьма помогает в работе. По крайней мере мне.

По большому счёту именно так, но unit-test`ы и отдел тестирования никак не противоречат друг-другу, наоборот, дополняют.

Насчёт значительного изменения архитектуры не возьмусь судить, не имею такого опыта. Но при относительно малых изменениях они очень помогают - доработал/изменил что-то, запустил тесты и уверен, что всё осталось в рабочем состоянии.

Да, для отдельных модулей оно самое то. Однако и работу в связке тоже весьма неплохо можно проверять. У нас помимо модульных тестов есть и "сквозные": от hibernate-level через mbeans, sessionBeans (под jboss) до нескольких уровней dao на клиентской стороне (ex: клиентский кэш). Конечно, таким образом не всё можно протестить, но ключевые моменты охватитить вполне по силам.

Вроде как и у нас коммерческий софт. Видимо, попадаем в меньшинство

Re: re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

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

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

А у нас это не работает т.к.

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

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

Кстати, лишняя уверенность может быть даже вредна Тут читал интересную статистику по поводу ДТП. После курсов по обучению вождению в сложных ситуациях (гололед, ночь) количество ДТП в этих ситуациях увеличивалось на 10-20%. Вывод из этой истории был сделан такой - учить можно, но внушать чувство уверенности - нельзя.

Хм, а что делать в такой ситуации:
1) Есть метод создания пользователя, нужно его потестировать в разных ситуациях.
2) Ситуации - это не только параметры на входе, а разные конфигурации базы (кто пользователя создает, какие у него права, где пользователь создается, какие есть связанные объекты и т.п.)
3) Для того чтоб протестировать этот метод - нужно сгенерить штук 10 баз (одна тестовая база - SQL на 500 кб), попробовать там создать пользователя, посмотреть что получилось.
4) Если у нас таких методов сотня, то получаем что-то около 1000 тестовых баз данных.
5) А теперь у нас в новой версии полностью меняется система назначения прав/скриптовое API/что-нибуль еще. И все - приплыли. Нужно руками обновлять 1000 баз, иначе ни один тест не запустится, т.к. система завалится при попытке "подцепить" старую базу.

Идеи ?

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

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

Антиоффтопик - с тестировщиком все еще не определились, если кто хочет работать - еще не поздно.

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Ну, это не совсем рефакторинг.

А вот, кстати, сегодня правил багу, которая в юнит-тестах бы точно вылезла - с копированием статусов.
Но до этого недели две были баги либо в javascript, либо от базы клиента зависят.

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

winzard, Нашелся тестировщик-то?

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

winzard, на эту должность подойдёт человек с навыками Advanced User'a? ато есть у меня кандидатурка на примете...

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Alexaf, да

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

Vastey, А расширять ОТ собираетесь?
Есть кандидатура с опытом работы в ОТ.

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

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

re:фТЕВХЕФУС ФЕУФЙТПЧЭЙЛ РТПЗТБННОПЗП ПВЕУРЕЮЕОЙС

anovikov, шИртесь вглубь, что-ли.....