Effective Testing Strategy in Android

Slide 1

Slide 1 text

Effective Testing Strategy in Android Natan Ximenes at Chicago Roboto - September, 2021.

Slide 2

Slide 2 text

// Natan Ximenes Senior software engineer, Android at WE ARE HIRING -> league.com/us/careers/ - Rio de Janeiro, Brazil.🌴 - Living and surviving in Android world over the last 6 years. 🤖 - Passionate about Digital Products, Agile and Testing. 󰡷 - Big fan of (brazilian)Football, NBA, e-sports, Marvel and Star Wars 🏃 @natanximenesdev github.com/Senemix29 [email protected]

Slide 3

Slide 3 text

Strategy

Slide 4

Slide 4 text

"Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. " (Sun Tzu, 500 b.c)

Slide 5

Slide 5 text

"It's the art of planning the best way to gain an advantage or achieve success." (Collins Dictionary)

Slide 6

Slide 6 text

Strategy is about.. planning the best, with the resources we have, to achieve a goal.

Slide 7

Slide 7 text

Testing Strategy

Slide 8

Slide 8 text

untested software shouldn’t be delivered to production...

Slide 9

Slide 9 text

...otherwise, the users might become the testers

Slide 10

Slide 10 text

...otherwise, the users might become the testers So... Testing is really important!

Slide 11

Slide 11 text

Testing Strategy A good strategy can help us to test properly an application, when we plan: // what to test… // how to test it... // without personal bias inﬂuence... // focused on software speciﬁcities... // possible points of failure...

Slide 12

Slide 12 text

What to test

Slide 13

Slide 13 text

What to test It can be any component of an application: // Function // Class // Layer // Screen

Slide 14

Slide 14 text

How to test it

Slide 15

Slide 15 text

How to Test It’s a combination between: // Testing types(Unit, Integration, UI, ...) // Testing tools (JUnit, Roboletric, Espresso, Assertion Libraries,...) Depending on the application architecture and design.

Slide 16

Slide 16 text

Bias-independent decisions

Slide 17

Slide 17 text

Bias-independent decisions Deﬁning what and how to test something should be: // Impersonal ⛔“Who did code it?” ✅“What does this code do?” // Based on facts, not on personal tastes ⛔ “I prefer Unit Tests” ⛔ “I prefer Integrated Tests” ✅ “Which testing types and testing tools would apply for our application at the moment?”

Slide 18

Slide 18 text

Quality can't be taken for granted, it needs to be ensured!

Slide 19

Slide 19 text

Bias-independent decisions should be documented Documentation should be a team agreement, containing guidelines about: // Naming // Style(BDD, TDD) // Which tools to use // Which testing types and how to apply it …it must be updated frequently!

Slide 20

Slide 20 text

Software Speciﬁcities

Slide 21

Slide 21 text

Software Speciﬁcities Things that might directly impact the tests:

Slide 22

Slide 22 text

Software Speciﬁcities Things that might directly impact the tests: // Frameworks(View-based, Compose, Epoxy, ...) // Concurrency(Coroutines, RxJava, Flows, AsyncTask, ...) // Architecture(MVC, MVP, MVVM, MVI) // Dependency Injection(Koin, Dagger/Hilt)

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Software Speciﬁcities Only adopt a framework or library when it’s conﬁguration for testing is known and well documented.

Slide 25

Slide 25 text

Points of Failure

Slide 26

Slide 26 text

Points of Failure // in the App // outside the App

Slide 27

Slide 27 text

Points of Failure in the App Examples: // Side effects in the core of the app // Crashes

Slide 28

Slide 28 text

Points of Failure in the App - What to do? // Smoke Tests at the CI

Slide 29

Slide 29 text

Points of Failure in the App - What to do? // Smoke Tests at the CI // Crash reports

Slide 30

Slide 30 text

Points of Failure in the App - What to do? // Smoke Tests at the CI // Crash reports // Feature Flags

Slide 31

Slide 31 text

Points of Failure in the App - What to do? // Smoke Tests at the CI // Crash reports // Feature Flags // Phased releases

Slide 32

Slide 32 text

Points of Failure outside the App Examples: // Internal backend failures // External services/SDKs failures // Unstable mobile network Sometimes, even automated tests won’t be enough

Slide 33

Slide 33 text

Points of Failure outside the app - What to do? // Expect external/internal services might fail // Provide enough user feedback // Incident postmortems

Slide 34

Slide 34 text

Testing Pyramid… is it a Testing Strategy?

Slide 35

Slide 35 text

Testing Pyramid... It’s an ideal testing types geometric distribution: 10% UI Testing 20% Integration Testing 70% Unit Testing // It’s a trade off, between Execution time, Fidelity, Maintenance and Debugging

Slide 36

Slide 36 text

Testing Pyramid - it’s not a strategy // ignores different testing types/approaches // ignores speciﬁcities // ignores points of failure // it doesn’t always apply

Slide 37

Slide 37 text

Testing Pyramid - isn’t the only one // Testing Trophy - by Kent C. Dodds

Slide 38

Slide 38 text

Testing Pyramid - isn’t the only one // The Bug Filter - by Noah Sussman

Slide 39

Slide 39 text

Testing Distribution - it’s about adding value Plan your strategy and follow what’s best, thinking about: // Execution time // Fidelity // Maintenance // Debugging

Slide 40

Slide 40 text

TL;DR

Slide 41

Slide 41 text

TL;DR // Testing is important… but it needs to be well structured // It’s not about you, it’s about the application // Testing isn’t enough... // Testing Pyramid it’s not a testing strategy

Slide 42

Slide 42 text

Further reading // Medium Blog: https://natanximenes.medium.com/ // References: https://cutt.ly/testing-strategy-talk-references

Slide 43

Slide 43 text

THANK YOU! Effective Testing Strategy in Android Natan Ximenes at Chicago Roboto - September, 2021. @natanximenesdev github.com/Senemix29 [email protected] linkedin.com/in/natan-ximenes29/