Спросили, могу ли я поделиться настоящими боевыми тест-планами, иной документацией, просто чтобы посмотреть, как организован процесс тестирования в крупных компаниях. Если конфиденциальность позволяет.
Конфиденциальность не позволяет. Это даже не смешно.
К тому же, одни только документы вряд ли покажут, как, собственно, организован процесс. Кто учился летать по-учебникам физики?
Просто ознакомиться с темплейтами подобных документов можно достаточно легко:
- На carnegiequality.com — темплейты документации. Я их использовал, нормально сделанные.
- На неофициальном сайте сайте российских ГОСТ-ов rgost.ru есть ГОСТ-ы в области разработки программного обеспечения. Это читать можно только в случае крайней необходимости 🙂
- У Сергея Орлика в левой колонке есть линк на pdf Тестирование (по SWEBOK). Грамотная штука, но опять же — на уровне форматов (изучите устройство автомата, курсант), а не на уровне «резать врага надо так и этак».
Учесть надо и то, что такие документы не имеют определенной формы. Формат есть, а форма разная, зависит от содержания. Предполагается, что человек, который ими интересуется, достаточно подготовлен для того, чтобы прочитав их, смог извлечь и применить то, что может помочь конкретно ему в конкретной ситуации. Руководствоваться ими реально, но с большими допущениями.
Большая часть подобных бумаг просто неприменима в «боевых условиях» в маленькой компании, и даже излишне их упоминать, не то, чтобы их заполнять.
Для справки приведу пример непосредственно процесса, который используется в отделе тестирования в большой компании:
- Если «вижу» большой кусок работы (полчаса и больше) — надо открывать отдельные задачи в QA project и назначать их на себя или того, кому эти задачи предназначены.
- Исключение может быть сделано для очень мелких тасков и каких-то внутренних специфических дел.
- Надо постоянно процесить статус задач в системе соответственно их состоянию
- Например, надо переводить задачу в «in progress» когда начинаю работу над ней, а не через день и не через 2 дня, как получается.
- Надо регулярно отмечать время, затраченное на работу над задачами в отдельности.
- Можно делать лог ворк раз в день, но надо в одно и тоже время, и обязательно до митингов с менеджерами или с заказчиком. А задач в системе — сотни.
- Надо проверять потраченное время, когда закрываю задачу.
- Если я закрываю задачу, не залогировав время — это практически равноценно тому, что я справился с ней за 0 минут и можно планировать такую же высокую скорость в будущем для решения подобных задач.
В большой компании без всего этого тупо невозможно работать.
В маленькой компании все это тупо мешает.
Все это и есть «процесс». Собственно тестирование проходит тенью рядом со всем этим великолепием управленчества.
Процессы — это очень хорошо!!! Есть только одна проблема — заставить/уговорить/убедить всех придерживаться им.
Одному это будет удобно, другого будет раздражать, в итоге — раскол.
Приходя работать в большую компанию, нужно быть готовым к тому, что под тебя никто подстраиваться не будет, нужно быть готовым играть по правилам, которые там заведены. Иначе ты не приживешься.
Маленькие же компании более гибкие и готовые к изменениям.
Когда-то начитался о полезности и преимуществах Wiki.
Был опыт внедрения Wiki в компанию из пяти человек. Бесполезно.
Был опыт внедрения Wiki в отдел из пяти человек. Насильственно, но благополучно.
Был опыт использования Wiki в компании из десяти человек, которые относились к этому как к обычному рабочему инструменту. Все было прекрасно.
Поэтому мне кажется, что уговаривать не надо. Или оно работает, или нет.
Но если вернуться к «автомату» 😉 — SWEBOK, его лёгкая модификация общими усилиями с Юрием Булуем теперь находится здесь — http://swebok.sorlik.ru
Детали — в анонсе http://sorlik.blogspot.com/2010/01/swebok.html
С уважением,
-Сергей Орлик