The document outlines the methodology and goals of testing in software development, emphasizing the importance of understanding different types of tests, best practices, and the balance between risk and testing capacity. It discusses various testing categories, such as unit, functional, integration, and user acceptance tests, and highlights the significance of test-driven development and continuous integration. The document also stresses the need for effective testing strategies to enhance product quality and align with agile methodologies.

1. Methodology
IT Test
the Goal:
• Understand the different types of Test
• Best & Worst practices of Test
• To check your product matches your customer’ expectation, test it!
• But Test is not coding. It’s seen as simple & boring
like Google,
• Improve your Test perception & practices
• Learn how Test might be a key lever to improve your business
Key reading: ‘How Google tests software’ James A. Whittaker

2. IT Test Training
the Goal:
• When you test an application, you’re proving it’s working
• Understand the basics
the key points: an introduction to Test for beginners. A list not exhaustive with
definition that can change from one firm to another.
Objectives
• Understand the different types of test and their respective goal
• Present a few Worst Practices & Best Practices to improve your own process
• Often you can’t test everything so Test is about taking Risk. What Risk are you ready to take?
For who?
• Non IT people
• Beginner in Test
Agenda:
The different categories of test
• Unit test
• Functional test
• Integration test
• (Non) regression test
• User Acceptance test (UAT)
• Production test
• Workload test
• Case study: where put continuous integration?
• Which data for testing?
What next?
• Test Driven Development, Continuous Integration, Architecture impact (API or micro services)
Content for each test type:
• Definition
• Where in the Release Cycle?
• Who?
• Which data?
• Where (environment)?
• Worst and Best Practices
• Key questions

3. UNIT Test
• First test done by the coder on basic functionality
• Check the development done matches the basic criteria of acceptance
the key points: Test Driven development, Quality First

4. Functional test
Check the functionality is fully matching the criteria of acceptance of the end user
the key points: first evidence the functionality developed is working

5. Integration test
• Several definitions (goals) possible
• One might be: rerun of the functional test to check the compatibility of the code updates when several
developers are coding at the same time on a software version
the key points: the goal of integration might also be to test the software in a wider and more realistic,
‘Prod like’ environment.

6. (non) regression test
• Rerun the functional tests to check nothing has been broken
• Regression test is about Risk: what is required to retest? What is not?
the key points: in theory all functional tests should become regression tests once setup into production.
In the reality, often people don’t have the time, budget, capacity to do all. So, what’s your strategy?

7. Focus on (non) regression test
• In theory, all new functionality in production should integrate the regression test.
• So the test plan will always grow. At one point, you’ll face a problem of feasibility (workload, time, cost)
the key points: to test is you often need other environment. So, test is closely related to DevOps practices
(automated deployment). Check you’re testing the right code. Code management is fundamental

8. User Acceptance Test
• Final step to check the user accepts the solution, the software
• The Customer’s ‘No Go/Go’ decision before setup in production
the key points: 80% of the functionalities should be validated before. The main goal of UAT is to get the
customer’s sign-off

9. Case study
Question
Where should we put continuous integration?
the key points: since the Kerviel affair, Dev team can’t write anymore on Production environment.
Only the Production team has this right.

10. Case study
Solution proposed
• Integration test: develop US1 and US2 in parallel to short the lead time
• Release vN is deployed in production
• Release vN+1 is in development
the key points: to be reactive (Agile), limit the dependencies when there might be many feedback loops.
Keep the integration in the hand of the coder to quickly iterate

11. Which data for testing?
• 100% production copy?
• Custom data?
• Pros and Cons
the key points: many strategies are possible. Keep in mind those strategies should help you to be
reactive & agile regarding your constraints. Otherwise, you have a problem

12. What’s next?
• Now, you understand the Value Added of the Test and also how complex it can be
• Test is one of the basement of the code factory as it implements the Quality First
• Read about TDD, Continuous Integration, Continuous Delivery, DevOps, Google practices
the key points: Test is key in the development process and is driving Quality, Code & Architecture at Google
Test Driven Development
• Test is so important there’s an Agile practice called ‘Test Driven Development’
• The goal is to Test as soon as possible instead of testing at the end of the process
• Why? Because when you test at the end, it’s more complex to test, analyze and more expensive
• Work with Proof Of Concept (POC), MVP, with ‘maquette’. Get feedback’s from End User on a storyboard,
on Graphical User Interface (GUI) designed on a sheet of paper, on a Minimum Viable Product (MVP) is a
form of ‘Test Driven Development’ principle
Continuous Integration
• Ideally we’d like to test everyday, every time there’s a change in the code
• To do so, you need to make it a ‘non event’. So, study automation solutions like AML, tools about DevOps
• Be careful. Automation is not magic. Test methodology is Key. Learn how to select test, which data to use
• DevOps’s scope is wider and closely related to Agile methodologies for developers
• It’s related to all tools facilitating the End of the development process and production management
• It embeds automated deployment, easy configuration, automated regression, production data analysis,
strong partnership Developer/IT Operation, …
Architecture impact (API or micro services)
• To understand the importance of the Test, you can read ‘How Google test software’
• You’ll learn that IT department at Google is around 1200 people worldwide
• It’s not called ‘Test department’ but ‘Productivity department’. Their role is to help developers test their code
• Software Test Engineer do Code review and can ask Developer to review the architecture to ease the test
• They also code part of the code factory coding test platform & tools to ease developer’s life
• Architecture tends toward API or micro services to facilitates Re-Use and Test automation

13. Methodology
IT Test
APPENDIX
the key points: understand when & who might do which test
• A theoretical Software development Release Cycle

14. Release Cycle (1/3)
when do we do what?
Overview of what can be a Software release cycle to understand:
• The goal of the test
• When, who & how this test can be done
the key points: this Release cycle is ideal

15. Release Cycle (2/3)
when do we do what?
Overview of what can be a Software release cycle to understand:
• The goal of the test
• When, who & how this test can be done
the key points: this Release cycle is ideal

16. Release Cycle (3/3)
when do we do what?
Overview of what can be a Software release cycle to understand:
• The goal of the test
• When, who & how this test can be done
the key points: this Release cycle is ideal