Процесс тестирования в крупных компаниях

Спросили, могу ли я поделиться настоящими боевыми тест-планами, иной документацией, просто чтобы посмотреть, как организован процесс тестирования в крупных компаниях. Если конфиденциальность позволяет.

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

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

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

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

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

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

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

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

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

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

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

3 ответа на “Процесс тестирования в крупных компаниях”

  1. Процессы — это очень хорошо!!! Есть только одна проблема — заставить/уговорить/убедить всех придерживаться им.
    Одному это будет удобно, другого будет раздражать, в итоге — раскол.
    Приходя работать в большую компанию, нужно быть готовым к тому, что под тебя никто подстраиваться не будет, нужно быть готовым играть по правилам, которые там заведены. Иначе ты не приживешься.
    Маленькие же компании более гибкие и готовые к изменениям.

  2. Когда-то начитался о полезности и преимуществах Wiki.
    Был опыт внедрения Wiki в компанию из пяти человек. Бесполезно.
    Был опыт внедрения Wiki в отдел из пяти человек. Насильственно, но благополучно.
    Был опыт использования Wiki в компании из десяти человек, которые относились к этому как к обычному рабочему инструменту. Все было прекрасно.
    Поэтому мне кажется, что уговаривать не надо. Или оно работает, или нет.

Добавить комментарий