7 – Are you doing the scenarios with participation of everyone in the beginning of the project ? When everyone is understanding the same thing and you starts to worry about tests in the beginning of the project, you spend less time/money than write test cases after development. Pay attention in your flow.

8 – Be curious ! Ask !

9 – Everything should be automated ? Remember that the effort spent when you automate something can be less valuable than manual testing.

10 – How many steps are you using in the scenarios, try don’t use more than 4 or 5. Make it simple.

11 – Use page object model – Better structure

12 – Be clear and objective when write the steps

13 – The feature is your documentation for end users, testers, developers. Following one of the Scrum rules, you don’t need more than this in your documentation process. Less time spent, more clear than huge documents (Because it uses examples), keeps the documentation together with the test.

Hello everyone, automating tests for your mobile application is the best way to increase the effectiveness, efficiency and coverage of your software testing. The test automation for mobile has been considered a critical factor for big mobile app companies but for the small ones this is very expensive. Small companies want to grow fast so automation is too expensive for them.

Black box – For game tests you should know that you need focuses on the functional and overall playability aspects of the game. Examples: graphics, special effects, animations, colours.

White box – focuses on the architectural, integration and systemic aspects of mobile game. Examples: how third-party components, databases, social media/external entities, as well as graphics/game engines, audio play and so on are integrated in to your game.

It is typically recommended to build test scripts that know how game is progressing, what kinds of faulty states could there be, and also focus on image recognition. As many graphics cannot be recognized as control mechanism – buttons, menus, sliders etc. – image recognition will help to identify those that are meant for controlling (and not just as a graphical element).

Compatibility testing is all about making that game compatible across different devices. The typical misconception with compatibility testing is that it will be only done with the final version of the game. If compatibility testing is done during all development releases – regression tests– it can help to reveal incompatibility issues with any parts of the game, its third-party components or integrations with those actual devices that end-users use. This is very important to get the game working robust and well across all possible device variants – hardware and software. (But remember that will be impossible tests in each device and version of android)

Performance testing Many games are by default developed (and tested) on high-end devices, without any chance to get decent performance level on low-end devices. For this reason, try to understand what are the devices/versions of OS most used for your clients. This way you can focuses more in devices that your clients are using. For example, take a look at Gamebench. It can help game developers to understand those potential bottlenecks in performance, reveal unused potential with CPU and GPU resources, and help to push the boundaries of Android gaming and visuals, without forgetting the most important thing – a need to test the game on real devices. You should consider creating tests which last for hours to observe how well the game as well as how much of battery is used during long usage. To determine if you game will be able to run successfully for a sustained duration under heavy load, Load/Stress tests can be used. The performance tests will measure how responsive your game can be on a real device.

Localization testing becomes highly important when your game is targeted for the global markets. The word ‘global’ means your game needs to be ‘local’ for everyone. When your game titles, texts and content needs to be translated and tested with devices in multiple languages, these types of tests can be easily performed automatically (with help of cloud-based device access and test automation) to change the language of devices, and even do it again with the same test runs. The problems layouts can be easily picked from screenshots.

Load testing tests the limits of a system, such as the number of players on a server, the graphic content on the screen (e.g. frames per second, FPS), or memory consumption (allocation and deallocation of it). In this category you can count in multi-player testing as it can involve several different scenarios to be tested.

Multiplayer – A need to test multi-player abilities is there and is naturally more challenging and requires the other end to perform as a real counterpart. For example, typical case is that the game communicates with backend server. In these cases, connectivity is essential and the synchronization between backend and devices that need to get information about the gameplay.

Real occurring events on background – Interrupts, battery consumption, how charger effects to overall performance and usage. These all have significant impact on user experience – and good entertainment level.

**Don’t forget to test:

UI layouts and elements: All games are typically targeted for maximal set of different screen resolutions and different types of screens. Regression testing should be done each and every time when UI layout changes to ensure that game works.Menu structure and functions: Testing menu structured, functionality and correct behaviourScreen orientation: both landscape and portrait modesScreen resolution: There are lots of screen resolutions especially on Android and typically autoscale can help game developersSocial Integrations: In many games, it is essential to be able to share results across your ecosystem, friends or just for yourself.Security: identifying third-party code, its vulnerabilities, and license restrictions are very often neglected by game devs.

I summarised the most important and not duplicated parts. If you have any questions, just write below on the comments. Thank you 🙂

A page object is an object that represents a single screen (page) in your application. For mobile, “screen object” would possibly be a better word, but Page Object is an established term that we’ll stick with.

A page object should abstract a single screen in your application. It should expose methods to query the state and data of the screen as well as methods to take actions on the screen.

Example: “login screen” – basically consisting of username and password and a Login button could expose a method login(user,pass) method that would abstract the details of entering username, password, touching the “Login” button, as well as ‘transitioning’ to another page (after login).

A screen with a list of talks for a conference could expose a talks() method to return the visible talks and perhaps a details(talk) method to navigate to details for a particular talk.

The most benefit of this is abstraction and reuse. If you have several steps needing to navigate to details, the code for details(talk) is reused. Also, callers of this method need not worry about the details (e.g. query and touch) or navigating to this screen.

case result
when :invalid
self
else
site_page.await(timeout:10)
end
end

end

So, you can see that everything of login screen is inside the same class (login – android and other for ios) and you need use only one time. So you will avoid to repeat your code and it will be easier to maintain 🙂