Конфиденциальность не позволяет. Это даже не смешно.

К тому же, одни только документы вряд ли покажут, как, собственно, организован процесс. Кто учился летать по-учебникам физики?

Просто ознакомиться с темплейтами подобных документов можно достаточно легко:

1. На carnegiequality.com — темплейты документации. Я их использовал, нормально сделанные.
2. На неофициальном сайте сайте российских ГОСТ-ов rgost.ru есть ГОСТ-ы в области разработки программного обеспечения. Это читать можно только в случае крайней необходимости 🙂
3. У Сергея Орлика в левой колонке есть линк на pdf Тестирование (по SWEBOK). Грамотная штука, но опять же — на уровне форматов (изучите устройство автомата, курсант), а не на уровне «резать врага надо так и этак».

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

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

Для справки приведу пример непосредственно процесса, который используется в отделе тестирования в большой компании:

• Если «вижу» большой кусок работы (полчаса и больше) — надо открывать отдельные задачи в QA project и назначать их на себя или того, кому эти задачи предназначены.
  • Исключение может быть сделано для очень мелких тасков и каких-то внутренних специфических дел.
• Надо постоянно процесить статус задач в системе соответственно их состоянию
  • Например, надо переводить задачу в «in progress» когда начинаю работу над ней, а не через день и не через 2 дня, как получается.
• Надо регулярно отмечать время, затраченное на работу над задачами в отдельности.
  • Можно делать лог ворк раз в день, но надо в одно и тоже время, и обязательно до митингов с менеджерами или с заказчиком. А задач в системе — сотни.
• Надо проверять потраченное время, когда закрываю задачу.
  • Если я закрываю задачу, не залогировав время — это практически равноценно тому, что я  справился с ней за 0 минут и можно планировать такую же высокую скорость в будущем для решения подобных задач.

В большой компании без всего этого тупо невозможно работать.

В маленькой компании все это тупо мешает.

Все это и есть «процесс». Собственно тестирование проходит тенью рядом со всем этим великолепием управленчества.