The document discusses the complexities and subjective nature of software quality, emphasizing the importance of team collaboration and proper metrics to define and assess quality. It highlights that quality can be influenced by factors such as project type, coding standards, and development environments, while also cautioning against the false security that certain metrics may provide. Ultimately, it stresses the need for a collective mindset towards quality within teams to ensure effective software delivery.

1. 1© 2019 Nagarro – All rights reserved
by Christina Hauk and Thomas Goldberger
Software Quality
without Testing

2. 2
The truth about Quality

3. 3
"We ensure quality
because we provide
automated tests."
often heard…

4. 4
often heard…
"It’s too expensive and
takes too much time
to write unit tests."​

5. 5
often heard…
"We’ve qualified testers who
verify that our software
behaves as expected."​

6. 6
often heard…
"It’s just a Proof of Concept but
we’d like to use ​it productive
as soon as possible"

7. 7
The Buzzword Quality

8. 8
#1
Quality Characteristics
What is Quality?

9. 9
Our Building Blocks for Quality

10. 10
Why is it so hard to define Quality?
Quality is subjective!
• People in IT are rather analytic
o How to measure?
o What to measure?
o Is it relevant if it isn’t measurable?
• Quality is often defined by client or end-user
o They “feel” if something is good
o They don’t measure
• Quality for stakeholder and end-user is:
o If it feels secure
o If it is beautiful
o Intuitive and working
o They don’t care about the implementation of a very complex algorithm
in five readable lines of code.

11. 11
We need metrics ...
… to define quality (objective quality)
• Metrics will give us the possibility to define
quality gates in a CI/CD pipeline
• We gain a better understanding for
software when using kpi’s like:
o Code-Coverage (Unit-Test)
o Path- Coverage (Unit-, Integration test)
o Story mapping (Ui-, Integration-, Unit-
test)
o Amount of defects/bugs found
o Mean time to recovery/repair (MTTR)
• False sense of security
• Metrics could deliver wrong picture of
software quality
o Number of tests vs. meaningful tests
o 80% Code-Coverage dosen‘t mean
that 80% of fuctions/methods are
properly tested.
Pro
Con

12. 12
Who is responsible for quality?
#2
Quality Assurance

13. 13
The Software Quality Hopper: The frame
Expectations and Ideas
Project Type Requirements The Team
Acceptance CriteriaInfrastructure Team Spirit
Tooling
Software Architecture
Coding Guidelines Clean Code & SOLID Principles
The Software
the frame

14. 14
The Team
The team enables software quality – not only the automation / quality engineer.
Quality depends on team work.

15. 15
The Requirements of the Software Project
"How to describe requirements?"
Ideas &
Expectations
Epics
User Story User Story
User Story User Story
Acceptance Criteria Acceptance Criteria
Acceptance CriteriaAcceptance Criteria
Tasks Tasks
Tasks Tasks
WHAT
HOW

16. 16
The Software Project Type
What do we engineer?
Evaluate an idea / business caseEvaluate an idea / business case
Proof of Concept (PoC)
Pilot
Prototype

17. 17
The Timeline of a Project Type
What do we engineer?

18. 18
The Quality Level of a Project Type
How to enable quality?
RequirementsLevel 1
Level 2
Level 3
Level 4
Level 5
Infrastructure
Manual Deployment
Code Quality Performance
Security Compliance
Level 6 Deployment via CI / CD Pipelines
Level 7 Automated Tests
PoC
Prototype
Pilot / MVP
Green Field ProjectRefactoring
Legacy Project

19. 19
Software is always testable, right?!
#3
Quality in Action

20. 20
The Software Quality Hopper: Action
Expectations and Ideas
Project Type Requirements The Team
Acceptance CriteriaInfrastructure Team Spirit
Tooling
Software Architecture
Coding Guidelines Clean Code & SOLID Principles
The Software

21. 21
The Tooling: Environment
• Develop in a 'nutshell'
• Environment must be
o Self-contained
o Free from external influences
o Controlled by the developer(s)
• Provide different development stages
• Recommendations:
o Use a local development environment (local
configuration = almost productive configuration)
o Use Container
o DevOps (not only tools, but also mindset)
o First (local) environment, second development
Development stages:
LOCAL
DEV
TEST
STAGING
PROD
on your local machine
on a server - private
on a server - private
on a server - private
on a server - public
developer
developers
automation engineer
operations
operations
last quality gate – productive like environment
DevOps

22. 22
The Tooling: CI / CD Pipelines

23. 23
Software Architecture
Following Levels should be considered:
• Environment level
o Microservices
o Build / orchestration environment
• Solution level
o Patterns (particularly abstractions)
o Project structure (feature-oriented vs. file-
type-oriented)
o Technology stack (e.g. frameworks)
• File level
o File structure (order of properties, pubic,
protected, private methods etc.)
o One method = one behavior
o Coding Guidelines
o Clean Code & SOLID
Web app
Backend
API
Database
environment level – e.g. kubernetes
solution level
file level
Elasticsearch

24. 24
Coding Guidelines
• Why?
o Raise and ensure readability
o Prevent misunderstandings and confusion
o Clear framework
• Coding Guidelines – most important
o Naming Conventions
(e.g. names of variables, methods/functions)
o Maximum lines of a file and maximum lines of
a method / function / class
• Recommendations:
o Define coding guidelines together in a team
o Use it together with linters
o Take a look at https://cssguidelin.es/#syntax-
and-formatting

25. 25
Clean Code & SOLID
• Read the book Clean Code by Rober C. Martin
• Read Blogs and involve yourself in discussions about Clean Code
• Live and breath Clean Code
• The same goes for SOLID
o Single Responsibility Principle
o Open – Close Principle
o Liskov substitution Principle
o Interface segregation Principle
o Dependency inversion Principle
• You will make your life easier if your code is maintainable and readable
• And last but not least …

26. 26
Clean Code & SOLID

27. 27
Always remember....
#4
The Message

28. 28
Always remember…
• Quality has numerous facets…
o …it is multilayered
o …has a subjective character
o …can be ensured in a performing team
• Quality needs…
o …a frame
o …practice
o …a mindset
• Never forget …
o …your code quality
o …your tooling and it’s setup
o …your team communication

29. 29Nagarro GmbH | Vienna / Austria | +43 1 409 58 90-0 | www.nagarro.com
Christina Hauk
@HaukChristina
@T_Goldberger
Thomas Goldberger

30. 30
Sources Images
• https://sonin.agency/the-4ps-innovation-model-poc-prototype-pilot-production/
• https://de.toonpool.com/cartoons/Controlled%20Quality_28355
• https://salopekconsulting.com/hr-metrics-measure/
• http://clipart-library.com/cartoon-teachers.html
• https://blog.callr.tech/gitlab-ansible-docker-ci-cd/
• https://nohat.cc/f/boy-giving-a-present-to-a-girl/4587236330831872-201809041452.html
• https://app.hedgeye.com/insights/37389-cartoon-of-the-day-pied-piper?type=cartoons
• https://unixtitan.net/explore/group-of-friends-having-fun-clipart/
• https://wavelength.asana.com/develop-effective-communication/
• http://teamsofv.blogspot.com/2013/11/winterpause-joggingzeit.html
• http://i.imgur.com/T0gOgrX.png
• https://images-na.ssl-images-amazon.com/images/I/515iEcDr1GL._SX385_BO1,204,203,200_.jpg