March 30, 2018 at 10:24QA in mobile game development or how to build a process in an indie company
Hello!
Today I will talk about creating a testing department using the example of a small company that has been releasing mobile games for 3 years. The peculiarity is that the company does not depend on sponsors and lives off the money that it makes. And it is important for us, as employees, to do what, in our opinion, users will like. There is an opportunity to experiment and work for an audience, but at the same time, there is much less time for product development.
The need for a QA department appeared a year ago, and I needed to build the testing process without breaking the release schedule.
QA in mobile development is a bit of a secret service. While it works well, no one notices that testing is being conducted. But once Akella misses at least once, comments on the game are full of messages of varying degrees of anger. In essence, the task of the mobile tester is to ensure that the application has a minimum of noticeable bugs, and the development teams clearly understand the meaning of each release and work to achieve the result.
Testing is a factor that helps to improve a product, but if it is used improperly, it will also be a load-bearing element in the system, greatly delaying the release. In our company, 2 working days are laid for testing the game: the first day - the product is tested and finalized; second day - the game passes the last checks and goes to the market.
The testing process faces the following problems:
Before I joined the company, testing was carried out within teams. Now this is a separate stage for which time needs to be laid. For a while, everything was done on the principle of "whoever passed it first will be tested." I did not want to transfer releases, because there was no understanding of the importance of each of them. The disadvantages of this format are frequent processing at the end of the week and lack of employment at the beginning of the week.
The first tool that was supposed to make the process uniform was the time schedule setting the test dates. This was done so that the workload became uniform. According to the plan, all releases that did not have time to come out before the weekend were to create employment at the beginning of next week. The restriction worked, but sometimes priority was confused and there were situations when games that could wait were released before more important releases.
We needed a visualization of the process and all the tasks that go into the test. We started a kanban board in Jira. Those who do not understand what it is, I advise you to read the book by David Anders “Kanban. An alternative way to Agile. ”
Once a week, on Mondays, we met with hemdesigners at a short rally, according to the results of which plans and priorities were set for a week. Projects coming in addition to the main plan were discussed separately and automatically went off the next week, or fell into the test only when a “window” appeared in my schedule.
The workload has become clearer and more transparent, but, alas, has not become more even. Kanban showed not only testing problems, but also general communication problems between departments and individual specialists. Plus, a new cause for concern has appeared: it has become forgotten how important it is to also talk with colleagues. There were situations in which everyone did their job well, but without looking at the others. As a result, one of the projects being supported and requiring urgent updates due to the fact that the analytics period was ending, was overdue for 3 days. Of course, these are monetary losses and lost information.
One of the main lessons learned from that situation, I formulate for myself as:
In addition to interaction, it remains for us to adjust the distribution of employment. The solution turned out to be simpler than it was originally seen - we added a rally on Wednesday evening. As a result, on Monday we set out priorities for a week, and on Wednesday we discuss the release schedule for Friday. Now, already in the middle of the week, everyone with almost absolute certainty knows what will happen, what won’t work out and everyone can leave home on time. Teams more specifically set internal deadlines.
It is much easier to put together one unplanned rally and spend 15 minutes than spend 3 days trying to comply with a process that, as a result, just not everyone interpreted correctly. The result is obtained only if all employees are aware that it is not enough to do their job well. Always think why this work is being done and help others do the same.
In the near future, we will introduce an updated testing system based on “self-testing with fakap”. The point is that teams can release their game bypassing the QA department if they prove the need for it. That is, they will clearly understand that a release is necessary, but, due to delay, it does not fall into the main testing grid. Under his own, of course, responsibility. There is a hypothesis that in this case we will be able to reduce the burden on the department and increase the overall labor discipline, because teams will more soberly assess their strengths, since doing extra work due to their own delay is not the most desirable case.
To create a productive department, you need, in addition to classical testing, to deal with what is rightly called "quality control". Make sure that games come out not just like that, but for a specific purpose. It will also not be superfluous to study the needs of the audience and business in a modern, dynamic market.
The lack of automation provides both limitations and opportunities. On the one hand, you need to check more elementary things yourself. But, on the other hand, much more time is left to explore additional aspects of the business. And there are a lot of tools that make testing more effective. Only “heuristics” or correctly composed “checklists” deserve a separate article. But you need to talk about this separately.
When building a department and its processes, it is important and necessary to remember and understand 2 things:
how to build a work process so that it does not infringe on the interests of other employees;
how to respond to process disruptions. The goal and result is much more important than their strict adherence.
Today I will talk about creating a testing department using the example of a small company that has been releasing mobile games for 3 years. The peculiarity is that the company does not depend on sponsors and lives off the money that it makes. And it is important for us, as employees, to do what, in our opinion, users will like. There is an opportunity to experiment and work for an audience, but at the same time, there is much less time for product development.
The need for a QA department appeared a year ago, and I needed to build the testing process without breaking the release schedule.
Testing in mobile game dev: what is and what is the problem
QA in mobile development is a bit of a secret service. While it works well, no one notices that testing is being conducted. But once Akella misses at least once, comments on the game are full of messages of varying degrees of anger. In essence, the task of the mobile tester is to ensure that the application has a minimum of noticeable bugs, and the development teams clearly understand the meaning of each release and work to achieve the result.
Testing is a factor that helps to improve a product, but if it is used improperly, it will also be a load-bearing element in the system, greatly delaying the release. In our company, 2 working days are laid for testing the game: the first day - the product is tested and finalized; second day - the game passes the last checks and goes to the market.
The testing process faces the following problems:
- No test automation
- Different approach to full testing and feature testing
- Dependence on other departments. Failure to meet deadlines from other employees affects congestion. Weeks overloaded with weeks alternate with weeks when there are no releases at all
- The need to learn how to find flaws in game design or UI. There are situations when the testing phase helps to abandon a futile game.
The process and the result. How to change everything, but not to break anything
Before I joined the company, testing was carried out within teams. Now this is a separate stage for which time needs to be laid. For a while, everything was done on the principle of "whoever passed it first will be tested." I did not want to transfer releases, because there was no understanding of the importance of each of them. The disadvantages of this format are frequent processing at the end of the week and lack of employment at the beginning of the week.
The first tool that was supposed to make the process uniform was the time schedule setting the test dates. This was done so that the workload became uniform. According to the plan, all releases that did not have time to come out before the weekend were to create employment at the beginning of next week. The restriction worked, but sometimes priority was confused and there were situations when games that could wait were released before more important releases.
We needed a visualization of the process and all the tasks that go into the test. We started a kanban board in Jira. Those who do not understand what it is, I advise you to read the book by David Anders “Kanban. An alternative way to Agile. ”
Once a week, on Mondays, we met with hemdesigners at a short rally, according to the results of which plans and priorities were set for a week. Projects coming in addition to the main plan were discussed separately and automatically went off the next week, or fell into the test only when a “window” appeared in my schedule.
The workload has become clearer and more transparent, but, alas, has not become more even. Kanban showed not only testing problems, but also general communication problems between departments and individual specialists. Plus, a new cause for concern has appeared: it has become forgotten how important it is to also talk with colleagues. There were situations in which everyone did their job well, but without looking at the others. As a result, one of the projects being supported and requiring urgent updates due to the fact that the analytics period was ending, was overdue for 3 days. Of course, these are monetary losses and lost information.
One of the main lessons learned from that situation, I formulate for myself as:
“Не требуй жёсткого выполнения гибких элементов процесса. Непонятно - спроси. Напомни, если нужно. Сначала польза и результат, а потом уже всё остальное”.In addition to interaction, it remains for us to adjust the distribution of employment. The solution turned out to be simpler than it was originally seen - we added a rally on Wednesday evening. As a result, on Monday we set out priorities for a week, and on Wednesday we discuss the release schedule for Friday. Now, already in the middle of the week, everyone with almost absolute certainty knows what will happen, what won’t work out and everyone can leave home on time. Teams more specifically set internal deadlines.
It is much easier to put together one unplanned rally and spend 15 minutes than spend 3 days trying to comply with a process that, as a result, just not everyone interpreted correctly. The result is obtained only if all employees are aware that it is not enough to do their job well. Always think why this work is being done and help others do the same.
In the near future, we will introduce an updated testing system based on “self-testing with fakap”. The point is that teams can release their game bypassing the QA department if they prove the need for it. That is, they will clearly understand that a release is necessary, but, due to delay, it does not fall into the main testing grid. Under his own, of course, responsibility. There is a hypothesis that in this case we will be able to reduce the burden on the department and increase the overall labor discipline, because teams will more soberly assess their strengths, since doing extra work due to their own delay is not the most desirable case.
Final farewell
To create a productive department, you need, in addition to classical testing, to deal with what is rightly called "quality control". Make sure that games come out not just like that, but for a specific purpose. It will also not be superfluous to study the needs of the audience and business in a modern, dynamic market.
The lack of automation provides both limitations and opportunities. On the one hand, you need to check more elementary things yourself. But, on the other hand, much more time is left to explore additional aspects of the business. And there are a lot of tools that make testing more effective. Only “heuristics” or correctly composed “checklists” deserve a separate article. But you need to talk about this separately.
When building a department and its processes, it is important and necessary to remember and understand 2 things:
how to build a work process so that it does not infringe on the interests of other employees;
how to respond to process disruptions. The goal and result is much more important than their strict adherence.