задачка для понимающих

[dieash]

Из серии "как правильно", или о взаимодействии групп разработки и тестирования. Мой опыт показывает, что это, в общем-то, повсеместно больная тема.

Есть различные анти-паттерны. Крайние случаи, когда программисты позволяют себе фразочки " QA нам своими ошибками мешает работать", "Ну я тут, типа, что-то исправил, а для проверок у нас QA есть" - не

Comments

[v_i_y]

сам твой вопрос
если ошибка не воспроизводится в trunk-версии, значит ошибка исправлена.
вызывает массу вопросов :)

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

вообще если в какой-то версии была проблема, но программист её не смог раскопать, ссылаясь на то, что "а у меня вот из транка сейчас не повторяется, а может само пофиксилось" - они чреваты конечно.

зы. давай уже не томи, говори правильный ответ :)

[dieash]

да чё тут тянуть-томить, Юра ниже всё уже изложил.
и это правильно, считаю :)

[another_felix]

Я тоже похожее писал, но он опередил! :(

[dieash]

ну вот. ты тоже понимаешь!

[yurine]

В том окружении, где проверяют в транке и ошибка не повторяется, поставить x.y.p.b и проверить (в т.ч., если надо, на данных QA). Если не повторяется, дальше разбираться в окружении QA или искать факторы, которые позволят повторить у себя.

Если в старой версии повторяется, а в транке -- нет, здесь возможны два варианта.
1. Найти ошибку в старом коде и смотреть код в транке, почему не повторяется и надо ли что-то всё-же исправлять. Более надёжный подход.
2. Оставить как есть, с осознанием, что "ещё вылезет", и, возможно, это выйдет весьма боком. Оправдательной причиной здесь может быть нехватка времени, хотя порой лень и нежелание.

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

[dieash]

Юр, спасибище тебе огромное за! как бальзам на старую рану! :) Собственно, примерно так и объяснял. Результат выше описан... Ведь, казалось бы, такие очевидные вещи. Ан нет.

На мой взгляд, зачастую вопрос с нехваткой времени очень второстепенный. скорее, следствие. В первую очередь либо лень с нежеланием, либо просто незнание. С последним проще "бороться" - достаточно подсказать и рассказать о возможных последствиях. А вот с первым...

[yurine]

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