by Dmytro Makhno

Опыт Более 5ти лет в тестировании, с совмещением обязанностей PM, CM. Интересы Тестирование, QA, PM, CM. SW Development Processes. Убеждения Нет такого процесса, который бы не смог поломать человек. Именно человек делает работу.

Аудитория выступает судьей опыта автора. Автор не относит себя к теоретикам. Почему «эволюция сознания»? Не волнуйтесь, что можете не успеть прочитать весь слайд. Презентация выложена. «узелок» для автора.

Как… Раздел тест плана Вектор развития Использует техники тестирования в качестве… Инструмента Методологии

Специфика проекта Домен, Платформа Размер Проектная команда Позиция менеджмента Опыт клиента Опыт Тестировщиков, Разработчиков Распределение команды Тестовое окружение Предыдущий опыт! Информационный багаж!

Отсеиваем наиболее важные «входы» Анализируем возможные подходы… Выписываем вероятные решения Выбираем(иногда пробуем) наиболее «живучие» (Храбрость или безумие!?) Не делаем сделанный выбор догмой – постоянно улучшаем. (Учимся на ошибках) … ни слова о «тестовой стратегии»

Начинаю эволюционировать…

Множество небольших проектов с ограниченным бюджетом Команда часто меняется Проекты требуют конфигурационного тестирования Клиенты не осознают необходимость тестирования как отдельного процесса

Должны быть повторяемые Test Cases (100% повторяемость не требуется), которые можно использовать в конфигурационном тестировании. Поддержка и составление Test С ases должны быть максимально легкими. Человек должен вводиться в проект максимально быстро, с минимальными знаниями.

Check Lists, как наиболее простая форма Test Case -ов Инструмент TestLink. При необходимости Check List легко расширяется Используем проходы Check List на разных платформах

(+) Тестировщики быстро знакомятся с проектом (+) Работу легко распределять и мониторить исполнение (-) Плохо то, что нигде не учитывается позиция менеджеров. Даже не анализировалось (-) Решение больше выглядит тактическим, что может препятствовать стратегическому развитию отдела и контролю качества в целом (+) Хотя и тактическое решение, но может использоваться как переходное состояние к более «зрелому» тестированию

Разрабатывается собственный продукт, в финансовом секторе, для узкого рынка. Все на.NET, есть Win и Web части, уровни Client, Server и DB явно выделены. От базовой ветки ведутся независимые проекты Количество тестовых проходов по продукту стремится к бесконечности Независимые проекты сильно ограничены в ресурсах Менеджеры проектов (PM), в прошлом разработчики Сейчас приоритет ставится на количестве функционала, но в любой момент может поменяться в пользу стабильной работы Команда мотивированна на развитие (принцип компании) Производство не может останавливаться для детального пересмотра подходов. Отсутствие, даже неформальных, точек интеграции в процессе разработки между разными отделами.

Должно существовать хорошо отлаженное регрессионное тестирование, с хорошим покрытием и повторяемостью. Бросок в сторону автоматизации Подход по регрессии не должен быть «скучным», иначе мотивация у людей пропадет. Второй бросок в сторону автоматизации Тестировщики должны глубже понимать процессы разработки, чтобы работать в союзе, а не в оппозиции Для повышения стабильности должно быть заложено нагрузочное тестирование Желательно, чтобы весь инструментарий был ясен PM- у, для повышения лояльности к тестированию

Выбран сценарий развития : CheckList -> TestCases -> Scripts. Которые постепенно, шаг за шагом, позволит облегчить внедрение автоматизации и не даст производству остановиться TestComplete, как инструмент, для проверки Win Client. MS Visual Studio, как инструмент для проверки уровня Server и произведения нагрузки. Близкий разработчикам, и имеющий дружественный интерфейс для тестировщиков Selenium с интеграцией.NET, как инструмент написания тестов для проверки Web Client Тестировщики активно делятся знаниями по процессам и технологиям

(---) очень много входов и сложно учесть все, сама стратегия довольно сложна для понимания и требует множества навыков (+) людям «технарям», интересно заниматься автоматизацией, и рынок такой опыт ценит, мотивация не снизится (+) сценарий развития способствует постепенному развитию и корректировке по ходу реализации

Огромное число людей разной квалификации Проекты с риском для жизни человека Проекты значительно отличаются друг от друга, но бюджет проектов огромный Команды сильно разбросаны по миру Тестирование является важнейшей точкой контроля Существуют сторонние аудиты, требующие выполнения ряда требований. Их прохождение - критично

Стратегия тестирования должна быть простой и легко понятной, не только для тестировщиков. Если процесс прошел тестирование, то это должно означать, что проблем действительно нет. Большой бюджет позволяет реализовывать дорогие процессы. Необходимо не нарушать требования аудитов Риск ошибки должен быть минимальным! Цена ошибки – жизнь…

Мы можем тестировать или ручками или пытаться автоматизировать, чтобы обеспечить повторяемость. Требования к аудитам должны выполняться, все должны знать чего НЕЛЬЗЯ делать. И уж только потом почему нельзя. Любая сделанная работа проверяется человеком по крайней мере той же квалификации Любая сделанная работа реализуется и проверяется двумя тестировщиками Вся работа повторяется и перепроверяется до тех пор, пока не будет достигнут критерий…

(+) Чем больше раз проверим, тем меньше вероятность ошибки. (-) Очень дорогой процесс (+/-) Явно не подразумевает использование «современного» тестирования. (+) Требования аудита направляют «креатив» в созидательное русло … еще предстоит сделать

Остался один смысловой слайд…

Сложной/простой Дешевой/дорогой … Соответствовать целям проекта!

Что же нужно уточнить…

Можно приступить к дискуссии…