Software Quality without Testing
0 likes478 views
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.
Software Quality without Testing
- 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"
- 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
- 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