Freeartists статьи и рецензии о технологиях
Независимый отдел тестирования и его задачи
При разработке программ без тестирования не обойтись, поэтому ситуацию отсутствия тестирования или попытки заменить его такими несерьезными методами как кросс-тестирование или тестирование на живых пользователях, мы рассматривать не будем.
Тем не менее, даже там, где полноценное тестирование входит в цикл разработки, его часто организуют неправильно. В этой статье я расскажу, как должно быть организованно тестирование.
Что и как тестировать
Известно, что самые опасные ошибки это идеологические и архитектурные ошибки, заложенные на старте проекта. Именно они имеют максимальный срок и силу влияния на проект, и именно из-за них терпят неудачу многие проекты с нормальным управлением и финансированием. Поэтому, начинайте тестирование как можно раньше. Тестируйте: техническое задание, черновики документации, наброски архитектуры и первые прототипы.
Когда проект стартовал, и первый код уже написан, проверяйте все решенные задачи, пишите приемочные тесты на всю готовую функциональность. Обязательно проверяйте все новые версии, даже если они не пойдут в бой. Составляйте и актуализируйте план тестирования или чек-лист для каждого разрабатываемого продукта.
Определите опытным путем время, необходимое на тестирование новой версии, исправление найденных ошибок и подготовки к выходу исправленной версии. Учитывайте это время в своем календарном плане. Это время не константа. В начале проекта это может быть один-два дня, ближе к концу, когда основная функциональность будет уже написана, время на тестирование и исправление может достигать нескольких недель, а в конце проекта, по мере стабилизации кода, время на тестирование сокращается. Умножайте это время на два перед выпуском знаковых версий продукта.
Состав группы тестирования
В идеальной группе тестирования должны быть следующие роли: начальник отдела тестирования, специалист по автоматическому тестированию, специалист по нагрузочному тестированию, несколько специалистов по ручному тестированию, аналитик, технический писатель и юзабилити специалист.
Начальник отдела тестирования — распределяет ресурсы отдела между различными проектами, отвечает за сроки тестирования новых версий продуктов, принимает решение о соответствии продуктов принятым в компании стандартам качества.
Специалист по автоматическому тестированию — создает автоматические тесты на всю важную функциональность, отвечает за их актуализацию и своевременное выполнение (прогон автоматических тестов занимает много времени). Кроме этого данный специалист должен отвечать за создание тестового стенда и различного рода автоматизацию, например, за написание билд-скриптов. Обязательно выделите на эту роль отдельного человека, иначе он погрязнет в ручном тестировании.
Специалист по нагрузочному тестированию — мне сложно представить систему, для которой производительность и скорость реакции не была бы критична. Поэтому нагрузочное тестирование нужно начинать на самых ранних стадиях. Например, проверять наброски архитектуры и структуры базы данных на соответствие заявленным в начале проекта характеристикам производительности.
Специалистом по нагрузочному и автоматическому тестированию может быть один человек. Он должен иметь высокую техническую квалификацию, разбираться в особенностях используемых протоколов, базах данных и языках программирования. Обычно, такие специалисты дорого стоят, но поверьте, иметь в штате такого человека гораздо лучше, чем толпу студентов.
Специалист по ручному тестированию — автоматизировать все не возможно, машина не заменит человека. Руками пройтись по основным функциям и бизнес логике, проверить соответствие проекта техническому заданию и спецификации может только человек. Обычно на эту роль нанимают студентов старших курсов технических специальностей.
Аналитик — специалист предметной области и бизнес логики ваших продуктов. Это связующее звено между отделом тестирования, командой проекта и заказчиком. Он отвечает на вопрос, как должны работать продукты.
Технический писатель — пишет и актуализирует техническую документацию. Возможно, многие со мной не согласятся, но я считаю, что писать техническую документацию должны не разработчики, а специально выделенный специалист в отделе тестирования. Отдел тестирования является одним из основных потребителей документации, носителем знаний о проектах компании и интеграции между ними.
Разработчики должны использовать системы автодокументирования, пытаться заставить их писать документацию — это отличный способ получить плохо документированный продукт и конфликты в коллективе.
Юзабилити специалист — если ваш продукт имеет пользовательские интерфейсы, вам нужен человек, который будет проверять их соответствие ожиданиям пользователей. Конечно, по-хорошему, у вас в организации должен быть специализированый отдел проектирования и тестирования интерфейсов, но не все могут себе это позволить. Если вы наняли специалиста по пользовательским интерфейсам, но у вас нет специализированого отдела, то лучше ему работать в отделе тестирования, так он не будет зависеть от менеджеров проектов.
Главное, что работники отдела тестирования должны не просто констатировать наличие ошибок или не соответствие спецификациям, но и помогать разработчикам находить причины этих ошибок. Для этого специалисты по тестированию должны хорошо разбираться в предметной области, архитектуре проектов и всегда проверять окружение тестируемой функциональности.
Идеальный тестовый стенд
Создание правильного тестового стенда задача очень важная и не сложная, но, почему-то, многие ее игнорируют. Это приводит к серьезным ошибкам на всех уровнях: от архитектуры и дизайна, до производительности готового продукта. Пример: реальные заголовки в два раза длинней из-за этого разъезжается верстка; в боевой базе 2 миллиона транзакций, а не 100 из-за этого поиск работает медленно; реальное оборудование слабее машин разработчиков и т. д.
В результате, первая версия продукта может настолько не соответствовать ожиданиям, что время необходимое на доводку как бы готового продукта часто превышает время на его создание.
Вот три простых требования к тестовому стенду:
- Тестовые данные должны отражать реальность. Если вы делаете новую версию уже существующего проекта, вы должны скопировать его базу данных, замаскировав секретные данные. Если вы делаете новый продукт, вы должны сгенерировать данные похожие на настоящие. Это не должно быть «бла бла бла». Вы даже можете начать наполнять базу реальными данными, до того как будут готовы средства их визуализации.
Для синхронизации тестовой базы с боевой, для маскирования секретных данных и для наполнения базы фейковыми данными, разумно использовать скрипты. Тут-то вам и пригодиться специалист по автоматизации. - Тестовое оборудование должно соответствовать оборудованию, на котором будет работать боевая версия продукта. Не всегда это возможно, но, по крайней мере, архитектура тестового оборудования должна соответствовать, а производительность быть слабее. У меня в практике был пример, когда база данных и приложение находились на разных машинах, но стояли в одной стойке, соединенные очень быстрым каналом. А в бою оказалось, что машина с базой находиться в Америке, а с приложением в России. Нам многое пришлось переделать.
- Программное обеспечение боевой и тестовой машины должно быть абсолютно одинаковым. Вплоть до версии ОС и всех программ. Не соответствие программного обеспечения тестовой и боевой машины порождает самые загадочные глюки.
Все сказанное выше верно и для машин разработчиков. Применить для машин разработчиков правила 1 и 3 не составляет труда.
Автоматизация тестирования
Как уже говорилось выше, автоматизация тестирования очень важная задача. Особенно в условиях нехватки ресурсов на тестирование.
Кроме написания своих скриптов и макросов используйте готовые инструменты. Например, для web существуют валидаторы, проверяющие все страницы сайта на соответствие спецификациям W3C, и программа Xenu, ищущая битые ссылки.
Не забывайте про юнит-тесты, хотя писать их должны разработчики, но запускать, при сборке новой версии, могут и специалисты отдела тестирования.
Независимый тестовый отдел
Во многих организациях и проектах, в которых я работал, группа тестирования входила в состав проекта и подчинялась непосредственно менеджеру проекта. Это в корне не правильно, так как приводит к конфликту интересов между менеджером проекта и специалистами по тестированию. Менеджеру хочется быстрее закончить проект и сознательно или нет, он склоняет тестировщиков к выпуску некачественного продукта.
Не зависимо от структуры вашей компании, состоит ли она из отделов или проектов, отдел тестирования должен быть независимым и иметь такой же уровень подчиненности как отделы разработки или проектные команды. Иначе говоря, менеджеры проектов и начальник отдела тестирования должны быть равны в правах. Это гарантирует отсутствие конфликта интересов и соответствие готовых продуктов заявленным в спецификациях стандартам качества. Кроме того, у вас появиться человек, который будет нести реальную ответственность за качество.
Комментарии закрыты