Slide 1

Slide 1 text

Software Quality - weekly kaizen for a better product - Dev.Talk June 2016 Thomas Mentzel

Slide 2

Slide 2 text

Agenda •Kaizen vs. Kaikaku •Software and Build quality indicators •Summary

Slide 3

Slide 3 text

Kaizen vs. Kaikaku •Kaizen •Small increments of improvement •Faster iterations, small steps •Kaikaku •fundamental and radical changes •One huge step and one big improvement

Slide 4

Slide 4 text

Git •Is the source code checked in? •Which branching concept is used? (GitFlow, GitHubFlow) •Does a readme.md describe the build process? •Does a readme.md describe the required tools?

Slide 5

Slide 5 text

Jenkins •Does an automated build ‘on check-in’ exist? •Was the latest ‘master’ build successful? •Was the latest ‘develop’ build successful? •Does each build get a unique version number? •Are the latest master/develop builds published? (file server)

Slide 6

Slide 6 text

Unit Tests (nunit, junit, xunit, ...) •Does the project contain unit tests? •Is the unit test execution integrated into and tracked by the automated build process? •Do master/develop have no failing unit tests? •KPIs used to measure the progress (so far) •Test coverage •Number of tests

Slide 7

Slide 7 text

SonarQube •Does a weekly automated code analysis exist? (master or preferable develop) •KPIs used to measure the progress (so far) •lines of code •technical debts, technical debts per line of code •issues, issues per lines of code •Todo: Define ruleset (Same for IDE and SonarQube)

Slide 8

Slide 8 text

Automated deployment •Is the application deployed automatically? (develop/master at least once a week)

Slide 9

Slide 9 text

Automated integration tests •Does the project contain integration tests? •Is the integration test execution automated after deployment? •Do master/develop have no failing integration tests? •KPIs used to measure the progress (so far) •Number of tests

Slide 10

Slide 10 text

Upcoming: Code reviews •Are one (better two) code review pals defined? •Does a code review checklist exist? •KPIs used to measure the progress (so far) •Number of reviews

Slide 11

Slide 11 text

Summary •Think “kaizen”, not “kaikaku” •There should be a progress every review •Review should be at least every two month

Slide 12

Slide 12 text

Awesome Software Quality Talks •Code Reviews (http://bit.ly/296cEJy) •Coding Guidelines (http://bit.ly/29heBlZ) •Clean Code Developer (http://bit.ly/2948P5k) •Git (http://bit.ly/297DjVa) •GitVersion (http://bit.ly/297DjVa)

Slide 13

Slide 13 text

It is up to you!