?

Log in

No account? Create an account
Моя тестовая лаборатория

Как грамотно пиииип разработчика

Метки:

Comments

Наши реалии таковы, что они незаёбываются никак. На некоторый проблемы просто забивают и всё :) По крайней мере, в рамках релиза.
Честно говоря, мне не совсем понятно, что значит "забивают" на проблемы?
У вас такое допускается?
Забивают - значит, что переносят с текущего релиза на следующий или ещё дальше.
Надо, чтобы он все время чувствовал, не важно что, просто чувствовал и находился в постоянном чувстве тревоги.

А еще его можно вызывать среди выходных на работу и заставить доделовать то, что уже было доделано в рабочую неделю)))

Можно не пустить его в отпуск, пока он не доделает то, что начал, и не сдаст в отдел тестирования)))

Я надеюсь, вы понимаете что это шутка.

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

Подскажите, пожалуйста, что Вы думаете по этому поводу

А как бы Вы рассказали о результатах применения методики тестирования? Например, Вы разработали какую-то более-менее уникальную методику и Вас попросили рассказать о результатах применения этой методики в реальных условиях. Что и какие пункты Вы бы рассказали/описали?

Re: Подскажите, пожалуйста, что Вы думаете по этому пово

Для начала нужно понять, что является показателем результата качественного тестирования.
Это могут быть положительные отклики пользователей о ПО, или, к примеру, сокращение на столько-то процентов количества обращений пользователей в техподдержку и т.д.
Несколько субъективным показателем может также выступать количество дефектов, скажем, на 100 строк кода.
К примеру, раньше вы находили в среднем 3-4 дефекта на 100 строк кода, а после внедрения новой методики - 5-6. Конечно, теоретически причина может быть в другом (сменился программист, который пишет более "грязно" или пренебрегает юнит-тестами, а, может быть, программист тот же, но у него личные проблемы, которые отвлекают его и не дают сосредоточиться на работе).
Таким образом, "плясать" нужно от показателей результативности.
Хотя собственно о методике я бы тоже обязательно рассказала.
Можно выделить все нововведения в отдельные пункты и по каждому пункту описать в чем оно заключается и к чему приводит. Положительный эффект может заключаться не только в количестве найденных багов и конечном качестве продукта, но, к примеру, и в повышении результативности труда (на выполнение такой-то работы стало затрачиваться на столько-то меньше времени) или в качественном прогнозировании трудозатрат (что важно при планировании проекта) и т.д.
Угу, спасибо за пинок в нужном направлении.

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

З.Ы. Это я диплом пишу :(
Ну, определенная логика в этом, конечно, есть)
Однако стоит сделать пометку, что подобная практика может быть применима в условиях ограниченного количества времени, выделенного на тестирование. Если же тестировщики нормально укладываютсч в планы, то все-таки стоит уделить внимание всем основным функциям программы, даже если какие-то из них по статистике используются на порядок реже остальных. Лично я придерживаюсь такого мнения.
Если же существует проблема со сроками, то решаю ее не путем поверхностного тестирования некоторых функций, а путем проведения только позитивного тестирования (или в первую очередь позитивного тестирования), а уж потом, если будет время - уделяю внимание негативному.
Моя тестовая лаборатория

Сентябрь 2007

Вс Пн Вт Ср Чт Пт Сб
      1
2345678
9101112131415
16171819202122
23242526272829
30      
Разработано LiveJournal.com