Хочется вопрос по-другому поставить))
А не хотят ли SQA-Days когда-нибудь приехать в Омск или Новосибирск? )
У нас очень много специалистов, которым тоже интересно тестирование как слушателям, но улететь в Столицы, в Белоруcию или на Украину массово для них сложно…
и по времени работы кажется тоже неэффективен.
100% рабочая сферическая версия в вакууме единожды приемочно оттестированная пусть будет эталоном…
Тогда «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров» — где куча потерянных нрвных клеток -хотя бы однократное повторение сферического в вакууме тестирования (* на число задач) плюс время на локализацию/фиксирование/перепроверку касяков, коими кишат задачи и непонятно до каких пор кишить будут.
Управиться в срок с задачей возможно, если только «отдраивать» ее будет вся королевская более дешевая рать…
Остальные задачи на тестирование получается нервно курят в уголках…
Это все в защиту тестеров от monkey testing))Обязательно поправьте, если не права.
И еще, меньшее количество очевидных ошибок у хорошего тестера порождает желание изобретать более хитрые способы их искать, а у разработчиков какое-то чувство ответственности…
То, что все это должно быть без фанатизма (как нечистоплотность кода так и его вылизанность)-тут с автором сложно поспорить.
Абсолютно согласна с 1 вариантом развития событий. А вот 3 наверное случится через стоицот лет — в топах браузеров ие6 зачастую в первой пятерке…
2 варианта есть шанс избежать, проработав наполнение главной страницы(напичкав самой важной инфой и контактами для связи с фирмой-заказчиком). У нее в каком-то виде прогрузиться шансов больше, чем быть работающим всему сайту.
Я бы указанную причину разнонаправленности целей дополнила — либо команде не интересно ничего кроме взаимного гнобления, либо низкий уровень ответственности, либо у членов команды слишком много свободного времени, которое они позволяют себе тратить на поиски виноватых.
В любом случае исправить или привентировать ситуацию в силах только менеджер/тимлидер/нанимающий на работу.
Если в компании не принято подпитывать интерес сотрудников — поощрять их стремление развиваться, исследовать, искать оптимальные решения, никакая локальная инициатива дело не спасет. А интерес сотрудников будет подпитываться доступным способом — мереньем багами и поисками главного вредителя.
Так же и с ответственностью. Если один сотрудник, более менее осознающий ответственность за свою работу, понимает, что на качество его работы влияет и чужая работа. И попытается посодействовать коллегам в улучшении качества ИХ деятельности, тем самым улучшая своё, а коллегам это, мягко скажем, не нужно и иногда болезненно, локальная инициатива так же завянет.
Ну и терки на тему «я нафигачил тыщу багов за день в коде который вы месяц рожали» всегда отжирают кучу времени. Если менеджер не в состоянии эти «утечки» обнаруживать и грамотно локализовывать, то команде это и подавно не нужно.
codefest.ru/program/2010-09/
Но если ее хорошенько подготовить, как и компании, все же реально?)
А не хотят ли SQA-Days когда-нибудь приехать в Омск или Новосибирск? )
У нас очень много специалистов, которым тоже интересно тестирование как слушателям, но улететь в Столицы, в Белоруcию или на Украину массово для них сложно…
100% рабочая сферическая версия в вакууме единожды приемочно оттестированная пусть будет эталоном…
Тогда «я — 2-3 задачи за интервал + куча потереных нервных клеток у тестеров» — где куча потерянных нрвных клеток -хотя бы однократное повторение сферического в вакууме тестирования (* на число задач) плюс время на локализацию/фиксирование/перепроверку касяков, коими кишат задачи и непонятно до каких пор кишить будут.
Управиться в срок с задачей возможно, если только «отдраивать» ее будет вся королевская более дешевая рать…
Остальные задачи на тестирование получается нервно курят в уголках…
Это все в защиту тестеров от monkey testing))Обязательно поправьте, если не права.
И еще, меньшее количество очевидных ошибок у хорошего тестера порождает желание изобретать более хитрые способы их искать, а у разработчиков какое-то чувство ответственности…
То, что все это должно быть без фанатизма (как нечистоплотность кода так и его вылизанность)-тут с автором сложно поспорить.
2 варианта есть шанс избежать, проработав наполнение главной страницы(напичкав самой важной инфой и контактами для связи с фирмой-заказчиком). У нее в каком-то виде прогрузиться шансов больше, чем быть работающим всему сайту.
Мое дилетантское мнение =)
«костыль»
Рыба с головы подгнивать начинает.
Я бы указанную причину разнонаправленности целей дополнила — либо команде не интересно ничего кроме взаимного гнобления, либо низкий уровень ответственности, либо у членов команды слишком много свободного времени, которое они позволяют себе тратить на поиски виноватых.
В любом случае исправить или привентировать ситуацию в силах только менеджер/тимлидер/нанимающий на работу.
Если в компании не принято подпитывать интерес сотрудников — поощрять их стремление развиваться, исследовать, искать оптимальные решения, никакая локальная инициатива дело не спасет. А интерес сотрудников будет подпитываться доступным способом — мереньем багами и поисками главного вредителя.
Так же и с ответственностью. Если один сотрудник, более менее осознающий ответственность за свою работу, понимает, что на качество его работы влияет и чужая работа. И попытается посодействовать коллегам в улучшении качества ИХ деятельности, тем самым улучшая своё, а коллегам это, мягко скажем, не нужно и иногда болезненно, локальная инициатива так же завянет.
Ну и терки на тему «я нафигачил тыщу багов за день в коде который вы месяц рожали» всегда отжирают кучу времени. Если менеджер не в состоянии эти «утечки» обнаруживать и грамотно локализовывать, то команде это и подавно не нужно.