забавно, что когда начинаешь структурировать и записывать свои действия и изыскания, то автоматически получается лучше концентрироваться и вникать
Абсолютно верно. Психологический аспект :) К тому же статья изложена простым и доступным языком. Такое изложение не только приятно для чтения, но и легко для усвоения.
У меня на текущий момент 7 внешних жестких дисков по 5 ТБ каждый с мультимедиа, играми, софтом и пр. хламом. Уже под завязку. Нужно расширяться. Давно озадачилась покупкой единого хранилища. Что посоветуете?
Занимательная статья. До сего момента считала, что автоматоны были просто интересными игрушками, а посему все же имели пользу для конечного потребителя, т.е. "не рекламы ради, а пользы для". А оно вон как, все-таки реклама. Эх...
Использование id вместо XPath и CSS очень правильный подход. К сожалению, на практике таких атрибутов у продукта зачастую не имеется вовсе, и крайне сложно добиться от разработчиков их внедрения, особенно, если разработка внешняя.
Статья "согрела душу"! :) Я вспомнила, как сама в свое время озадачилась входом с сферу IT (правда мне было тогда 39) и тоже выбрала "тестирование ПО" (в моем случае автоматизацию тестирования на Java), имея основное образование тоже педагогическое. Правда причиной стала насущная необходимость удаленки.
Хорошие примеры метрик из практики. Метрика по выполнению тест-плана для демонстрации прогресса тестов вышестоящему руководству прям в точку. Руководство очень любит наглядные (лучше с картинками и графиками) отчеты :).
Вот еще несколько метрик из моей практики:
метрики, показывающие эффективность процесса разработки: ----------------------------------------------------------------------------------------- 1) частота повторно обнаруженных дефектов = (количество повторно обнаруженных дефектов / количество устраненных дефектов) х 100. 2) скорость введения дефекта = количество найденных дефектов / количество изменений. Т.е. среднее количество найденных дефектов на одно изменение (новый функционал, багфикс).
метрики для автоматизации тестирования: --------------------------------------------------------------- 1) процент тестов, упавших НЕ по вине продукта = количество упавших тестов не по вине продукта / общее количество упавших тестов х 100. Показывает качество кода в автотестах. 2) процент дефектов, найденных автотестами = количество дефектов, найденных автотестами / количество всех найденных дефектов х 100.
В статье четко написано, что разработчики продукта тесты (автотесты) не должны писать в силу своего мышления. Тесты (автотесты) пишут тестировщики (автотестировщики, т.е. разработчики автоматизированных тестовых сценариев).
Спасибо )
Абсолютно верно. Психологический аспект :)
К тому же статья изложена простым и доступным языком. Такое изложение не только приятно для чтения, но и легко для усвоения.
Спасибо )
Спасибо )
У меня на текущий момент 7 внешних жестких дисков по 5 ТБ каждый с мультимедиа, играми, софтом и пр. хламом. Уже под завязку. Нужно расширяться.
Давно озадачилась покупкой единого хранилища.
Что посоветуете?
А я и не утверждала, что реклама - это плохо :).
Просто как-то грустно - такой шедевр и, вдруг, просто реклама.
Занимательная статья.
До сего момента считала, что автоматоны были просто интересными игрушками, а посему все же имели пользу для конечного потребителя, т.е. "не рекламы ради, а пользы для". А оно вон как, все-таки реклама. Эх...
Использование id вместо XPath и CSS очень правильный подход. К сожалению, на практике таких атрибутов у продукта зачастую не имеется вовсе, и крайне сложно добиться от разработчиков их внедрения, особенно, если разработка внешняя.
Статья "согрела душу"! :)
Я вспомнила, как сама в свое время озадачилась входом с сферу IT (правда мне было тогда 39) и тоже выбрала "тестирование ПО" (в моем случае автоматизацию тестирования на Java), имея основное образование тоже педагогическое. Правда причиной стала насущная необходимость удаленки.
Спасибо за статью и успехов на выбранном поприще!
Хорошие примеры метрик из практики. Метрика по выполнению тест-плана для демонстрации прогресса тестов вышестоящему руководству прям в точку. Руководство очень любит наглядные (лучше с картинками и графиками) отчеты :).
Вот еще несколько метрик из моей практики:
метрики, показывающие эффективность процесса разработки:
-----------------------------------------------------------------------------------------
1) частота повторно обнаруженных дефектов = (количество повторно обнаруженных дефектов / количество устраненных дефектов) х 100.
2) скорость введения дефекта = количество найденных дефектов / количество изменений.
Т.е. среднее количество найденных дефектов на одно изменение (новый функционал, багфикс).
метрики для автоматизации тестирования:
---------------------------------------------------------------
1) процент тестов, упавших НЕ по вине продукта = количество упавших тестов не по вине продукта / общее количество упавших тестов х 100.
Показывает качество кода в автотестах.
2) процент дефектов, найденных автотестами = количество дефектов, найденных автотестами / количество всех найденных дефектов х 100.
В статье четко написано, что разработчики продукта тесты (автотесты) не должны писать в силу своего мышления. Тесты (автотесты) пишут тестировщики (автотестировщики, т.е. разработчики автоматизированных тестовых сценариев).