Agile Software Development Quality Assurance. Ioannis Stamelos, Panagiotis Sfetsos
Книга интересна тем, что написана вроде как не программистами. Учеными, которым не надо работать по Agile/Waterfall, соотеветственно, они могут смотреть со стороны и изучать, как бабочек.
Аджайл назвали Аджайлом в 2001м, основные принципы -
В теории, код рефакторят, упрощая и убирая ошибки. Применяют TDD. Пользователи смотрят и говорят, что не так. Постоянно бегают автотесты. Программисты работают в парах, чтоб делать поменьше ошибок. Постонно каонтактируют с заказчиком, чтоб понимать, то ли вообще делают. Заказчик понимает, что качество зависит от него. Постоянный фидбэк помогает.
Это все в теории.
На практике - если документации мало, проект теряет управляемость через полгода. Никто не помнит, как должно работать и уж тем более, почему именно так.
Если документации мало, обязанность "проверить всё" ложится на плечи тестера, который, таким образом, становится еще и бизнес-систем-аналитиком. Иначе никак.
* * *
Дальше говорят, что "чтото прогнило" поняли давным-давно, чуть не сразу, как появился "водопад". Проекты падали, закрывались, не окупались...
Искали, пытались, придумали - "улучшать качество продукта". Не пошло.
Искали, пытались, придумали - в девяностых решили "улучшать процесс". Инструкции, планы, шаги, обеспечение качества по всем направлениям.
Попробовали. Помогло? Да, но не очень. Проекты все равно падали, закрывались и не окупались, хотя процент успешных проектов несколько увеличился.
Начали искать дальше, придумали Аджайл. Пробуем. Помогает? А черт его знает. Исследовать надо. Истории успеха рассказывают все и всем, но какой порцент продолжает падать, закрываться и не окупаться? Тут еще забавная фишка - затраты на одну итерацию, безусловно, меньше. Но вот проект целиком запросто может стать дороже, чем при старом добром "водопаде".
Тестеры тоже не спали в шапку, а понемногу придумывали, как бы так отдавать качественный продукт.
Придумали V-модель, которая, в принципе, работала - и работает до сих пор, даже в Аджайле, просто теперь во время итераций.
Лучше-то все равно ничего нет. Разве что автотесты.
* * *
Поговорим про спеки.
Спеки не совершенны, ибо
Аджайл предлагает писать мало, часто показывать, обсуждать. Отсюда - заказчик обязан участвовать, ему показывают, требования должны быть маленькими, говорить на одном языке с заказчиком.
Дальше исполняется гимн "Юзер-Стори спасет мир!" Они короткие, понятные, законченные, обсуждаемые, несут ценность заказчику, их можно оценить и протестировать.
Добавляйте роли, а то и персонажей, пишите определения "готово".
Нет, проблемы, конечно, есть.
Заказчик может сказать "Но я же хотел совсем не ЭТО!"
Иногда все-таки нужно отслеживать, откуда и куда растут требования.
Участие заказчика вроде как снижает риски, но может увеличивать стоимость.
Если проект большой, то начинаются проблемы коммуникаций.
* * *
Поговорим о тестировании GUI.
Очень хорошо бы использовать автотесты.
Как к этому прийти? Можно по шагам.
* * *
История успеха - которая сводится к тому, что одной команде нравилась их работа настолько, что они работали 12/7, но успевали к дед-лайнам, и решили, что "так дальше жить нельзя". Поискали - нашли - воплотили, и заработало. То есть, как и раньше, успевают к дед-лайнам, но у них появилось немного свободного времени.
Аджайл назвали Аджайлом в 2001м, основные принципы -
- итеративность,
- инкреметнальность (каждая итерация отдает релиз),
- самоорганизация,
- готовность к неожиданносятм.
В теории, код рефакторят, упрощая и убирая ошибки. Применяют TDD. Пользователи смотрят и говорят, что не так. Постоянно бегают автотесты. Программисты работают в парах, чтоб делать поменьше ошибок. Постонно каонтактируют с заказчиком, чтоб понимать, то ли вообще делают. Заказчик понимает, что качество зависит от него. Постоянный фидбэк помогает.
Это все в теории.
На практике - если документации мало, проект теряет управляемость через полгода. Никто не помнит, как должно работать и уж тем более, почему именно так.
Если документации мало, обязанность "проверить всё" ложится на плечи тестера, который, таким образом, становится еще и бизнес-систем-аналитиком. Иначе никак.
* * *
Дальше говорят, что "чтото прогнило" поняли давным-давно, чуть не сразу, как появился "водопад". Проекты падали, закрывались, не окупались...
Искали, пытались, придумали - "улучшать качество продукта". Не пошло.
Искали, пытались, придумали - в девяностых решили "улучшать процесс". Инструкции, планы, шаги, обеспечение качества по всем направлениям.
Попробовали. Помогло? Да, но не очень. Проекты все равно падали, закрывались и не окупались, хотя процент успешных проектов несколько увеличился.
Начали искать дальше, придумали Аджайл. Пробуем. Помогает? А черт его знает. Исследовать надо. Истории успеха рассказывают все и всем, но какой порцент продолжает падать, закрываться и не окупаться? Тут еще забавная фишка - затраты на одну итерацию, безусловно, меньше. Но вот проект целиком запросто может стать дороже, чем при старом добром "водопаде".
Тестеры тоже не спали в шапку, а понемногу придумывали, как бы так отдавать качественный продукт.
Придумали V-модель, которая, в принципе, работала - и работает до сих пор, даже в Аджайле, просто теперь во время итераций.
Лучше-то все равно ничего нет. Разве что автотесты.
* * *
Поговорим про спеки.
Спеки не совершенны, ибо
- никто не знает, что хочет с самого начала,
- даже если знают все требования, никто не знает детали,
- даже если все детали описаны, их никто не прочитает ("не осилит"),
- даже если прочитает, спеки все равно изменятся.
- Все делают ошибки.
Аджайл предлагает писать мало, часто показывать, обсуждать. Отсюда - заказчик обязан участвовать, ему показывают, требования должны быть маленькими, говорить на одном языке с заказчиком.
Дальше исполняется гимн "Юзер-Стори спасет мир!" Они короткие, понятные, законченные, обсуждаемые, несут ценность заказчику, их можно оценить и протестировать.
Добавляйте роли, а то и персонажей, пишите определения "готово".
Нет, проблемы, конечно, есть.
Заказчик может сказать "Но я же хотел совсем не ЭТО!"
Иногда все-таки нужно отслеживать, откуда и куда растут требования.
Участие заказчика вроде как снижает риски, но может увеличивать стоимость.
Если проект большой, то начинаются проблемы коммуникаций.
* * *
Поговорим о тестировании GUI.
Очень хорошо бы использовать автотесты.
- Крэш-тесты при каждом коммите.
- Смоук-тесты каждую ночь.
- Полный цикл, когда готов релиз-кандидат.
Как к этому прийти? Можно по шагам.
- Сначала определить, что тестировать.
- Потом сделать Инпут.
- Потом сделать проверку Аутпута.
- Прогнать тесты.
- Сделать вывод - работает или нет.
- И добавить это все в регрессию.
* * *
История успеха - которая сводится к тому, что одной команде нравилась их работа настолько, что они работали 12/7, но успевали к дед-лайнам, и решили, что "так дальше жить нельзя". Поискали - нашли - воплотили, и заработало. То есть, как и раньше, успевают к дед-лайнам, но у них появилось немного свободного времени.