Хм, так же, как и руками оно измеряется. Запоминаете время до события, вычитаете его из времени после события. Из разницы, можно вычесть лаг тестирующей системы, но он, как правило, пренебрежимо мал.
Вы совершили простую ошибку в начале пути, когда отказались от load runner'a, признав его отклики недостоверными.
Нагрузочное тестирование подразумевает возможность разделения генерации нагрузки (jmeter или другой адекватный задаче инструмент) и измерения откликов (руками или селениумом).
Полгода назад мы проделали аналогичную работу, уперлись в ограниечение по ресурсам для браузеров.
Пришлось перерабатывать систему на совместную работу selenium и jmeter.
Младший: для работы требует внимания ведущего.
Мидл: работает сам
Ведущий: учит других
А уж обязанности автоматизаторов отличаться радикально могут от компании к компании. У нас ручные разбирают тесты, младшие ат пишут тесты, старшие ат — проектируют тесты.
Сомнительный критерий, который отличает Инженера по тестированию (автоматизированное) от Ведущего инженера по тестированию (автоматизированное).
Аналогично с ручным тестированием. Хотелось бы точнее определить компетенции для более точного попадания или не попадания в категорию.
Как тестировщику интересно, как системы будут отрабатывать кейсы «пользователь чихнул», «у пользователя чешется нос», есть ли калибровка под линзы, очки, косоглазие и пирата с повязкой на глазу.
Вообще это вопрос ответственности. Но у программиста больше возможностей понять причину возникновения ошибки.
Канер рассказывает, что их разработчики чинили четыре из пяти «у меня не воспроизводится».
А техническое решение проблемы — отдавать программистам снапшот системы(вместе с операционкой), на которой воспроизводится дефект. Жаль, не всегда возможно.
Сказанное верно для b2b — контрактной разработке. У нового продукта на массовом рынке спецификаций нет. По каким спекам писали твиттер? Есть реакция аудитории, попытки предсказать ее ожидания и жесткие сроки, которые и явились причиной появления процесса управления качеством, ведь это не только «у нас будет меньше багов», но и осознанное «релизим сейчас, поправим потом».
Ага, почти все это попадает под категорию, которую все любят писать в резюме — «ответственный».
По статистике врут. Ответственных в компании человека два-три. Они приближают ее существование к смыслу. Остальные — бабушка надвое сказала.
Хорошая история. А насчет того, что ждет дальше — задача моей группы на декабрь — «захватить мир». Вот только почему-то всегда находится что-то посрочнее, и приоритет уменьшают.
А на практике менеджеру не интересно, сколько некритичных для выпуска дефектов есть в продукте.
Решение по выпуску зависит от того, есть ли критичные для выпуска баги. На них и стоит тратить время.
Это да. Но qa звучит солидней и оплачивается выше, оттого самопровозглашают себя тестеры qa специалистами, забывая, что полномочия qa настоящего лежат недалеко от руководителя проекта.
Сейчас работаю над такой задачей: Завести как можно меньше багов, те есть находить дефекты, которые исправят сейчас. Желательно, без трекеров и прочей волокиты. На те, что не признают подлежащими фиксу времени не тратить.
Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.
Как-нибудь напишите об одном месяце и миллионе строк кода. Любопытно и полезно, я думаю.
Еще хотелось бы услышать ваше мнение о разнице в тестировании проектов и продуктов, b2b и b2c, чует мое сердце, разница есть и приличная, а на b2c поработать не довелось.
Да, для сложных задач.
Разработчик отдает задачу тестировщику, параллельно запускает полное автотестирование — занимает примерно столько же времени. Сам в это время занят другим.
Ну а мелкие задачи — тестируются вместе, в реалтайме, так сказать.
Пару лет используем решение из истории 3 — персональное тестирование «на лету», когда программист правит баги в режиме живого общения с тестировщиком.
Пока это один из самых эффективных способов тестирования.
Но есть проблемы, интересно, как их решили вы.
1. Необходимо соотношение тестировщиков\программистов один к одному. Дорого. Иначе — очереди и затея теряет смысл. И да, программисты имеют свойство доделывать задачи одновременно.
2. Сажать за один комп — работает на простенькой функциональности, неопытных программистах и очевидных багах. А если фича сложная, а программист опытный, то первые замечания появятся часа через три.
Нагрузочное тестирование подразумевает возможность разделения генерации нагрузки (jmeter или другой адекватный задаче инструмент) и измерения откликов (руками или селениумом).
Полгода назад мы проделали аналогичную работу, уперлись в ограниечение по ресурсам для браузеров.
Пришлось перерабатывать систему на совместную работу selenium и jmeter.
Мидл: работает сам
Ведущий: учит других
А уж обязанности автоматизаторов отличаться радикально могут от компании к компании. У нас ручные разбирают тесты, младшие ат пишут тесты, старшие ат — проектируют тесты.
Аналогично с ручным тестированием. Хотелось бы точнее определить компетенции для более точного попадания или не попадания в категорию.
Вы не в курсе, планируется ли драйвер для firefox сделать частью проекта firefox?
Были ли проблемы, связанные с тем, что драйвер для chrome реализует не команда Selenium? Или наоборот, это сплошные преимущества?
Хотя я, наверное, знаю ответ. Нет легкого способа протестировать. Есть необходимость думать и работать.
Канер рассказывает, что их разработчики чинили четыре из пяти «у меня не воспроизводится».
А техническое решение проблемы — отдавать программистам снапшот системы(вместе с операционкой), на которой воспроизводится дефект. Жаль, не всегда возможно.
По статистике врут. Ответственных в компании человека два-три. Они приближают ее существование к смыслу. Остальные — бабушка надвое сказала.
А на практике менеджеру не интересно, сколько некритичных для выпуска дефектов есть в продукте.
Решение по выпуску зависит от того, есть ли критичные для выпуска баги. На них и стоит тратить время.
Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.
Как-нибудь напишите об одном месяце и миллионе строк кода. Любопытно и полезно, я думаю.
Еще хотелось бы услышать ваше мнение о разнице в тестировании проектов и продуктов, b2b и b2c, чует мое сердце, разница есть и приличная, а на b2c поработать не довелось.
Разработчик отдает задачу тестировщику, параллельно запускает полное автотестирование — занимает примерно столько же времени. Сам в это время занят другим.
Ну а мелкие задачи — тестируются вместе, в реалтайме, так сказать.
Пока это один из самых эффективных способов тестирования.
Но есть проблемы, интересно, как их решили вы.
1. Необходимо соотношение тестировщиков\программистов один к одному. Дорого. Иначе — очереди и затея теряет смысл. И да, программисты имеют свойство доделывать задачи одновременно.
2. Сажать за один комп — работает на простенькой функциональности, неопытных программистах и очевидных багах. А если фича сложная, а программист опытный, то первые замечания появятся часа через три.