Господа, у Вас такие умные разговоры, сценарии какие-то, кто решает что сценарий покрывает такое-то число процентов случаев... Я вот только одного понять не могу, почему я всего этого не знаю и живу спокойно? И даже как-то программы пишу и в лучшем случае даю их другому сотруднику потестить, а чаще просто тесчу сам и без всяких там сценариев и т.п. Наверное, это от того, что проекты у меня маленькие один-два, максимум 3 программиста? Или это мы просто ламеры все?

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

Контора разрабатывает приборы, причем порой аналогов не имеющие (даже у меня есть один патент, а у некоторых их штук 10), то бишь имеется штук 5 конструкторов, штук 5 программистов, штук 5 электонщиков, штук 5 непонятно-чем-занимающихся-личностей (мы их называем идеологами), пара непосредственных начальников. Ни о каких тестировщиках мы слыхом не слыхивали. Обычно идеологи в общих чертах описывают всем остальным что надо делать (хотя в наших демократических стенах в совещаниях может принимать участие каждый и высказывать свои новые идеи), программисты кооперируются с электронщиками и когда у нас в результате нашего спонтанного труда возникает новое чудо техники, мы отдаем его идеологам, они вносят замечания (на этой стадии происходит и простейшее тестирование) и процесс повторяется. Потом процесс повторяется уже с учетом замечаний заказчика. Что касается программистов, обычно на один проект хватает одного программиста. За 3 года я вел только один проект, в котором учавствовало трое. Я не считаю тех случаев, когда в приборе есть несколько разных систем, например, микропроцессор под который пишут на голом C, и компьютер, под которым Windows. Тут программистов несколько, но они кооперируются только в области протоколов взаимодействия. К слову сказать, о таком, чтобы один человек продумывал структуру классов или БД, а другой кодировал, тут тоже никто не слышал.

Как это происходит в "нормальных" конторах? Насколько актуально нам что-то менять в процессе разработки ПО?

alexeyvgMikeKSК слову сказать, о таком, чтобы один человек продумывал структуру классов или БД, а другой кодировал, тут тоже никто не слышал.Т.е. у вас человек делает структуру БД, вечером пишет веб-клиента, а наутро принимается за программирование микроконтроллера???


Ну, не совсем. Один человек пишет под микроконтроллеры, другой - под винду. С другой стороны, я разрабатывал ПО дефектоскопа, у которого внутри был PC104. Мы решили, что будем использовать MS Windows Embedded. Я разбирался в сборке и администрировании MS Embedded, ставил его, настраивал; писал программу этого дефектоскопа тоже я. Что значит писал программу? Значит мне вкратце сказали, какой примерный должен быть интерфейс и какая вообще идея прибора. По ходу работы все это уточнялось или придумывалось по мере надобности. Например, в процессе плотной работы по поиску неисправностей в ПО / электронике стало очевидно, что с таким количеством каналов очень трудно отследить обрывы отдельных датчиков. В результате я придумал, что нужен специальный тест при старте прибора, который бы отслеживал обрывы. Как оценить наличие обрыва никто на тот момент не знал. То есть можно сказать, что я придумал идею, что надо тестировать обрывы, способ тестирования, проверил его и внедрил его в ПО. Что еще? Формат файла хранения результатов, структура БД для программы отображения и сама программа отображения. В общем-то все это делалось одним человеком. Когда готово, отдаю соседу, он тестирует путем работы с прибором. Если все работает и ему удобно, отдаем заказчику. Вот я и спрашиваю, правильный ли подход или нужно его менять? И как вообще дело обстоит у других фирм?

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


Согласен, ведь я не работаю в SolidWorks, не стою у станка и не развожу печатные платы. И специальность у меня вполне определенная - ведущий программист.

alexeyvg
MikeKSПро TDD я слышал. Но я работаю видимо в какой-то диназаврской конторе (тем не менее я очень сомневаюсь, что это уникальная ситуация). Я сейчас расскажу как у нас это дело происходит, а Вы мне пожалуйста расскажите как это происходит в большинстве "нормальных" контор, так как больше нигде программистом я пока не работал и поэтому чувствую себя не совсем ловко при поиске новой работы.

Чем сложнее и больше проект, тем больше необходимость в специализации и, в частности, в выделенном тестировании.


То есть, если в проектах работают 1-3 человека, специализация, все это тестирование, TDD и прочее, не так уж и нужно?

alexeyvg
Если одним проектом занимаются 10 человек в течении года, и эти 10 человек будут программистами, делающими всё, то проект может и не закончится :-(

У нас таких больших проектов нет. У нас всего по направлению работают 25 человек. Программистов из них 6 человек.

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

Я представляю сколько нужно денег, чтобы нанять еще 6 человек. А экономическая выгода от этого предприятия не очень очевидна даже мне, что уж там говорить о руководстве. Нет, я Вас полностью поддерживаю, просто я не очень понимаю, чем конкретно будую заниматься эти люди.

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

САМОЕ ГЛАВНОЕ. В чем заключается работата тестировщика? Какие знания для этого нужны? Запустить программу, потыкать мышкой и посмотреть падает или нет - это я понимаю. Написать программу, которая будет за место человека мышкой тыкать по программе (1000 раз нажать открыть/закрыть файл, например) это я тоже могу себе представить. Также я слышал, что для тестирования в исходный код внедряются какие-то дополнительные функции (bool test() ?), которые потом каким-то образом вызываются тестировщиком и по анализу их работы делается вывод о работоспособности приложения. Эту идею я правильно уловил? А что это за функции и что они делают? Давайте, на примере. Я пишу программу типа "Блокнот". Какие тесты я должен создать?