“Is your feature ready for QA” checklist

So you’ve finally finished a feature, cleaned up the code, opened a pull request…only to have a QA engineer come up to you with “Umm, have you tried this on whatever device here like tablet/old API/new API?”. Has this ever happened to you? It sure has with me and my colleagues and if you’re not a perfect developer (are there?) this might have happened to you too. So this inspired me to write a checklist that you should go through before opening a pull request. By the way, if you haven’t seen it yet, Github has introduced the draft pull requests now, so you can open one for review, but not merging. I think it’s a pretty cool and useful thing exactly for such case: when all together the feature and logic is final, but you just need to check those business things.

I’m writing from an Android developers perspective, but I think this can be easily translated to other fields like iOS/Web too.

The checklist

• This may seem obvious, but important nevertheless. Configuration changes: if you support portrait and landscape mode, make sure your new feature also supports it.
• Languages. This can be a pain if your app supports many languages, but it should work with short/long texts and special characters.
• API’s are great because of their evolution and mission to simplify developers life, but they can also be the reason for a lot of trouble since back compatibility should sometimes (a lot of times) be handled explicitly. Moreover, newer API’s are more concerned with security issues than their older brothers, so stuff that works on API 23 may not on API 28. And API 19. So make sure all of them get their piece of cake.
• A smart world it is. Tablets, TV’s, watches should never be left out if they're part of your app’s family. They too want the feature, and if they don’t, they should at least not break because of it.
• Next in line are screens with different densities. LDPI, XXHDPI, you know the drill. What looks good on one may not on the other and vice versa.
• Staging/production or any other flavours you have that support your new feature or bug fix.
• Same for your build configs, debug/release, check with your obfuscate etc.
• You should also run all of your lint/code formatting tools and fix the things they complain about.
• If you’re a good girl/boy, you write your unit tests and you don’t break the other unit tests and you should, of course, run them too.
• The best solution for the last couple of points is, obviously, CI, so if you have it configured (and you should have), then it will do the job of checking for you just in case you forgot.
• I guess that’s it from my side and if you have other points to add, I’ll be happy to do so. Happy merging!

I guess that’s it from my side and if you have other points to add, I’ll be happy to do so. Happy merging!

Receive a new Mobile development related stories first. — Hit that follow button

Twitter: @ChiliLabs

www.chililabs.lv