Слушай, Sancha

У меня есть подруга, она на Эвен Кейсар экономистом работает. Как это у них в реале поставлено можно у неё узнать. Не знаю поможет ли это тебе. Но спросить можно.

Проблема в том, что и учиться не у кого. Команда из не опытных(ето я себя имею ввиду) и не очень опытных. То что я читаю в BTS как описание бага мне кажется могло бы быть удачнее. Баги не имеют названий (правда указан номер тест-кейса), просто в клетке EXCEL пишется: в прицессе таком-то, сделал то-то и то-то, произошло так-то. И пока ты не прочтёшь весь рассказ , не поймёш в чём проблема.
Наши опусы никто не правит. Сравнивать мне не с чем.
А информацию я ишю и уже нахожу. Етот форум, например, меня очень продвинул в понимании предмета, спасибо всем, кто принял учавствие в обсуждении.

Тестируем мы систему CRM/Billing компании связи. Всвязи с етим хочу спросить есть ли у кого подобный опыт, каковы специфические моменты тестирования систем CRM? Мне кажется наши тесты а их сейчас около 500 не покрывают всей функциональности, она очень разветвлённая.
Например, параллельно с нами тестируют по-переменно юзеры етой системы из самых различных подразделений (продаюшие, поддерживаюшие, агенты, управленци и т.п) Девочка из продаж открывает баг - "система продала пакет услуг "А" клиенту- обладателю свийстава "Б". А вот в ныне работаюшей системе етого не происходит. ("В,Г..." можно а вот "Б" нет)"
В нашей документации не описаны подобные бизнес правила, значит я не могу впринципе выйти на подобные баги. Ето нормально? Или я что-то упускаю?

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

Хочу учиться оптимально описывать баги, где и как ето сделать?

наш старший просто сливает все описания багов и линки на иллюстрации в таблицу Excel. Тблица доступна всем. Можно впринципе там искать, но поиск затруднен свободным стилем описания багов разными/разношёрстными авторами

Здравствуйте
Я в тестировании человек новый, хочу с опытными и знаюшими обсудить ситуацию сложившуюся у нас на проекте. В команде нашей 4 чел. + старший группы(играюший тренер). Ежедневно мы сдаём отчеты о сделанных тестах и описания найденных багов.
Старший всё ето собирает в один документ и раз в 2 дня заседает с разработчиками на предмет продвижения проекта и статуса проверок. Т.к тестеры делают ротацию- меняются тестами чтобы каждый мог лучше познакомиться со всей системой. Они начинают подавать уже открытые кем-то ранее баги(на сегодня открыто несколько сот штук) Разработчики етим недовольны, начальник проекта настаивает на выучвании тестерами всех открытых багов. Всвязи с етим вопрос: как боротся с "даблами"? Как их отсеивать? Какая практика наиболее еффективна и приемлема в описанной мною ситуации? :help:
Спасибо