Алексей, я не сомневаюсь, что вы найдете много полезных и важных багов. В этом смысле — все сработает, конечно.
Вот только, боюсь, обработать и починить эти баги будет некому — все заняты на фичах.
Или фичи делать будет некому — все заняты на багах.
Ну и всякие прочие возможные комбинации )
То есть не получится в тот же срок, с тем же набором фич, но еще плюс с улучшенным качеством.
От появления тестировщиков качество само по себе не улучшается, да.
чорт, случайно запостил много недописанных комментов )
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если есть доступ и знания, но непоянтна структура БД — тоже пользы мало
Если программисты умеют быстро локализовывать проблемы, а тестировщики нет — значит надо последних обучать методам и инструментам
Если быстро не умеют это делать ни программисты, ни тестировщики — похоже, проблема где-то в консерватории. Надо подумать, что поможет ускориться. Повышать тестируемость (testability) продукта в общем.
Хотя, может, в вашей ситуации 2 часа на сценарий и 2 дня на локализацию — это вполне нормально. Правда, от проекта к проекту все сильно по-разному )
Да и баги всякие бывают
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
простой ответ, как делаю я:
Я обычно стараюсь локализовать ошибку, насколько это возможно. И если для этого нужно просмотреть логи на двух-трех хостах, заглянуть в БД, что-то еще проверить — я это сделаю. С другой стороны — бывают проблемы, когда ну совсем ничего непонятно — тогда иду к программисту. А если он далеко и вообще недоступен — собираю максимум данных, относящихся (на мой взгляд) к проблеме и добавляю в багрепорт с соответствующими комментариями — дескать в логе ничего умного не увидел, но на всякий случай — вот кусок лога, может вы сами что-то в нем найдете.
Что придется проверить при исследовании — заранее неясно. Логи, настройки, БД, порой даже и сам код — все возможно, главное не увлекаться чересчур. Если потрачено уже 30-40 минут, а исследование ничего не дает — лучше остановиться и сообщить о том, что уже есть. Потом, если что, вместе с программистом сядете и проверите.
ответ посложнее. все зависит.
представьте: вы с утра отвели сына в школу и поехали на работу по пробкам своего города-миллионника. На работе в ленте новостей вы видите, что «в городе произошел взрыв вблизи школы, прямо во время уроков. Здание полностью разрушено. Мужчина из „тойоты“, проезжавшей рядом с нашим офисом, отметил, что весь город в светофорах, ездить невозможно.»
Что-что? В какой школе взрыв? Что взорвалось? Какое здание разрушено? Есть ли жертвы? Причем здесь этот мужик из «тойоты» и светофоры?
Нет ответа.
Вот примерно так и выглядит зачастую нелокализованная ошибка: какие-то данные предоставлены, но работать с ними невозможно, и пользы от них почти никакой.
А если заменить школу на закрытую военную часть и убрать мужика со светофорами? Ну, вроде уже и не так все плохо выглядит. То есть информации по-прежнему ноль, но оно как-то более понятно: кто ж пустить корреспондента на закрытую территорию.
В общем, в разных ситуациях работают разные подходы.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если для локализации ошибки нужно обойти десять серверов, чтоб понять где случилась беда, без каких-либо ориентиров, где смотреть — то это беда само по себе. Это значит, что эффективно тестировать продукт практически неозможно, и основная масса времени тратится не на работу с проблемой, а на тупой перебор серверов. Тут? Вроде нет. А может на этом? Ой, а на первом мы во все логи заглянули?
Добавьте возможность хотя бы сузить пул серверов для поиска проблемы, найдите способ быстро проверить все сервера — и уже станет проще.
Если сценарий занимает 2 часа, то это опять же ужас какой-то. То есть разработчик полтора часа что-то делал — и получил ошибку. Потом полтора часа воспроизводил. Потом еще 6 часов проверял на разных варинтах данных. И вот, не прошло и двух дней — ошибка локализована! Тут, мне кажется, проблема не в том, кто это делал — программист или тестировщик. Проблема в том, что сценарий занимает два часа человеческого времени.
Вот только, боюсь, обработать и починить эти баги будет некому — все заняты на фичах.
Или фичи делать будет некому — все заняты на багах.
Ну и всякие прочие возможные комбинации )
То есть не получится в тот же срок, с тем же набором фич, но еще плюс с улучшенным качеством.
От появления тестировщиков качество само по себе не улучшается, да.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если есть доступ и знания, но непоянтна структура БД — тоже пользы мало
Если программисты умеют быстро локализовывать проблемы, а тестировщики нет — значит надо последних обучать методам и инструментам
Если быстро не умеют это делать ни программисты, ни тестировщики — похоже, проблема где-то в консерватории. Надо подумать, что поможет ускориться. Повышать тестируемость (testability) продукта в общем.
Хотя, может, в вашей ситуации 2 часа на сценарий и 2 дня на локализацию — это вполне нормально. Правда, от проекта к проекту все сильно по-разному )
Да и баги всякие бывают
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Я обычно стараюсь локализовать ошибку, насколько это возможно. И если для этого нужно просмотреть логи на двух-трех хостах, заглянуть в БД, что-то еще проверить — я это сделаю. С другой стороны — бывают проблемы, когда ну совсем ничего непонятно — тогда иду к программисту. А если он далеко и вообще недоступен — собираю максимум данных, относящихся (на мой взгляд) к проблеме и добавляю в багрепорт с соответствующими комментариями — дескать в логе ничего умного не увидел, но на всякий случай — вот кусок лога, может вы сами что-то в нем найдете.
Что придется проверить при исследовании — заранее неясно. Логи, настройки, БД, порой даже и сам код — все возможно, главное не увлекаться чересчур. Если потрачено уже 30-40 минут, а исследование ничего не дает — лучше остановиться и сообщить о том, что уже есть. Потом, если что, вместе с программистом сядете и проверите.
ответ посложнее. все зависит.
представьте: вы с утра отвели сына в школу и поехали на работу по пробкам своего города-миллионника. На работе в ленте новостей вы видите, что «в городе произошел взрыв вблизи школы, прямо во время уроков. Здание полностью разрушено. Мужчина из „тойоты“, проезжавшей рядом с нашим офисом, отметил, что весь город в светофорах, ездить невозможно.»
Что-что? В какой школе взрыв? Что взорвалось? Какое здание разрушено? Есть ли жертвы? Причем здесь этот мужик из «тойоты» и светофоры?
Нет ответа.
Вот примерно так и выглядит зачастую нелокализованная ошибка: какие-то данные предоставлены, но работать с ними невозможно, и пользы от них почти никакой.
А если заменить школу на закрытую военную часть и убрать мужика со светофорами? Ну, вроде уже и не так все плохо выглядит. То есть информации по-прежнему ноль, но оно как-то более понятно: кто ж пустить корреспондента на закрытую территорию.
В общем, в разных ситуациях работают разные подходы.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если для локализации ошибки нужно обойти десять серверов, чтоб понять где случилась беда, без каких-либо ориентиров, где смотреть — то это беда само по себе. Это значит, что эффективно тестировать продукт практически неозможно, и основная масса времени тратится не на работу с проблемой, а на тупой перебор серверов. Тут? Вроде нет. А может на этом? Ой, а на первом мы во все логи заглянули?
Добавьте возможность хотя бы сузить пул серверов для поиска проблемы, найдите способ быстро проверить все сервера — и уже станет проще.
Если сценарий занимает 2 часа, то это опять же ужас какой-то. То есть разработчик полтора часа что-то делал — и получил ошибку. Потом полтора часа воспроизводил. Потом еще 6 часов проверял на разных варинтах данных. И вот, не прошло и двух дней — ошибка локализована! Тут, мне кажется, проблема не в том, кто это делал — программист или тестировщик. Проблема в том, что сценарий занимает два часа человеческого времени.