Did you ever wonder why some of mobile applications are becoming spectacular while the others are only good enough, some even plain bad? Of course the overall concept matters. The general idea has to answer a need, it has to be researched and documented during the market research phase. But what matter even more, is the very important first impression of the product, how it was designed and how user friendly it really is. There lays the most important part of what distinguishes a standard app from an awesome app. The quality (and part of the success) of an application can be evaluated by the above criteria through the “testing” phase (or Quality Assurance how we call it at Polidea). In our office, the testers team is taking part in every part of the app development process for an optimal and usable end-product. We will unveil here how the less known testing operations that are taking place during the app development a step at a time...
TESTING IN POLIDEA
Polidea operates as a big team, organically. If designers are the brain, developers are the muscles and testers, the senses. As testers, we are here to report when we find discrepancies between the core idea of a product and the final implementation of mobile apps, but also to participate in the development process itself. We, as test engineers, uphold the quality of every single elements crafted by the team to fully satisfy our partners needs.
It is very important for us to have a deep understanding of what the end-product should look like. We need to visualize fully the concept idea, the project goals and requirements. So we get involved in the project from day one, till the finish line and production release. For projects with parallel development on different platforms (Android & iOS etc..) we work on both operating systems at the time to spot easily the differences between user interfaces or functionalities. At first sight, nothing can appear dysfunctional, only a thorough comprehension of the ins and outs of a product enables us to visualize differences, that we can then signal to the developers or designers to correct.
As software development and design process are team sports, so is testing. Best teams are composed from individuals and their specific set of skills and abilities. But the whole is always greater than the sum of its parts. That's why in Polidea we practice several testing activities to spread and share our knowledge between our tester team. Once a week, all testers are meeting. The main purpose is to help us keep up with what is happening in each and every projects we are reviewing. And the second point is to share knowledge, tools, best practices and news from the testing world. Moreover, during our daily work we are doing pair testing sessions and testing code reviews.
The tech world around us is constantly evolving. Consequently, the whole testing know-how involved into solving new challenges become more and more complex. Each project is different and we have to fit to all clients needs. If a client prefers to work in a slightly different way than what we are used to, then we are always trying to adjust as much as possible. We are Agile. We strongly believe that the best practices emerge from this way of work in this dynamic environment - project related than strict testing process. It is not only about the methods that we implement but also about the frameworks and tools that we use.
THINK OUT OF THE BOX
Here in Polidea we, testers are checking the overall look and usability. We are not only focused on the functional parts of the product. Indeed, the user experience is the strongest factor that will determine if the app will be successful after its release to the market. We are checking all the possible paths and events that may occur. First part of our working process is to recreate the “happy” path - or when the flow that was described by the client is taking place. However, this is only the tip of the iceberg and when building mobile applications that are spread to large audiences, you will always find users manipulating the feature in irresponsible, pointless, or even impossible ways. That is why we also need to focus on all possible user's scenarios. Handling exceptions is key here. We have to secure all possible paths, provide exception errors and feedback for the end users.
Not only every single part of the system have to be properly tested but also in the end the overall implementation also need some attention. While performing integration tests we are checking all mobile platforms and backend at the same time. Manual tests are very good in terms of exploratory testing, finding edge cases while thinking out of the box, but the real powerful tool that we are using are test automations. While teams are growing and new features are delivered, the best process to find the regression bugs are automated scenarios. As We have already defined what is stable and what’s a desirable behavior we can easily check if new implementation has any influence on what was already delivered and accepted. This automation process will help us greatly to find the remaining edge cases.
TESTING LIKE AN END USER
In order to discover all those edge cases we need to put ourselves in the shoes of our end-users. This is our number one methodology to develop our understanding of a product and how to test it. In order to see with our users’ eyes we need to ask ourselves:
How will the application be used?
Who are our our end-users?
What are their needs?
What is the end user environment?
And finally why would they pick our client’s product more than a competitor’s one? Is it because it is unique and one of the kind or it is user friendly, stable and well tested?
Usually software development teams are testing application behavior with ideal network conditions such as broadband Wi-Fi. But in reality, ideal condition are not always met. At Polidea, we have developed in our office a cellular network simulator that recreates different problematic connecting situations which inform us how the application will handle eventual lack of Internet connection, full, over-limit, no In Traffic, 4G, 3G, 2G, Disabled, Fatality,etc... On top of this we also perform field testing to make sure our applications works as expected and meets user expectations in the real life.
This post summarizes the main concepts of Polidea’s testing philosophy. Next posts about testing will focus more on the technical aspect of our workflow, and tips to implement best testing practices. So stay tuned for more.
- Tomek MnichLead Test Engineer
- Sławomir AndrianTest Engineer