kristi_k

Я еще не эксперт, но опыт организации тестирования уже есть. Попробую рассказать на своем примере.

Когда я пришла в компанию, опыта в тестировании у меня практически не было. В компании я была единственным тестировщиком.

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

Никто не ставил мне цель организовать процесс тестирования, моя задача была просто тестировать!:)

Я начала с изучения очень большого и сложного проекта, читала ТЗ, задавала много вопросов и первое время просто тестировала то, что считала нужным, без планов. К слову, тогда я нашла очень много багов, о которых долгое время никто не подозревал.

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

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

Появилось много правил, например: "исправил, сразу сообщи", "обновил версию, сообщи" и т.д. Все это делалось для того, чтобы я была в курсе о состоянии дел на проекте и мы ничего не упустили.

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

Документация нужна тогда, когда уже сложно контролировать все на словах. Тест-план - достаточно бесполезная штука в том виде, в котором его предлагают обычно.

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

1. Выяснить, какие приоритеты у проекта (меньше багов/ скорость тестирования/ тестирование основных штук/тестирование все и вся). Нужно понять, что хочет начальник и что хочет заказчик (иногда "хотелки" отличаются). 

2. Выяснить, какие виды тестирования проекту нужны (нужно ли нагрузочное тестирование, производительности, безопасности и т.д.)

3. Изучить проект (анализ ТЗ, анализ пользователей).

4. Если нужен Тест-план (требуют) - написать. Если нет: написать Тест-план для себя в свободной форме: определить приоритетность проверки функционала, определить виды тестирования, определить сроки, определить, что сейчас не нужно, но хотелось бы внедрить.

5. Наладить процесс взаимодействия в команде (определить правила, кому, куда и зачем обращаться, в каких случаях к аналитику, в каких к руководителю, в каких к разработчику и т.д.).

6. Подумать, какие инструменты могут пригодиться в процессе тестирования, найти, изучить, скачать бесплатно/нужно купить.

7. Составить чек-листы или тест-кейсы (я больше люблю кейсы, с ними удобнее понимать, что твой сотрудник, пройдя его точно проверил самые основные сценарии).

8. Тестировать самостоятельно проект по намеченным планам.

9. Анализировать запланированное время на тест и фактическое. Учиться точно оценивать сроки.

10. Анализировать итоги тестирования: что было запланировали и что успели сделать, какие были найдены баги, где еще надо поискать и т.д.

Я тоже посоветую курсы Натальи Руколь, мне они очень помогли.