Сообщений в теме: 8

[IlyaPopovich]

Всем доброго здравия, 

К примеру, есть некий отдел из 20 тестировщиков. 

Каждому выдаётся задание и кредит доверия. 

Требуется контролировать выполнение задач.

В области тестирования - это немного сложновато, в отчётах можно написать что угодно. 

 

 

Перепроверять при большом количестве человек самому - все время будет занято такими проверками

Делигировать проверку ведущим тестировщикам - опять же вместо проведения сложных кейс, локомотивы тестирования будут заниматься задачами не по уровню

Постоянный контроль приводит к тому, что люди демотивированы (им недоверяют). 

Проводедение кросс-тестирование - увеличение времени тестирования. При планировании, мало кто хочет выделять дополнительное время для такого контроля. 

 

Обобщая всю эту несуразицу:

Какие оптимальные методы проверки выполнения задач существуют?

[Tishka]

Ну к примеру, Вы бы могли разделить между тестировщиками некоторые "области ответственности" - каждый тестирует свою часть.

И по факту на продакшене узнаете, кто хорошо тестировал, а кто не очень.

 

P.S. Это сугубо личное мнение.

[lurk]

Оптимальный метод проверки исключение проверки из процесса работы.

PS:

По факту Мне не хватает условий кейса. Вы знаете возможности команды или нет? Насколько хорошо Вы знаете продукт? Насколько команда знает продукт? Команда собрана с нуля или давно работает в таком составе? Какие задачи руководство планирует решить с помощью Вас? Какие задачи Вы планируете решить с помощью этой проверки? 

[orandzheviyman]

Для этого и существует sitechco.com 

[Сергей]

Круть, чуваку дают отдел в 20 человек, а он ищет ответ на форумах. Книги по управлению и оценке не пробовали читать?

Вы так готовитесь к собеседованию или уже завалили?

[Vasiliy]

Если команда в 20 человек уже есть, а вы им только выдаете кредит доверия, то значит вы пришли к готовой команде, а не собирали ее.

В таком случае общайтесь с предыдущим руководством (по возможности), с коллегами и другими участниками процесса.

Перепроверять сами за всеми не сможете, делегировать ведущим тестировщикам сможете после того как выдадите им кредит доверия. И то только в случае, если они поймут и согласятся, что надо проверять за тем и за тем.

 

PS.

А вообще Сергей прав. Такие вещи надо отрабатывать на небольших командах,  а не отделах в 20 человек.

[Dananas]

На одном из мест работы, нас, сопляков, просили делать отчетный документ со скриншотами, что все работает согласно заявленным требованиям. В случае обнаружения ошибки на продакшене, поднимались эти отчеты. Если данная проверка была выполнена, но результат отличный от боевого, то шло разбирательство в сторону не обманул ли тестировщик или это проблема боевой среды. Если такой проверки не было озвучено в отчете, то выговор тестировщику и/или аналитику о том, что не подумали про это.

Примерно как-то так.

[lurk]

На одном из мест работы, нас, сопляков, просили делать отчетный документ со скриншотами, что все работает согласно заявленным требованиям. В случае обнаружения ошибки на продакшене, поднимались эти отчеты. Если данная проверка была выполнена, но результат отличный от боевого, то шло разбирательство в сторону не обманул ли тестировщик или это проблема боевой среды. Если такой проверки не было озвучено в отчете, то выговор тестировщику и/или аналитику о том, что не подумали про это.

Примерно как-то так.

Если ошибка специфическая или плавающая кому попадало?

Как определяли кто виноват тестировщик или аналитик, если не была озвучена проверка в отчете?

 

PS: Если организация так любит отчетность полезно вначале отдавать документ с тестами на рецензирование и утверждение вышестоящим заинтересованным лицам под подпись - с конечным утверждением от непосредственного руководителя проекта. Чтобы не возникло ситуации обвиняем невиновных. 

PS2: Были ситуации когда тестировщик обманывал?

[Dananas]

 

 

Если ошибка специфическая или плавающая кому попадало?

Ошибки не по основному функционалу или плавающие, или еще какие левые фиксировались с дальнейшим разбирательством ведущего СКУя почему так.

 

 

 

Как определяли кто виноват тестировщик или аналитик, если не была озвучена проверка в отчете?

Тут сложнее =)

По большому счету всегда виноват тестировщик, за каким-то небольшим исключением, когда аналитик реально накосячил с документом.

 

 

PS: Если организация так любит отчетность полезно вначале отдавать документ с тестами на рецензирование и утверждение вышестоящим заинтересованным лицам под подпись - с конечным утверждением от непосредственного руководителя проекта. Чтобы не возникло ситуации обвиняем невиновных. 

 

Примерно так и было. Тестировщики писали 2 документа на задачу: сценарий проверки и краткая выдержка большими мазками о том, что будет проверяться. Сценарии проверял СКУй (SQA), выдержку смотрели аналитики, что задачу мы поняли верно.

 

 

 

PS2: Были ситуации когда тестировщик обманывал?

Сам лично =)

Была задача, тестовые данные к которой были в единственном экземпляре. Я как умный человек сначала все проверил, а потом только спохватился, что отчет не написал. Пришлось в пейнте перерисовывать скриншоты =)

 

П.С. Основная идея всей этой схемы заключалось в том, что бы минимизировать риски по выкату версии с критическими ошибками. Минорные то висели у нас по пол года и это было нормально. 

Немного сумбурно ответил, и возможно глобальную мысль не передал, прошу прощения за это, не выспался =)