1. 6 типов документов
1.1. KNOW
1.1.1. Знание
1.1.1.1. Знания — это закономерности предметной области (принципы, связи, законы), полученные в результате практической деятельности и профессионального опыта, позволяющие специалистам ставить и решать задачи в этой области.
1.2. TOOL
1.2.1. Инструменты
1.2.1.1. Инструменты и документы необходимые для работы
1.3. REG
1.3.1. Регламенты
1.3.1.1. Рабочие правила и регламенты
1.4. HOWTO
1.4.1. Мануалы
1.4.1.1. Небольшие инструкции, когда надо просто выполнить какую-то операцию в функциональности, а не изучить ее
1.5. DRAFT
1.5.1. Черновики
1.5.1.1. Для документов в разработке/доработке
1.6. OLD
1.6.1. Архив
1.6.1.1. Для устаревших документов
2. Процесс разработки
2.1. 1. Тестировщик берет задачу на разработку или актуализацию документа
2.2. 2. Документ создается/копируется в [Draft] и получает соотв. отметку
2.3. 3. Тестировщик назначается ответственным за документ
2.4. 3. Документ оформляется/актуализируется
2.5. 4. Документ проходит ревью
2.6. 5. После НЕ прохождения ревью он дорабатывается ответственным, пока ревью не будет пройдено
2.7. 6. Документ размещается в нужном разделе
3. Роли
3.1. Тестер
3.1.1. Пишет/актуализирует инструкции
3.1.2. Назначается Ответственным за документы
3.2. Ответственный
3.2.1. Человек к которому мы придем в вопросе, когда не поймем, что написано в документе
3.2.2. У документа может быть несколько ответственных
3.3. QA
3.3.1. Контроль общего состояния Базы знаний
3.3.2. Ревью документов вместе с тестером
3.3.3. Размещение документов
3.3.4. Помощь PM в выполнении его задач
3.4. Project Manager
3.4.1. Быть в курсе происходящего
3.4.1.1. Контроль сроков
3.4.1.2. Передача актуальной информации заинтересованным лицам
3.4.2. Презентация продукта и результатов
3.4.3. Разработка и согласование ключевых задач и стратегии развития
4. Где отчеты?
4.1. Отчеты не нужны, на все нужные куски функционала и кейсы будут задачи
4.2. Процесс от лица менеджера
4.2.1. В сьют идут тесты пачками на какую-то функциональность
4.2.2. По определенным, согласованным пачкам PM выставил задачи на документацию
4.2.3. Люди которые берут эту пачку получают задачу на разработку документа.
4.2.4. Дальше по Процессу разработки.
4.2.5. В случае факапов и т.п. возможно допилка/доработка позже или передача другим специалистам
5. Направления
5.1. Стоит выбрать одно из них
5.1.1. Варианты
5.1.1.1. Junior Page
5.1.1.2. FORIS
5.1.1.2.1. РТ
5.1.1.2.2. ФТ
5.1.1.2.3. Автоматизация
5.1.1.2.4. Нагрузка
5.1.1.2.5. Модель
5.1.1.2.6. SD
5.1.1.3. Другие проекты
5.1.1.3.1. COCAT
5.1.1.3.2. New Age
5.1.1.4. Сбор данных
5.1.1.4.1. Перебор всех источников информации и разнесение его по структуре
5.1.1.5. Консультации
6. В тест-кейсе все не опишешь
6.1. http://software-testing.ru/library/testing/general-testing/2080---30
7. Дальнейший план, независимо от цели
7.1. Этап 1
7.1.1. Привлечение 2 человек
7.1.2. Закрываем цель
7.1.2.1. Не факт, что все будет делать руками
7.1.2.2. Вероятно будут задачи которые можно будет делегировать скучающим/желающим помочь
7.1.3. Обкатка и повышение компетенций до QA и PM
7.1.3.1. После достижения результата по какой-то цели
7.1.3.2. Люди станут экспертны
7.1.4. ДУмаю работы на недели 2 - 4
7.2. Этап 2
7.2.1. Расширение до 6 человек (парная работа)
7.2.2. Закрываем еще одну цель
7.2.3. Еще неделя-две
7.2.4. Получаем бригаду QA и PM
7.2.4.1. При желании можно расширить
7.3. Дальше можно взять что-то пожирнее с учетом того, что будут запускаться именно тестеры
7.3.1. Эксперты консультируют по тому как все делать
7.3.2. Но не делают за них
7.3.3. МОжно заняться дальнейшим расширением
7.3.3.1. У нас же не тока РТ
7.3.4. Идея! ПМы по направлениям