Комментарии 18
Знакомые ситуации, особенно в некоторых отечественных стартапах. Но еще хуже, когда руководство считает, что им самим чисто проверить что сделали программисты будет достаточным, что бы убедиться в работоспособности продукта, и следовательно отказываются от услуг тестировщика…
А некоторые считают что программисты должны пушить только хорошо проверенные ими изменения, без каких-либо серьезных багов. Поэтому как-бы и тестеры не нужны.
То что выгоднее нанять тестеров с более низкими зарплатами чем у программистов и тем самым разгрузить программистов на отладку уже найденных багов или написание новых фич почему-то в расчет не берется.
То что выгоднее нанять тестеров с более низкими зарплатами чем у программистов и тем самым разгрузить программистов на отладку уже найденных багов или написание новых фич почему-то в расчет не берется.
Да прям.
Приду и протестирую по-быстрому так, что это сработает.
Приду и протестирую по-быстрому так, что это сработает.
Алексей, я не сомневаюсь, что вы найдете много полезных и важных багов. В этом смысле — все сработает, конечно.
Вот только, боюсь, обработать и починить эти баги будет некому — все заняты на фичах.
Или фичи делать будет некому — все заняты на багах.
Ну и всякие прочие возможные комбинации )
То есть не получится в тот же срок, с тем же набором фич, но еще плюс с улучшенным качеством.
От появления тестировщиков качество само по себе не улучшается, да.
Вот только, боюсь, обработать и починить эти баги будет некому — все заняты на фичах.
Или фичи делать будет некому — все заняты на багах.
Ну и всякие прочие возможные комбинации )
То есть не получится в тот же срок, с тем же набором фич, но еще плюс с улучшенным качеством.
От появления тестировщиков качество само по себе не улучшается, да.
вот скажите, что может быть не так в ситуации:
тестировщики проходят шаги и записывают их: открыл форму, получил платежи, обработал… и ещё 20 действий.
И подобные результаты дают разработчикам — описание 20 шагов и название среды. Причем, чтобы воспроизвести все те шаги (а их там много) надо от 20 минут до 2 часов.
Вопрос: должны ли тестировщики предоставлять не только общие шаги по системе в рамках сценария, а конкретные условия появления бага/ошибки? Изолировать ошибку.
Т.е. если есть ещё, например, шина и десяток сервисов. Они запускаются по очереди и в них причина ошибки. Тестировщик, проходя сценарий, должен найти конкретное место появления ошибки и конкретные условия и предоставить их разработчику (он должен уметь пользоваться SQL искать сущности, пользоваться шиной, сервисами — изолировать проблему)?
Или же тестировщик, как обезьянка должен потыкать формочки по сложному комплексному сценарию и не получив нужный результат завести баг, а разработчик пусть сам повторяет эти 20 минут подготовки комплекса и выясняет дебагером, какой из 10 сервисов на шине отработал с ошибкой… причем, как правило, чужой сервис?
По возможности можете дать ссылку или цитату того, чем подкреплено мнение…
тестировщики проходят шаги и записывают их: открыл форму, получил платежи, обработал… и ещё 20 действий.
И подобные результаты дают разработчикам — описание 20 шагов и название среды. Причем, чтобы воспроизвести все те шаги (а их там много) надо от 20 минут до 2 часов.
Вопрос: должны ли тестировщики предоставлять не только общие шаги по системе в рамках сценария, а конкретные условия появления бага/ошибки? Изолировать ошибку.
Т.е. если есть ещё, например, шина и десяток сервисов. Они запускаются по очереди и в них причина ошибки. Тестировщик, проходя сценарий, должен найти конкретное место появления ошибки и конкретные условия и предоставить их разработчику (он должен уметь пользоваться SQL искать сущности, пользоваться шиной, сервисами — изолировать проблему)?
Или же тестировщик, как обезьянка должен потыкать формочки по сложному комплексному сценарию и не получив нужный результат завести баг, а разработчик пусть сам повторяет эти 20 минут подготовки комплекса и выясняет дебагером, какой из 10 сервисов на шине отработал с ошибкой… причем, как правило, чужой сервис?
По возможности можете дать ссылку или цитату того, чем подкреплено мнение…
простой ответ, как делаю я:
Я обычно стараюсь локализовать ошибку, насколько это возможно. И если для этого нужно просмотреть логи на двух-трех хостах, заглянуть в БД, что-то еще проверить — я это сделаю. С другой стороны — бывают проблемы, когда ну совсем ничего непонятно — тогда иду к программисту. А если он далеко и вообще недоступен — собираю максимум данных, относящихся (на мой взгляд) к проблеме и добавляю в багрепорт с соответствующими комментариями — дескать в логе ничего умного не увидел, но на всякий случай — вот кусок лога, может вы сами что-то в нем найдете.
Что придется проверить при исследовании — заранее неясно. Логи, настройки, БД, порой даже и сам код — все возможно, главное не увлекаться чересчур. Если потрачено уже 30-40 минут, а исследование ничего не дает — лучше остановиться и сообщить о том, что уже есть. Потом, если что, вместе с программистом сядете и проверите.
ответ посложнее. все зависит.
представьте: вы с утра отвели сына в школу и поехали на работу по пробкам своего города-миллионника. На работе в ленте новостей вы видите, что «в городе произошел взрыв вблизи школы, прямо во время уроков. Здание полностью разрушено. Мужчина из „тойоты“, проезжавшей рядом с нашим офисом, отметил, что весь город в светофорах, ездить невозможно.»
Что-что? В какой школе взрыв? Что взорвалось? Какое здание разрушено? Есть ли жертвы? Причем здесь этот мужик из «тойоты» и светофоры?
Нет ответа.
Вот примерно так и выглядит зачастую нелокализованная ошибка: какие-то данные предоставлены, но работать с ними невозможно, и пользы от них почти никакой.
А если заменить школу на закрытую военную часть и убрать мужика со светофорами? Ну, вроде уже и не так все плохо выглядит. То есть информации по-прежнему ноль, но оно как-то более понятно: кто ж пустить корреспондента на закрытую территорию.
В общем, в разных ситуациях работают разные подходы.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если для локализации ошибки нужно обойти десять серверов, чтоб понять где случилась беда, без каких-либо ориентиров, где смотреть — то это беда само по себе. Это значит, что эффективно тестировать продукт практически неозможно, и основная масса времени тратится не на работу с проблемой, а на тупой перебор серверов. Тут? Вроде нет. А может на этом? Ой, а на первом мы во все логи заглянули?
Добавьте возможность хотя бы сузить пул серверов для поиска проблемы, найдите способ быстро проверить все сервера — и уже станет проще.
Если сценарий занимает 2 часа, то это опять же ужас какой-то. То есть разработчик полтора часа что-то делал — и получил ошибку. Потом полтора часа воспроизводил. Потом еще 6 часов проверял на разных варинтах данных. И вот, не прошло и двух дней — ошибка локализована! Тут, мне кажется, проблема не в том, кто это делал — программист или тестировщик. Проблема в том, что сценарий занимает два часа человеческого времени.
Я обычно стараюсь локализовать ошибку, насколько это возможно. И если для этого нужно просмотреть логи на двух-трех хостах, заглянуть в БД, что-то еще проверить — я это сделаю. С другой стороны — бывают проблемы, когда ну совсем ничего непонятно — тогда иду к программисту. А если он далеко и вообще недоступен — собираю максимум данных, относящихся (на мой взгляд) к проблеме и добавляю в багрепорт с соответствующими комментариями — дескать в логе ничего умного не увидел, но на всякий случай — вот кусок лога, может вы сами что-то в нем найдете.
Что придется проверить при исследовании — заранее неясно. Логи, настройки, БД, порой даже и сам код — все возможно, главное не увлекаться чересчур. Если потрачено уже 30-40 минут, а исследование ничего не дает — лучше остановиться и сообщить о том, что уже есть. Потом, если что, вместе с программистом сядете и проверите.
ответ посложнее. все зависит.
представьте: вы с утра отвели сына в школу и поехали на работу по пробкам своего города-миллионника. На работе в ленте новостей вы видите, что «в городе произошел взрыв вблизи школы, прямо во время уроков. Здание полностью разрушено. Мужчина из „тойоты“, проезжавшей рядом с нашим офисом, отметил, что весь город в светофорах, ездить невозможно.»
Что-что? В какой школе взрыв? Что взорвалось? Какое здание разрушено? Есть ли жертвы? Причем здесь этот мужик из «тойоты» и светофоры?
Нет ответа.
Вот примерно так и выглядит зачастую нелокализованная ошибка: какие-то данные предоставлены, но работать с ними невозможно, и пользы от них почти никакой.
А если заменить школу на закрытую военную часть и убрать мужика со светофорами? Ну, вроде уже и не так все плохо выглядит. То есть информации по-прежнему ноль, но оно как-то более понятно: кто ж пустить корреспондента на закрытую территорию.
В общем, в разных ситуациях работают разные подходы.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если для локализации ошибки нужно обойти десять серверов, чтоб понять где случилась беда, без каких-либо ориентиров, где смотреть — то это беда само по себе. Это значит, что эффективно тестировать продукт практически неозможно, и основная масса времени тратится не на работу с проблемой, а на тупой перебор серверов. Тут? Вроде нет. А может на этом? Ой, а на первом мы во все логи заглянули?
Добавьте возможность хотя бы сузить пул серверов для поиска проблемы, найдите способ быстро проверить все сервера — и уже станет проще.
Если сценарий занимает 2 часа, то это опять же ужас какой-то. То есть разработчик полтора часа что-то делал — и получил ошибку. Потом полтора часа воспроизводил. Потом еще 6 часов проверял на разных варинтах данных. И вот, не прошло и двух дней — ошибка локализована! Тут, мне кажется, проблема не в том, кто это делал — программист или тестировщик. Проблема в том, что сценарий занимает два часа человеческого времени.
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
чорт, случайно запостил много недописанных комментов )
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если есть доступ и знания, но непоянтна структура БД — тоже пользы мало
Если программисты умеют быстро локализовывать проблемы, а тестировщики нет — значит надо последних обучать методам и инструментам
Если быстро не умеют это делать ни программисты, ни тестировщики — похоже, проблема где-то в консерватории. Надо подумать, что поможет ускориться. Повышать тестируемость (testability) продукта в общем.
Хотя, может, в вашей ситуации 2 часа на сценарий и 2 дня на локализацию — это вполне нормально. Правда, от проекта к проекту все сильно по-разному )
Да и баги всякие бывают
Если на проекте тестировщики не имеют доступа к БД, то и возможностей исследовать у них намного меньше.
Если есть доступ к БД, но нет знания SQL, то толку от того доступа.
Если есть доступ и знания, но непоянтна структура БД — тоже пользы мало
Если программисты умеют быстро локализовывать проблемы, а тестировщики нет — значит надо последних обучать методам и инструментам
Если быстро не умеют это делать ни программисты, ни тестировщики — похоже, проблема где-то в консерватории. Надо подумать, что поможет ускориться. Повышать тестируемость (testability) продукта в общем.
Хотя, может, в вашей ситуации 2 часа на сценарий и 2 дня на локализацию — это вполне нормально. Правда, от проекта к проекту все сильно по-разному )
Да и баги всякие бывают
среда 1-2. Правда разная с разработчиками. Доступ к базе есть. Смотреть могут все то же, что и разработчики, кроме кода. Проблема в том, что разработчикам нужно искать сервис который падает проходя сценарий и разрабатывать новый функционал, а тестировщики просто клацанием занимаются и показывают не стектрейс из лога, а сообщения об ошибках с UI. Лог они смотреть не умеют, только тот, что система сама показывает через UI
на самом деле просто убивает то, что тестировщик отгораживаются и отмахиваются:
Мы сценарий натыкали? натыкали. Баг получили? вот он. Приходи, посмотри. У вас не воспроизводится? ни чего не знаем. Id сущности? От куда я знаю. Вот её имя и номер с UI (подтянутые из другой сущности через join ).
Инфы от них по-сути ни какой. Примерно так, как в рассказе про взрыв.«Алло, МЧС? тут передали, что какая-то из военных частей взорвалась. Да, да… не знаю. Нет. Не знаю… Услышал» И все тестировщики включая тестлида считают это правильным.
на самом деле просто убивает то, что тестировщик отгораживаются и отмахиваются:
Мы сценарий натыкали? натыкали. Баг получили? вот он. Приходи, посмотри. У вас не воспроизводится? ни чего не знаем. Id сущности? От куда я знаю. Вот её имя и номер с UI (подтянутые из другой сущности через join ).
Инфы от них по-сути ни какой. Примерно так, как в рассказе про взрыв.«Алло, МЧС? тут передали, что какая-то из военных частей взорвалась. Да, да… не знаю. Нет. Не знаю… Услышал» И все тестировщики включая тестлида считают это правильным.
Ну едва ли они отмахиваются просто потому, что плохо воспитаны.
Для вас они «не умеют читать логи», а для них лог — мешанина малопонятных строк. И не исключено, что они правы, и логи действительно мало говорят непосвященным. Покажите, как определить и отфильтровать нужную транзакцию в логе. Расскажите общую логику построения логов.
А с архитектурой они знакомы? Если нет, то и разумные предположения, куда смотреть в случае проблем, им сделать трудно.
ID сущности сложно определить? Упростите ее получение.
Покажите уровень дубликатов и инвалидов; если он аномально высок — договоритесь с тестлидом, как будете решать проблему. Только не указывайте, пусть он сам что-нибудь придумает. И объясните, почему это — проблема.
Дайте пошаговую инструкцию исследования типичных проблем, простую — шагов на пять-семь.
Расскажите про черный и белый ящик наконец, что ли )
В общем, если коротко, то — учите и объясняйте. Ругаться смысла нет.
Если не хочется учить всех — учите тестлида или просто самого толкового из тестировщиков втихушку ). Он потом научит остальных.
Вы кстати знаете, кто из ваших тестировщиков — самый толковый? )
Для вас они «не умеют читать логи», а для них лог — мешанина малопонятных строк. И не исключено, что они правы, и логи действительно мало говорят непосвященным. Покажите, как определить и отфильтровать нужную транзакцию в логе. Расскажите общую логику построения логов.
А с архитектурой они знакомы? Если нет, то и разумные предположения, куда смотреть в случае проблем, им сделать трудно.
ID сущности сложно определить? Упростите ее получение.
Покажите уровень дубликатов и инвалидов; если он аномально высок — договоритесь с тестлидом, как будете решать проблему. Только не указывайте, пусть он сам что-нибудь придумает. И объясните, почему это — проблема.
Дайте пошаговую инструкцию исследования типичных проблем, простую — шагов на пять-семь.
Расскажите про черный и белый ящик наконец, что ли )
В общем, если коротко, то — учите и объясняйте. Ругаться смысла нет.
Если не хочется учить всех — учите тестлида или просто самого толкового из тестировщиков втихушку ). Он потом научит остальных.
Вы кстати знаете, кто из ваших тестировщиков — самый толковый? )
НЛО прилетело и опубликовало эту надпись здесь
Кто-то нашёл баги (неважно кто — штатные тестировщики/бета-тестеры/рядовые пользователи/коллеги-разработчики/НачПроекта), но разработчики не могут/не хотят/не имеют времени их исправлять, поэтому качество не улучшается.
Интересно, причём тут тестирование вообще? :)
Интересно, причём тут тестирование вообще? :)
Тестирование при том всего лишь, что оно — часть процесса разработки, и не стоит его искусственно отделять в специальную песочницу ).
Согласен, проблема не относится исключительно к тестированию — так же, как она не относится исключительно к разработке продукта или к планирование проекта. Планирование тестирования в контексте разработки конкретного продукта, как-то так.
Типичная проблема границ и взаимодействия компонент. )
Согласен, проблема не относится исключительно к тестированию — так же, как она не относится исключительно к разработке продукта или к планирование проекта. Планирование тестирования в контексте разработки конкретного продукта, как-то так.
Типичная проблема границ и взаимодействия компонент. )
Тестирования много не бывает…
Найти критические баги, выловить падения и прочее за пару итераций можно… вопрос: успеют ли их поправить?
ИМХО, тестеры должны вступать в процесс разработки тогда же, когда и сами разработчик… продумывать план, поднимать соответствующее окружение, думать над автоматизацией (если это возможно/нужно), и все будет хорошо.
Найти критические баги, выловить падения и прочее за пару итераций можно… вопрос: успеют ли их поправить?
ИМХО, тестеры должны вступать в процесс разработки тогда же, когда и сами разработчик… продумывать план, поднимать соответствующее окружение, думать над автоматизацией (если это возможно/нужно), и все будет хорошо.
по-хорошему, чем раньше qa вступает в бой — тем лучше, а бой начинается еще до того как девелоперы начинают думать о том что они будут девелопить.
тестирования БЫВАЕТ много. все баги не выловить — поэтому когда достигнуто некое количество выловленных багов — тестирование может останавливаться, так как резко падает эффективности этого тестиорвания. если в начале разработки можно тестировать 1 час и найти 20 багов, то под конец можно тестировать 20 часов и найти 1 баг. эффективность, при этом, на лицо.
все проблемы от безалаберности (неграмотности) тех людей, которые отвечают за процесс построения продукта «а мы и так сами всё смогём» — не канает.
тестирования БЫВАЕТ много. все баги не выловить — поэтому когда достигнуто некое количество выловленных багов — тестирование может останавливаться, так как резко падает эффективности этого тестиорвания. если в начале разработки можно тестировать 1 час и найти 20 багов, то под конец можно тестировать 20 часов и найти 1 баг. эффективность, при этом, на лицо.
все проблемы от безалаберности (неграмотности) тех людей, которые отвечают за процесс построения продукта «а мы и так сами всё смогём» — не канает.
«Кстати, а вам самим-то нужен неопытный руководитель...?»
Судя по кейсам — там как раз уже и есть один такой «эффективный менеджер». И «Боливар не вынесет двоих»
Судя по кейсам — там как раз уже и есть один такой «эффективный менеджер». И «Боливар не вынесет двоих»
Поменять местами первый и последний логотипы, я бы даже не заметил подвоха :)
>> То есть в отведенные сроки хоть какую-то пользу тестировщики
>> смогут приносить только в последние три недели
Это если помимо домового со списком, ещё и фея прилетит, которая составит тестплан, напишет кейсы и кроме того регулярно будет выполнять регрессию (автотестов то ещё нет))
Вообще в проектах больше чем разовая мелочь (ну скажем от 1-5 человеко-лет) новый сотрудник (неважно кто он по рангу) начинает действовать самостоятельно в среднем через три месяца, приносить реальную (!) пользу начинает примерно через пол года. Это мои личные наблюдения. Я и многие мои коллеги и знакомые через похожую схему прошли. Единицы начинают быть реально полезными через 1-3 месяца и как правило это редкие и дорогие специалисты в узких областях (например DBA-золотые руки).
>> смогут приносить только в последние три недели
Это если помимо домового со списком, ещё и фея прилетит, которая составит тестплан, напишет кейсы и кроме того регулярно будет выполнять регрессию (автотестов то ещё нет))
Вообще в проектах больше чем разовая мелочь (ну скажем от 1-5 человеко-лет) новый сотрудник (неважно кто он по рангу) начинает действовать самостоятельно в среднем через три месяца, приносить реальную (!) пользу начинает примерно через пол года. Это мои личные наблюдения. Я и многие мои коллеги и знакомые через похожую схему прошли. Единицы начинают быть реально полезными через 1-3 месяца и как правило это редкие и дорогие специалисты в узких областях (например DBA-золотые руки).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Протестируем по-быстрому? Это не сработает