Выполнимость наличия тестеров в небольшой [закрытой] компании/Команде
5 ответов
Вы определенно можете оставить тестировщика работать полный рабочий день - они должны тестировать продукт на протяжении всего процесса разработки, а не только в конце. Фактически, оставлять тестирование до конца проекта - это самое худшее, что вы можете сделать.
Я работал в паре компаний, в которых обычно есть 1 тестировщик на каждых 2 разработчиков, и никогда не было проблем, когда у них заканчивались дела - на самом деле как раз наоборот.
Обе эти компании были небольшими компаниями с 10-20 разработчиками и 5-10 тестировщиками.
В небольшой компании это сложно, потому что вы правы: вы не можете просто оставлять тестировщиков без дела между раундами формального тестирования. Конечно, они могли бы делать и другие вещи, например писать тестовые примеры и планы тестирования, но даже тогда у них может быть некоторое время простоя. Для небольшой компании может иметь смысл нанимать тестировщиков по контракту, когда они необходимы, поскольку у вас может быть только один продукт для тестирования, а время между продуктами велико. Вы также можете посмотреть, сможете ли вы найти другую компанию, которая проведет за вас тестирование - аналогично найму подрядчиков, но контракт будет заключаться с материнской компанией, а не с отдельными лицами.
В более крупных компаниях обычно (но не всегда) достаточно проектов на разных стадиях разработки / тестирования, чтобы все штатные тестировщики были заняты какой-либо работой. Конечно, иногда спрос превышает имеющиеся ресурсы (штатный персонал для тестирования), поэтому для конкретного проекта иногда привлекаются подрядчики.И да, вы правы, даже подрядчиков нужно обучать работе с системой, которую они тестируют, даже если они работают только над одним проектом.
Вы можете попросить разработчиков протестировать части друг друга, но в целом это не очень хорошая идея, и отдельный тестер будет лучшим вариантом.
Другой вариант - найти стороннюю компанию, которая протестирует приложение за вас. Это также заставит вас лучше составить спецификацию проекта.
Я работаю в небольшой команде, в которой редко бывает больше 1-2 разработчиков в каждом конкретном проекте. У нас нет и не может быть выделенного тестировщика. Обычно я привлекаю своих клиентов к QA-тестированию приложения в среде постановки перед выпуском любого релиза в производство. Это бывает более или менее успешным в зависимости от того, насколько клиент заинтересован в процессе тестирования. Я также в значительной степени полагаюсь на автоматизированные модульные тесты, используя TDD, и значительное ручное тестирование пользовательского интерфейса.
Хотя я хотел бы иметь людей с конкретными обязанностями по тестированию QA, и иногда мой заказчик назначает кого-то в качестве такового, это случается редко. Когда у меня есть выделенный тестировщик (почти всегда представитель заказчика), который вовлечен в процесс, я чувствую, что весь процесс разработки идет лучше.
В подобных ситуациях важно использовать формализованные планы тестирования и находить для тестирования любые ресурсы, не связанные с разработчиками. Часто техническому архитектору или менеджеру проекта приходится составлять критерии приемки или полные планы тестирования для новой функциональности, а также планы тестирования для регрессионного тестирования. Постарайтесь привлечь пользователей, менеджеров проектов, любых заинтересованных лиц, которые готовы помочь вам в тестировании. Но дайте им структуру, чтобы гарантировать, что все необходимые тестовые случаи будут рассмотрены.
Внешний QA-инженер может быть очень полезен в помощи при составлении плана(ов) тестирования, даже если он/она не будет выполнять все тестирование.
Удачи