…and the other way around.
Not long ago I was involved in a mobile app project that had probably the best agile quality assurance practices I have experienced in any project so far. Not surprisingly, the overall product quality turned out really well, the customer was impressed and an independent review was full of praise. At this point I had my ‘Aha!’ experience. You can actually do these things in any agile project! And if small steps towards quality are taken early, better quality costs less. So, what have I learned?
Create your Definition of Ready and Definition of Done and keep them up to date. Even agile beginners know the why behind Definition of Done. But checking a story against criteria in your project’s Definition of Ready is equally useful before you start wasting time with stories that are simply not ready to be started.
Use version control and branching policy. This is certainly one thing that does not take much time to agree on and set up right from the start. Right? As a tester I can handle receiving a new build with the same name three times a day. But the customer or a 3rd party involved may not find it that straightforward, let alone professional. Therefore, delivering the daily/weekly/demo build with a nice and clear tag makes it easier for everyone, avoids confusion and can save some time figuring out which was the build that contained that fix.
Commit smartly and use explanatory commit messages. This is, thinking ahead, not about how often to commit but rather about what the entities are to represent a single commit. Is it the whole feature or rather a subfeature? How much code is too much to rewrite in case it fails? Is the commit short and clear enough for a reviewer? Is the commit message explanatory enough for a tester? Or yourself when you need to get back to the code later at some point? (Well, ignore this point if you like commits with hundreds of lines of code called ‘Update’.)
Be clear about environments and their purpose. Which backend is this pointing to? Is the bug fix already in staging or just development environment? From which environment branch should we create a build for the customer? Are we missing an environment or do we have any redundant ones? A great blog on the topic was written by Olli.
Have a CI server, preferably up and running. It might not seem necessary in a small and quick project, but you will be thankful for it later. Personally, I see the best advantage of CI is the fact, that the code is always in such state that builds can be created automatically and at any point. Which makes it a great time saver.
Practice code (peer) reviews. It takes only 2 developers in the project that know the same language and a few seconds to minutes per commit. Even if the review would not catch any mistakes, it can introduce suggestions to make the code cleaner, clearer or simpler. And you may even learn something new.
Create separate branches for features, bug fixes and refactoring. Do your code changes in a separate branch first and give it for code review and testing before pushing into the main branch. This way you gain more confidence about your code, verify that it really works and minimise the chances you will break the branch you want to keep in (almost) shippable state at all times.
Be clear on what you need to support and test it before the end user does. Support across variety of devices, platform versions, resolutions, display modes - that causes a lot of pain in many projects. There is almost never enough time and budget and resources to cover all in testing. And hardly ever is that even necessary. But at the same time you do not want to rely purely on simulator or luck. If you are creating an app that is supposed to work as well on a 2-year old platform version as on the newest one, it is probably worth testing on both. And perhaps something in between, too. Is there a device with a non-standard display or resolution? The most widely used one? Get them. Support for a platform version that is still in beta? Compared to a released platform it is still immature and therefore worth special focus. Decide what is a reasonable coverage for physical devices and simulate the others. Compare a lot - you will discover bugs you would otherwise omit.
Test by exploring. Forget test cases. Exploratory testing is cheaper and still the most efficient and effective way to find bugs. Actually most of the bugs I have ever found (and seen other people discovering) were not by executing the exact steps in a test case. They came out while testing creatively also what was not in the test case. Exploratory testers just never feel like they are done. And often you do not need to be an experienced testing specialist to do effective exploring. Just put yourself in the shoes of the end user and think of what you would do with the app. Then activate your creativity and find out what else you could do. And retain a critical mindset at all times. Instead of ‘wasting time’ with specifications and writing test cases you use it all for testing and discussing with the team.
Organise session-based testing. Especially for small projects with no dedicated QA person, occasional exploratory testing sessions bring a lot of value for little money. Just invite the team (and also some outsider people if possible) to a testing session. During an hour or two the participants will be end users, exploring the app and giving feedback. A systematic approach by assigning areas or features of the app as well as testing under various conditions (e.g. in different languages) will bring more results than random playing. It will also reduce overlaps where two people are wondering about the same stuff. And the whole thing does not take more than an hour or two of the participants’ time plus the moderator’s time for preparation, session itself and follow-up. Another positive side effects of a session-based testing may include getting opinions from people with different roles and interests as well as increased commitment of those involved in the project to make good quality choices.
In fact, the best quality apps are not necessarily a result of big project and thick budget. They are outcomes of projects with a smart approach to quality assurance in its broadest sense.