Заявлена проблема: сложно оценить сроки, неизвестное количество итераций тестирования задачи.
И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет.
Каким образом и менеджер узнает срок готовности фичи/релиза? У кого?
По поводу раннего информирования — вы не боитесь перейти на bug driven development, когда программист отдает тестировщику бажную сборку, чтоб тому было чем заняться на ранних этапах?
Пост огорчает тестировщиков. Я искренне надеюсь, что лейтмотив 25 уроков звучит как «это поможет найти работу, а потом придется уже всерьез учиться еще 5 лет»
Тема разницы между ad hoc хоть и раскрыта, но очень не полностью.
Многие тестировщики, с которыми знаком, гордо считают, что занимаются исследовательским тестированием, забывая, что в нем, в отличие от ad hoc, присутствует этап разработки тестов.
Вы требуете от кандидатов только список дефектов listboxer или еще, например, кейсы? Вам не кажется, что listboxer отсеивает еще и подходящих людей? По своему опыту скажу, что гораздо приятней выполнять тестовое задание на специальном приложении. Или даже на боевом.
Правильный, хороший, но сложно реализуемый подход.
При робких намках на что-то подобное сталкивался с:
1. «Эти Ваши тесты опять сломались»
2. Программистам нужно писать фичи, скоро релиз править баги, стоять на скрам митинге, тесты чинить некогда.
3. А вас зачем наняли?
Если изначально строить процесс разработки то получится, переучить людей много сложнее да и необходимо понимание проблемы руководителем проекта, а это, что характерно, не всегда бывщий разработчик или тестировщик.
В команду разработки интегрировано ручное тестирование, «персональный программист тестировщика» (или наоборот) с оговорками. Автоматизация тестирования — отдельно, на несколько проектов.
Внутренний регламент работы тестировщиков — авто и не авто — составляют они же.
Регламент, касающийся работы других участников — согласовываем с ПМом и разработчиками.
Требования нам сильно помог создать руководитель разработки, у него богатый опыт.
Ответственность за тесты несет тимлид автотестеров перед заказчиками — ПМами проектов.
В моих целях — создание микрокоманды аналитик+(авто)тестер+разработчик для каждой фичи. Это обеспечит скорость и глубину.
В противовес этой модели — отдельная группа автотестирования, хоть и немного оторвана от текущего контекста, но имеет большой плюс — отношения «заказчик-клиент». Это позволяет избежать написания тестов ради тестов, позволяет покрывать тестами актуальные фичи.
Работал на 3 проектах с похожими входными данными и наличием автоматизации гуй-тетирования.
На первых двух в той или иной степени проявились перечисленные выше ошибки.
Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
Вторая заключается в непонимании факта, что автоматизация является разработкой ПО, к ней нужно писать требования, ставить цели, считать рентабельность и прочее.
На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия. К тестирующей системе предъявлены требования по времени прохождения тестов, частоте ложных срабатываний, возможностям адаптации к изменениям GUI, типу ошибок, которые могут обнаружить тесты.
И сейчас есть масса проблем, по большей части в функциональности, связанной со временем: фичи работающие асинхронно, срабатывающие по событиям, обрабатываемые в очереди с недетерминированным временем прохождения.
Есть цепочка операций, которую необходимо протестировать:
A --> B --> C
Длительность выполнения операции через GUI — 30 секунд.
Я хочу написать 3 теста — на каждую операцию.
У меня есть доступ к внутреннему API системы, позволяющий выполнить операцию за 3 секунды.
Очевидно, что при тестировании операции С мне выгодней сделать не так:
Операция А --> Операция B --> Операция C: проверка
а так:
API А --> API B --> Операция C: проверка
Каким образом и менеджер узнает срок готовности фичи/релиза? У кого?
По поводу раннего информирования — вы не боитесь перейти на bug driven development, когда программист отдает тестировщику бажную сборку, чтоб тому было чем заняться на ранних этапах?
Я буду проверять не только орфографию перед отправкой комментария.
Многие тестировщики, с которыми знаком, гордо считают, что занимаются исследовательским тестированием, забывая, что в нем, в отличие от ad hoc, присутствует этап разработки тестов.
При робких намках на что-то подобное сталкивался с:
1. «Эти Ваши тесты опять сломались»
2. Программистам нужно писать фичи, скоро релиз править баги, стоять на скрам митинге, тесты чинить некогда.
3. А вас зачем наняли?
Если изначально строить процесс разработки то получится, переучить людей много сложнее да и необходимо понимание проблемы руководителем проекта, а это, что характерно, не всегда бывщий разработчик или тестировщик.
Внутренний регламент работы тестировщиков — авто и не авто — составляют они же.
Регламент, касающийся работы других участников — согласовываем с ПМом и разработчиками.
Требования нам сильно помог создать руководитель разработки, у него богатый опыт.
Ответственность за тесты несет тимлид автотестеров перед заказчиками — ПМами проектов.
В моих целях — создание микрокоманды аналитик+(авто)тестер+разработчик для каждой фичи. Это обеспечит скорость и глубину.
В противовес этой модели — отдельная группа автотестирования, хоть и немного оторвана от текущего контекста, но имеет большой плюс — отношения «заказчик-клиент». Это позволяет избежать написания тестов ради тестов, позволяет покрывать тестами актуальные фичи.
На первых двух в той или иной степени проявились перечисленные выше ошибки.
Основная ошибка — нужно сперва научиться тестировать, а затем заниматься автоматизацией.
Вторая заключается в непонимании факта, что автоматизация является разработкой ПО, к ней нужно писать требования, ставить цели, считать рентабельность и прочее.
На последнем проекте автоматизация работает параллельно с ручной проверкой, прописаны регламенты взаимодействия. К тестирующей системе предъявлены требования по времени прохождения тестов, частоте ложных срабатываний, возможностям адаптации к изменениям GUI, типу ошибок, которые могут обнаружить тесты.
И сейчас есть масса проблем, по большей части в функциональности, связанной со временем: фичи работающие асинхронно, срабатывающие по событиям, обрабатываемые в очереди с недетерминированным временем прохождения.
A --> B --> C
Длительность выполнения операции через GUI — 30 секунд.
Я хочу написать 3 теста — на каждую операцию.
У меня есть доступ к внутреннему API системы, позволяющий выполнить операцию за 3 секунды.
Очевидно, что при тестировании операции С мне выгодней сделать не так:
Операция А --> Операция B --> Операция C: проверка
а так:
API А --> API B --> Операция C: проверка
Как работает PageObjectPattern в таком случае?