Test automation

DORA Continuous testing

Get Started. It's Free
or sign up with your email address
Test automation by Mind Map: Test automation

1. Understand

1.1. Get EARLY feedback on software changes

1.1.1. aka find errors asap

1.2. by creating - curating

1.2.1. All type of tests

1.2.1.1. 1 - unit

1.2.1.2. 2 - integration

1.2.1.3. 3 system / e2e / acceptance

1.2.1.4. ...smoke, perf, accessibility , security, load, internationalization

1.2.2. automated

1.2.3. running as fast as possible, aka as frequently as possible "continuously"

1.2.3.1. small

1.2.3.2. medium

1.2.3.3. large

1.2.3.4. huge

1.2.4. Locally and in the CICD pipelines (lifecycle)

2. Measure

2.1. % of test writen by developpers

2.1.1. the higher the best

2.2. % of tests are automated and running in the pipeline

2.2.1. the higher the best

2.3. Nb bug found over time in

2.3.1. dev

2.3.1.1. the higher

2.3.2. qa

2.3.3. prod

2.3.3.1. the lower

2.4. Time to fix acceptance test failures

2.4.1. reducing trend

2.5. % automed test false positive

2.5.1. the lower the best

3. Pitfall

3.1. Developper not involved in authoring automated tests

3.2. leading to

3.2.1. Broken test suite

3.2.2. Code is hard to test

3.2.2.1. poor code testability

3.2.3. Test phase is a bottleneck

3.2.3.1. Manual testing does not scale

3.2.4. Manual test are less reliable

3.2.5. Cost too much

3.2.5.1. incl test documentation

3.2.6. Long time to get feedback

3.2.6.1. additional triage effort

3.2.6.2. Delay to implement required design changes

3.2.7. "throwing code over the wall"

4. Implement

4.1. Increase % automated tests

4.1.1. Expect dev to practice

4.1.1.1. Test your code

4.1.1.1.1. deliver code and test => TDD

4.1.1.1.2. avoid test doubles: mocking / stubbing / fakes

4.1.1.2. Test all behavious in yoursystem: logic. perf, accessibility , security, load, internationalization ...

4.1.1.3. Verify coverage

4.1.1.4. Hold other with high testing quality during code reviews

4.1.1.5. Help identify and develop integration / e2e larger test

4.1.1.5.1. focus on critical user journeys

4.1.1.6. Keep test suite healthy

4.1.1.6.1. Prune useless test

4.1.1.6.2. Reduce test execution time

4.1.1.6.3. keep what is

4.1.1.7. Ask for help

4.1.1.7.1. Group of advocate

4.1.1.7.2. Tech lead / team ...

4.1.2. Integrated in the software life cycle, e.g.

4.1.2.1. local - precomit

4.1.2.1.1. Lintering formating

4.1.2.1.2. dependencies update

4.1.2.1.3. unit tests

4.1.2.1.4. integration test

4.1.2.1.5. Static App Security Testing SATS

4.1.2.1.6. coverage control + time to run test ok

4.1.2.1.7. build ok

4.1.2.2. CICD pipeline

4.1.2.2.1. CI

4.1.2.2.2. CD

4.2. Run test faster

4.2.1. Prune useless tests

4.2.2. Seek for paralelization

4.2.2.1. e.g. Golang parallel tests

4.2.2.1.1. doc

4.2.2.1.2. example

4.2.2.2. avoid data test in DB

4.2.3. Use test caching to avoid unnecessary reapeats

4.2.3.1. e.g. Golang test cache

4.2.4. Group test run by length

4.2.4.1. fast / medium / large / huge

4.2.4.2. run at higher possible frequency

4.3. Improve remaining manual tests

4.3.1. What

4.3.1.1. Exploratory testing

4.3.1.1.1. Discover bugs that go udiscovered with structured testing

4.3.1.1.2. Everyone can participate

4.3.1.1.3. "trust your instincts"

4.3.1.1.4. Finding help to improve automated test

4.3.1.2. What is hard to automate

4.3.1.2.1. E.g. specific android device / specific screen resolution

4.3.1.3. Test requirering a human jugment

4.3.1.3.1. E.g. Accessibility tests

4.3.2. How

4.3.2.1. Proximity

4.3.2.1.1. Tester working alongside with developpers

4.3.2.1.2. Testers roles may not be a full time job