В прошлых публикациях (первая и вторая) рассмотрели основные понятия про качество, четырехуровневый процесса управления и обеспечения качества, увидели что требования и качества тесно связаны друг с другом, попробовали получить ответы на вопросы какое мышление должно быть у команды для встраивания качества в продукт? Какая на продукте пирамида тестирования? Как ускорить получение обратной связи при разработке программного обеспечения?
Отлично. Разобрались, осознали и приняли мышление Test-First, концепцию Shift Left Testing, определили пирамиду тестирования. Теперь возничкает вопрос, а как начать качественно генерировать качественные тест кейсы?
Любой программный продукт, будь то веб-сайт или мобильное приложение, основан на коде. Чем согласованнее и целостнее эта база, тем удобнее с ней будет работать, например, при необходимости доработки проекта, передачи на сопровождение другой команде.
Основными критериями качественного кода являются следующие: простота восприятия, гибкость для модификаций, возможность обновления, понятность, тестируемость. Однако зачастую работа над проектом ведется в спешке, под давлением и код пишется людьми с разным уровнем квалификации (с разным мышлением). И даже опытные разработчики не всегда пишут код самого высокого качества. Поэтому для повышения качества кода проводится процедура code review.
Какое мышление должно быть у команды для встраивания качества в продукт? Какая на продукте пирамида тестирования? Как ускорить получение обратной связи при разработке программного обеспечения? Продолжим разбираться...
Как обеспечить качество программного обеспечения? Как обеспечить качественные производственные процессы? Как сделать так, что поменять, чтобы процессы и сам продукт имели встроенное качество?
Такими вопросами задаются практически все компании, которые занимаются производством программного обеспечения и для которых важно доставлять ценность до клиента без дефектов.
Этой статьей начинаю серию публикаций, посвященную встроенному качеству и как мы меняли процессы в нашей компании.
