Если совсем никак - это трагично. Но я не верю. Так не бывает.
Все равно ведутся какие-то записи по тому, что протестировано, и какие проверки прошли, а какие нет. Это раз. Второе - есть же лидер, в конце концов. Кто-то ведь определяет, например, что будет автоматизировано. Если этого нет, и все придумывают тесты сами, будет очень много дублирования по базовым проверкам.
По крайней мере, в моей практике все вопросы по "разгребанию" беспорядка в тестах решались путем строгого лидерства и разделения задач. Понятно, что "снизу" это инициировать сложно.

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

Самое легкое, с чего можно начать - это майндмэппинг по новому функционалу. Кто-то один составляет "центр" карты, потом ветки раздаются разным людям, все вместе заполняете. На каких-то ветках может как раз возникнуть необходимость сделать дополнительные таблички комбинаций. Сразу же можно что-то тестировать и отмечать результаты. Потом собираетесь еще раз, обсуждаете работу друг друга (тут важен доброжелательный настрой). Даете советы, кому что улучшить и дополнить. Отмечаете проверки, которые автоматизированы. Думаете, не надо ли где-то организовать перекрестные проверки, т.е. комбинации по разным ветвям функционала, если это может привести к интересным эффектам. Вроде бы, неплохой способ получить реальный эффект от митингов.

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

1. Решения, принятые на митингах, всегда лучше фиксировать, если есть на это время. Пусть это никому не надо, но изредка бывает нужно поднять историю, и тогда это здорово экономит время. Или, например, дать проскроллить новым людям для вникания в процесс.
Строить ли какие-то дополнительные чеклисты - тут мало инфы, надо понимать, как у вас вообще организовано ведение тест-кейсов.

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

2. Если без таблиц - то что делается - только очевидные позитивные проверки и случайно взятые из головы фейлы? Опять же, неизвестно, как у вас организовано тестирование, по каким методикам составляются тесты. Если кто-то отдельно пишет тесты, тогда это надо обсуждать на уровне команды. Если методику выбирает каждый тестировщик сам, к нему будут и вопросы, если что-то недотестировано.

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

Кому не видно? Для кого это проблема?
Кто не получает ожидаемого результата?

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

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

в том что нет какого-то порядка. не видно что автоматизировано а что нет. что протестировано а что нет.

Доброго времени суток всем.

Описание проблемы:
Проект длиной 4 месяца. Типа SCRUM (который заключается в том, что мы ничего не знаем что будет и не думаем вперед, делаем вот этот спринт, сдаем заказчику, и они уже придумывают новые штукенции которые идут в след спринт). Релиз спринта - каждые 2 недели. В первый день спринта тестировщики просматирвают задачи, задают вопросы, также остальные члены команды. Когда задачи закончены, они проверяются ручным тестированием (я). В команде есть автоматизаторы, которые автоматизируют позитивные сценарии. Кроме этого есть еще тестирование апи, этим занимаются те, кто свободен из тестировщиков. Баг трегинговой системы и системы в которой бы описывались тесты нет (максимум - списки в ворде).

Мои предложения по улучшению всего процесса:
1. надо как-то документировать требования, т.к. изменения которые происходят на ежедневных митингах не добавляются в описания задач - решила делать карту. по ней же писать чеклист того что нужно проверить (например, логин для неактивизированного пользоваля и пр.)
2. для тестирования апи создать таблицы с сочетаниями значений (разные методы, обязательные и необязательные поля, разные протоколы) с помощью allpairs например и отмечать так что проверено а что нет.

Вопросы:
1. Стоит ли? Время все это делать есть лично у меня, но интереса в то что это поможет и будет как-то полезно не вижу.
2. Допустим, мы решаем что стоит. Как сделать процесс более правильным и уменьшить количество ошибок, чтобы не получилось что времени на приготовление было потрачено очень много, а эффект как-то не особо заметен.

Спасибо.
За ссылки, любые комментарии и все такое - огромная благодарность.

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

полностью поддерживаю. Вопрос очень актуальный для компаний, которые только начинают, наверно. Каждый руководитель пытается как-то оценивать работы других. У нас сейчас предполагается внедрить систему что за переоткрытую задачу и тестер и разработчик получают минусы. Переоткрыта задача может быть если баги есть. Здесь появляются миллион но:
-но не было явных требований
-но в общении с каким-то другим менеджером решено это было не делать
-но это старый баг который к этой маленькой задаче не относится
-но это сломали после того как сделали что-то другое

И в какой-то момент может получится (совпасть звезды) что минусы будут получаться совсем не объективно.

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

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

Так что тоже буду рада каким-то идеям :)