- Тестирование в проекте должно быть. Если тестирования нет — на проекте можно ставить крест. Еще лучше — даже не начинать такие проекты :)
- Разработчики должны сами тестировать свой код. Причем, тесты должны создаваться разработчиками до того, как они напишут свою первую строку кода ("test first" — этот подход описан в книге Кента Бека "Test Driven Development" и применяется в экстремальном программировании). Для чего:
Во-первых, такой подход позволит создавать "чистый" код, то есть код, не содержащий ничего лишнего. Добавить в процессе кодирования пару-другую "кульных" фич, которые якобы обязательно будут использоваться — по-моему, этим болеют все разработчики. Пересилить себя и не делать этого очень трудно.
Во-вторых, тестируя свой код, разработчики начнут задумываться о том, как они будут это делать. Иногда проблема невозможности тестирования доходит до крайности, когда нужно все выбрасывать и начинать заново. Разумеется, наличие толкового архитектора должно свести такие проблемы к минимуму, но опыт показывает, что разработчики, которым наплевать на тестирование, могут свести на нет все благие начинания. Да и толковых архитекторов не так уж легко найти... Как, впрочем, и разработчиков. Но это совсем другая история :)
Третье, и самое главное достоинство этого подхода, — у разработчиков появится четкое понимание задачи, поставленной перед ними. Не редкость, когда разработчик приступает к реализации решения, не разобравшись толком, что же на самом деле требует ТЗ. Как результат — переделывание уже выполненной работы, иногда по нескольку раз, а значит, потеря драгоценного времени. - Наличие в проекте команды тестеров. Это совсем необязательно на ранних этапах проекта, но, как говорится, "must be" уже со следующей итерации. Чем они должны заниматься: анализ существующих тестов на предмет актуальности и полноты (например, на основе статического анализа кода можно выяснить, что покрытие кода тестами не приближается и к 15%, даже несмотря на то, что разработчики старательно выписывают тесты, как написано в предыдущем пункте); создание новых сценариев и тестов, которые еще не были реализованы; вообще, стремиться всячески поставить разрабатываемую систему в такую позу, чтобы она (система) с перепугу начала делать что-нибудь не то, или выдала какой-нибудь непотребный Segmentation fault. Также эти ребята должны проводить и другие виды тестирования, например, динамическое, нагрузочное и стрессовое тестирование. При этом наличие тестеров предполагает, что разработчики будут продолжать создавать часть тестов самостоятельно.
- Тестирование должно быть автоматизированным! Как говорят военные, у продукта должно быть только две кнопки — "вкл." и "пуск ракеты". Этот очень логичный подход должен применяться и здесь. Существует множество фреймворков, чтобы облегчить реализацию этого пункта. Например, семейство xUnit — эффективные и простые в обращении продукты, к тому же совершенно бесплатные. Казалось бы, автоматизация тестов — вполне логичный подход, но, к сожалению, с ужасающей регулярностью приходится наблюдать тестирование "в живую". Это когда разработчик пишет, например, функцию сложения двух чисел и вместо того, чтобы запускать набор тестов, он каждый раз запускает свою программу, вводит с клавиатуры разные числа и смотрит, что же там его программулина наскладывала... Жуть!
Фух! Ну вот, вроде бы удалось изложить мысли не сильно сумбурно :)
