Спасибо всем за подсказки. Привет Raperonzolo! Про требования, конечно я утрировала - должны быть по-любому. Хотя я спросила про "Anforderungen"( скорее всего мы не поняли друг друга).

Меня как раз и "прикрепили" к двум разработчикам (одна- Фронтэнд, второй-не поняла). Их приглашали по очереди на собеседование и спрашивали, готовы ли они со мной "возиться" по 2 часа в неделю примерно или нет. Проблема, что у них Agile, ну даже если это и гибкая разработка, не значит, что требований не должно быть. Ещё у них мало Webа как я поняла после прочтения их портфолио в интернете. Они готовят в основном высокотехнологичные фичи ( включая искусственный интеллект) для очень известных производителей, банков, страховых и Big Data ещё есть.

Поэтому я немного стрессую: ну где искусственный интеллект - а где я...

Зато есть личные проекты сотрудников, выставленные на сайте, в процессе разработки - это в основном Web.

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

Узнать мнение о чем? :) Хорошо ли, когда в команде есть тестировщик? Да, хорошо.

Берет ли тестировщик на себя работу программиста? Нет, не берет.

Лучше ли качество кода, если в команде есть тестировщик? Нет, не лучше.

Если вы считаете, что тестировщики никак не влияют на качество кода (а значит и конечного продукта) и они не берут часть работы на себя, и на вопрос: нужны ли они в команде?, отвечаете: да.... То я не вижу в этом логики....

вы считаете, что...

-----

...тестировщику, как и программисту, надо уметь читать то, что написано, а не то что он читает...

не вижу в этом логики

-----

Они влияют именно на конечный продукт.

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

"находя места возможных/реальныx ошибок"

....которые находятся и в КОДЕ в том числе....

Нет?

Поэтому я немного стрессую: ну где искусственный интеллект - а где я...

Не переживайте, искусственный интеллект вам тестировать вряд ли дадут). Найдут для вас формочки какие-то.

и в КОДЕ

-----

Работа тестировщика - СЛОМАТЬ - то, что программист считает надежно работающим. Только СЛОМАТЬ!!!

При этом ты "не должна знать" ГДЕ, ЧТО и КАК программист делает... ты должна знать как это СЛОМАТЬ.

Лучше ли качество кода, если в команде есть тестировщик? Нет, не лучше.

Ну... опосредованно. Смотря как разделить "качество кода" и "качество продукта", конечно. Если тестер что-то делает, то как минимум улучшается "Functional Suitability" (ISO 25010).

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

код после исправления ошибок, найденых тестером, становится качественнее

-----

Интересно, почему, в случае длительного сопровождения, нахождения и фиксинга кучи багов, именно код - деградирует?

Оно как? Кто-то написал, потом ушел, потом оно где-то сдохло, посыпались массовые жалобы, тестеровщик - подтвердил наличие проблемы, открыли таску на фиксинг и скинули на свободного, пофиксил он как мог в отведенное время - откуда будет качество у кода?

Смотрю сейчас код.

Чел написал:

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

- с остальным работать используя в цикле целочисленные индексы для доступа к полям в строке.

Из того что вижу - выход индексов за пределы количества полей - регулярный.

Пофиксил - индекс перестал выпрыгивать за пределы строки.

Качество кода улучшилось? С чего бы - Я все так же не понимаю что и как он считает - Я пофиксил, как мог, только выход индекса за пределы строки и код слегка деградироваl...

Качество кода - это в первую очередь то, что понимается под clean code, т.е. это документация, создание интуитивно понятного (читаемого) кода, создание тестируемого (юнит-тестами) кода итд. На все это тестировщик никак не влияет.

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

Кроме того, в общем случае, тестировщик не может проверять отказоустойчивость системы. Т.е. можно конечно запустить продукт и выдернуть сетевой кабель, но это не всегда можно (у нас например софт тестируется на виртуальных машинах через remote desktop), а отрубить жесткий диск или перевести время на час назад в процессе обработки данных или просто инициировать виндоус апдейт просто невозможно. А ведь зачастую именно такие проблемы и всплывают.

Зачем же нужны тестировщики?

Тестировщики прогоняют существующий продукт по "зеленому" сценарию, т.е. задача тестировщика убедиться в том, что в идеальных условиях продукт работает и взаимодействует со внешним миром как надо. Также тестировщик может проводить deployment test'ы, т.е. сценарии апгрейда. Все это очень тягомотная, однообразная и вместе с тем нужная работа.

вы только что не сдали istqb.

Разработчик ВСЕГДА собьется с того "как оно должно" на то "как оно сделано".

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

Если вы считаете, что тестировщики никак не влияют на качество кода

Есть код, а есть продукт. Тестировщики тестируют продукт. Код может быть ужасным, с кучей костылей, но если функционал работает корректно, то тестировщику пофиг, что там внутри. Другое дело, что в будущем при расширении функционала, к примеру, плохой код всегда наделает кучу проблем.

Работа тестировщика - СЛОМАТЬ - то, что программист считает надежно работающим. Только СЛОМАТЬ!!!

Это что еще за хрень? Какие сломать? Работа тестировщика - подтвердить, что продукт работает соответственно выдвинутым требованиям.

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

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

------

Не ЕСЛИ, а КОГДА.

А одернуть - нельзя - в силу не знания предметной области.

не собьется.

------

Тaк не бывает.

А Я что-то сдавал?

Ну хорошо - комиссию - к стенке...

Работа тестировщика - подтвердить, что продукт работает соответственно выдвинутым требованиям.

------

Что работает согласно спекам - может подтвердить и прогер.

От тестировщика, по крайней мере Я, ожидают нахождение имеющихся и потенциальных проблем.

См. AlexNek и его упоминания об тестировщице догадавшейся выдернуть кабель...

Не переживайте, искусственный интеллект вам тестировать вряд ли дадут).

:)))) я тоже об этом подозреваю...

Однако боюсь им чё-нить не сломать :))