Please log in to watch this conference skillscast.
In this talk Derek and Kirk will share with you how to test an app without a dedicated QA team, and this will be appealing to you if you're part of a smaller development shops where formal QA hasn’t been established.
This talk is meant to be a higher-level overview into general QA process; it is not meant to be a highly technical dive into automation tools and unit tests. A general list of topics Derek and Kirk plan to cover are listed below:
Thinking outside happy path
Thinking about every entrance into a view both within the app and from outside app (deeplinks versus in-app navigation)
Thinking about different use cases; ie: someone in the app for a LONG time versus someone who opens it for 30 seconds once a day
Thinking about which devices are supported; size classes, OS levels, screen resolutions, hardware capabilities, etc
Thinking about externalities; network conditions, power levels, server endpoints 404’ing, null (or unexpected) data
Data persistence, data mutation, data stabilities
Upgrade testing - different upgrade paths, Database migrations
Permissions (Mainly Android M +)
Repeated testing; ie: Verifying data race conditions aren’t an issue
Developing an appreciation for Ad-Hoc testing (ie: Before release always have a feeling like you are missing something and take an extra 15 minutes)
Developing a hatred for Ad-Hoc testing (non-rigorous testing)
Checklists, and why you should use them
YOU MAY ALSO LIKE:
Did You Test It?
Currently a QA Engineer at Possible Mobile and our focus is on mobile applications and new technology. I have been testing applications across many platforms for the past 7 years. I started in game testing and then moved over to Windows and Web testing. I have found my true passion in mobile testing over the last 3 years on both iOS and Android. I got into QA because I was tired of playing games and using software that was not flushed out or had obvious issues.
Currently a QA Engineer at Possible Mobile where our main focus is on delivering rock-solid apps to our clients. Formerly a server-side dev (C++ and, yes, Perl) I became frustrated at having a lack of Quality…. Quality Assurance; I did a career shift to try and save devs the same pain I used to experience. While not #rekting your code I can be found #rekting you at Mario Kart.