Mobile development with less complexity, more confidence, and fewer manual steps - PowerPoint Presentation

Slide1

Mobile development with less complexity, more confidence, and fewer manual steps

Benjamin van der VeenPartner, Survant James@bvanderveenPNSQC, Oct 17-19 2016

SOFTWAREQUALITYCONFERENCE

PACIFIC NW

PNSQC

™Slide2

Background

Started doing mobile with the 1st-gen iPhone in 2008But before that…web development since 2000a lot of Flash and Windows desktop appslow-level, high-performance networking/IO experienceI can attest that mobile is really hard!Slide3

Mobile is hard

Harder than web apps and backend servicesLots of state and state transitionsEnd product has to look good and be correctThe practice is far less mature than web developmentAutomated testing?Automated deployment?Slide4

The climateLower barriers to entry

More engineers, more libraries, more choices, more dependencies, more problemsMore horsepower available on more devicesFewer engineering constraints, more problemsMore devices, more problemsMore designersMore problemsSlide5

The climate

Automated testing and deployment still uncommonSlide6

What to do?

Write, maintain, and run automated tests.Write, maintain, and run a manual test plan.Allow the platform to guide you known-good, low-complexity UX and UI solutions.Automate deployment as much as possible, and deploy frequently.Slide7

Automated testsWhat are you supposed to test in mobile apps?Slide8

Automated tests

Web app testingDatabase mutations (input)Database queries (output)Form/model validations (error cases)Smoke/integration/happy path tests (state transitions)Slide9

Automated tests

Mobile apps don’t often have…Forms Databases

Direct responsibility for querying structured dataSlide10

Automated tests

But they do have…Complex rendering logicHighly state-dependent user flows

Dependencies on system services (GPS, push notifications, calendar, contacts, etc)Slide11

Automated tests

DON’T: try to write automated tests around rendering or layoutVery hard to write automated tests for user interface behavior, e.g.:Text or images are laid out correctly in all casesWhen the user taps a button it turns a colorWhen X scrolls Y appears or disappears&cSlide12

Automated tests

DO: test logic that can be separated from the UICreate a ‘backend’ moduleEverything that can be decoupled from the UI goes inIt’s tested if and only if it’s in the backend module

Mock out system services (push, contacts, location, network, etc) and test forUser approves a permissionUser denies a permission

User has no contactsLocation can’t be found

No network

&cSlide13

Automated tests

State machinesModel the kinds of input events the app can receiveModel the kinds of output and side-effects the app can haveWrite a formal state machine around those models, and exercise it in an automated fashionSlide14

Automated tests

State machine exampleGiven the following input events:The app has startedThe “app has started before” flag not setAssert the following side-effects:The ‘first run’ screen is displayedThe “app has started before” flag is setSlide15

Automated tests: recapCreate a backend moduleEverything in the backend has an automated test

Everything with an automated test is in the backendAgnostic of UIMock out system servicesUse state machinesDon’t write automated tests for UISlide16

Manual testing

Test “everything else”!Layout and rendering codeText or images are laid out correctlyWhen the user taps a button it turns a different color

When X scrolls Y appears or disappears

etcOnboarding

Integration with e.g., web services

Meets real-world requirements e.g., location services

Adequate performanceSlide17

Manual testing

Keep the testing plan in your source repo along with the app and the automated testsUpdate it in step with the codebaseMake it part of code reviewSlide18

Manual testing

Ideally, run it exhaustively…On each feature branch before merge into masterOn master after a feature merge

Before releasesTry to strike a balance, because it can potentially get time consuming

Although if you keep your use-cases simple, maybe not…Use your judgement. Maybe…

just run relevant parts before merging

just run stuff you know changed since the previous releaseSlide19

RecapMobile is hardWrite, run, and maintain automated testsWrite, run, and maintain manual testsSlide20

Allow the platform to guide youOkay strap in, because we are about to go to 6 G’s.Slide21

Allow the platform to guide youMVP (minimum viable product):

“The simplest possible product that allows you to validate your market hypothesis and allows you to learn enough to iterate the product forward.” – Wikipedia (?)Slide22

Allow the platform to guide youUse the built-in controls and navigation paradigms the platform gave you!

Don’t fight them!Don’t try to improve upon them!Don’t innovate here!Slide23

Allow the platform to guide youDesigners can very easily violate this principle without knowing it.Slide24

Allow the platform to guide youExample #1:

The difference between a button and a button with a custom background and ‘depress’ states can be 1 minute and 1 line of code vs 4 person-hours and 20 lines of code. Slide25

Allow the platform to guide youExample #2:

On iOS, the difference between a “just-in-time” login screen that slides up from the bottom and back down when dismissed, and a “just-in-time” login screen that slides in the from right and out to the left…is that the former is trivial to implement and the latter is extremely awkward (maybe impossible) to implement.Slide26

Allow the platform to guide youThese are really subtle differences!Slide27

Allow the platform to guide youThe process that results in the design of the product must be aware of the constraints imposed by the manufacturing process.Slide28

Allow the platform to guide youWhat happens when the design goes to developer?Slide29

Allow the platform to guide you

Mode 1 (“Pitch it over the fence.”)Designer designs a feature.Developer spends (a perhaps unexpectedly long) time on the feature.

Developer may or may not achieve designer’s vision in that timeIf the vision is achieved:

Great! You got lucky.If the vision is not achieved:

Even more time is required (rinse, repeat), or—

Vision is abandoned

Time has been wasted? People frustrated? Trust frayed?

Deadlines or market opportunities missed?Slide30

Allow the platform to guide you

Mode 2 (“Collaboration between design and development”)The developer recognizes that, relative to a similar alternative, a given design decision…creates a large amount of code complexity

takes significantly more time to implementresults in code that’s difficult to maintain or change

If developer offers feedback to designerDesign is changed to reduce implementation complexity, savings achieved. (This is where we want to end up!)

If the developer does not offer feedback to the designer

See Mode 1 (“Pitch it over the fence”)Slide31

Allow the platform to guide you

Cultivate a feedback loop between design and development!Does the team have liberty (trust?) to just do the simple thing?Is team empowered (trusted?) to collaborate on reducing complexity?

Is the team incentivized to do so? Or are they billing hourly? ;)

Do design and development have open lines of communication?

a collaborative rapport?

shared product goals?

alignment on how time and money is best spent?Slide32

Allow the platform to guide you

It can get hairy!Live and die by MVPFocus on high-level user flows and business value

“Pixel perfect” is dangerous, expensive, and elusive“Flow perfect” is achievable, expedient, and extremely valuable

Design should never be a one way flow from designer to developer!Or we aren’t collaborating! Collaboration is essential for expedient, efficient, sustainable product developmentSlide33

RecapMobile is hardIt ain’t like web appsWrite automated tests where it makes senseUse a manual test plan for verifying visuals and integration with real-world services

Allow the platform to guide the team to expedient solutionsSlide34

INTERMISSIONSlide35

UI codeWhy is this so hard!?Slide36

UI code

It amounts to configuration. The only way to see if it’s correct is to see if it’s correct.Slide37

UI code

UI code rarely encodes logic in the usual sense of the wordSlide38

UI code

Expensive to modify — write once, read never!Slide39

UI codeBottom line: it’s hard to meaningfully test in an automated fashion.

Don’t innovate (too soon)Don’t fight The System (unless you’re well-funded and have political connections on the inside)Slide40

UI codeComponentize where possible

Work with design to create a reusable palette of widgetryAvoid new, ad-hoc design solutions on each new screenCollaborate and iterate!Slide41

UI codeGet designers and developers in the trench togetherGet flow-perfect, not pixel-perfectFocus on business valueSlide42

RecapMobile is hardTest what you can, visually inspect the restUI code is hard to reason aboutDon’t fight The System

Focus on biz valueSlide43

Deployment

Compare web apps — it’s all figured out!Mobile apps — not so muchCode signing :(TediousLots of manual stepsThe dreaded review processImpediment to deploymentSlide44

Deployment

Just script everything. Start banging on it.Building the appBuilding the tests

Running the testsBuilding a fully-baked, ready to deploy package

Code signingAsset generation

Icons

Screenshots

Use CI to exercise all of the above regularlySlide45

Deployment

Speaking of CI. Don’t outsource CI. There are a million also-ran CI-as-a-service startups out there and in our experience they are all:Slow

Finicky Break builds by changing their environments without warning

Are not appreciably different from each otherAre not appreciably different from running Jenkins or Hudson on a Mac Mini in your closet

Except that they periodically break for no apparent reason

…and anyway you probably don’t want your signing keys on hosted CISlide46

Deployment…which leads us to: write your own everything.

Own and maintain your toolsDon’t get tangled up with some huge graph of open source dependenciesYour needs are unique! Invest in your own ergonomics.Slide47

DeploymentAlways be in the App Store review queue

Lately, Apple’s turnaround times are 2-3 days (for us?)Iteration 0: submit a build to AppleIteration 1: make a few changes, cut a release, submit it as soon as Iteration 0 is approved.Iteration N: since you always have a good build in your CI pipeline, just submit iteration N every time iteration N-1 is approved by Apple.Slide48

Bottom line

Test coverage, automated and manualMinimal UI complexityLess code

reusable codeCollaboration and feedback between design and development, design is kept ‘in check’ by platform realities

AutomationBuild and automated testing

Deployment — build, signing, asset generation

CI — all paths tested frequentlySlide49

Results

Confidence!You minimized complexity where it hurts the most—UIAnd you’re running manual QA on that

For everything else, you’ve got automated testsAbility to emit builds at the drop of a hat

Internal/beta users can always play with the latestMinimal developer headache associated with creating a build

More predictable and stable release cadenceSlide50

The EndQuestions?