QA 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 at the expense of the money it earns. And as employees, it is important for us to do what we think our users will like. There is an opportunity to experiment and work on the audience, but at the same time, there is much less time for product development.
The need for the QA department appeared a year ago and I needed to build the testing process without breaking the release schedule.
')
QA in mobile development is something of a secret service. While it works well, no one notices that testing is being conducted. But it is worth Akella at least once to miss and comments on the game are full of messages of varying degrees of anger. In essence, the task of a mobile tester is to ensure that the application has at least noticeable bugs, and the development teams clearly understand the meaning of each release and work towards achieving the result.
Testing is a factor that helps to improve the product, but, with illiterate use, it will also be a load element in the system, which strongly delays the release. In our company, the testing of the game lays 2 working days: the first day - the product is tested and refined; 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 inside teams. Now this is a separate stage on which to lay the time. For a while, everything was done according to the principle “who passed it before, that is what they test”. There was no wish to transfer the releases, because there was no understanding of the importance of each of them. The disadvantages of this format are in frequent reworkings at the end of the week and lack of employment at the beginning of it.
The first tool that was supposed to make the process uniform was the time limit on the testing dates. This was done in order to load became uniform. According to the plan, all releases that did not have time to go out before the weekend should have created employment at the beginning of the next week. The restriction worked, but sometimes priority was lost and there were situations when games that could wait would come out earlier than more important releases.
It was necessary to visualize the process and all the tasks that come in the test. We brought a kanban board in Jira. For 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 the design engineers at a short meeting, which resulted in plans and priorities for the week. Projects coming apart from the main plan were discussed separately and automatically left for the next week, or they got into the test only when a “window” appeared in my chart.
Workload became clearer and more transparent, but, alas, did not become more even. Kanban showed not only testing problems, but also common problems in communication between departments and individual specialists. Plus, there is a new cause for concern: 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 on support and requiring urgent updating due to the end of the analytics period was overdue by 3 days. It goes without saying that it is a monetary loss and missed 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 decision turned out to be simpler than it was originally thought - we added a rally on Wednesday evening. As a result, on Monday we scatter priorities for the week, and on Wednesday we are discussing the release schedule for Friday. Now, already in the middle of the week, everyone with almost one hundred percent certainty knows what will come out, what will not come out and everyone can go home on time. Teams specifically put the internal deadlines for work.
It is much easier to gather one unplanned rally and spend 15 minutes than to spend 3 days trying to observe a process that, as a result, simply did not correctly interpret everything. The result is obtained only if all employees are aware that it is not enough to do their job well. Always think about what this work is done for and help others do the same.
In the near future we plan to introduce an updated testing system based on “self-testing with a package”. The point is that teams will be able to release their game bypassing the QA department if they prove the need for it. That is, they will clearly understand that the release is necessary, but, due to the delay, does not fall into the main testing grid. Under his own responsibility, of course. There is a hypothesis that in this case we will be able to reduce the burden on the department and increase the general labor discipline, since the teams will be more sober in assessing their strength, because doing additional work because of their own delay is not the most desirable case.
To create a productive department, in addition to classical testing, it is also necessary to do what is rightfully called “quality control”. Make sure that the games come out for a reason, but for a specific purpose. Studying the needs of the audience and business will also not be superfluous in the conditions of a modern, dynamic market.
Lack of automation gives both limitations and opportunities. On the one hand, you need to check much more elementary things yourself. But, on the other hand, there is much more time to explore additional aspects of the business. And there are lots of tools that allow you to more effectively engage in testing. “Heuristics” alone or correctly compiled “checklists” deserve a separate article. But this need to talk separately.
When building a department and its processes, it is important and you need to remember and understand 2 things:
how to build a work process so that it does not infringe upon the interests of other employees;
how to respond to a violation of processes. The goal and the result is much more important than their strict observance.
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 at the expense of the money it earns. And as employees, it is important for us to do what we think our users will like. There is an opportunity to experiment and work on the audience, but at the same time, there is much less time for product development.
The need for the QA department appeared a year ago and I needed to build the testing process without breaking the release schedule.
')
Testing in mobile game development: what is and what is the problem
QA in mobile development is something of a secret service. While it works well, no one notices that testing is being conducted. But it is worth Akella at least once to miss and comments on the game are full of messages of varying degrees of anger. In essence, the task of a mobile tester is to ensure that the application has at least noticeable bugs, and the development teams clearly understand the meaning of each release and work towards achieving the result.
Testing is a factor that helps to improve the product, but, with illiterate use, it will also be a load element in the system, which strongly delays the release. In our company, the testing of the game lays 2 working days: the first day - the product is tested and refined; 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 testing features
- Dependence on other departments. Failure of deadlines from other employees affects the workload. Weeks overloaded with releases alternate with weeks when there are no releases at all
- The need to learn to find flaws in game design or UI. There are situations when the testing phase helps to abandon a hopeless game.
Process and result. How to change everything, but do not break anything
Before I joined the company, testing was carried out inside teams. Now this is a separate stage on which to lay the time. For a while, everything was done according to the principle “who passed it before, that is what they test”. There was no wish to transfer the releases, because there was no understanding of the importance of each of them. The disadvantages of this format are in frequent reworkings at the end of the week and lack of employment at the beginning of it.
The first tool that was supposed to make the process uniform was the time limit on the testing dates. This was done in order to load became uniform. According to the plan, all releases that did not have time to go out before the weekend should have created employment at the beginning of the next week. The restriction worked, but sometimes priority was lost and there were situations when games that could wait would come out earlier than more important releases.
It was necessary to visualize the process and all the tasks that come in the test. We brought a kanban board in Jira. For 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 the design engineers at a short meeting, which resulted in plans and priorities for the week. Projects coming apart from the main plan were discussed separately and automatically left for the next week, or they got into the test only when a “window” appeared in my chart.
Workload became clearer and more transparent, but, alas, did not become more even. Kanban showed not only testing problems, but also common problems in communication between departments and individual specialists. Plus, there is a new cause for concern: 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 on support and requiring urgent updating due to the end of the analytics period was overdue by 3 days. It goes without saying that it is a monetary loss and missed 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 decision turned out to be simpler than it was originally thought - we added a rally on Wednesday evening. As a result, on Monday we scatter priorities for the week, and on Wednesday we are discussing the release schedule for Friday. Now, already in the middle of the week, everyone with almost one hundred percent certainty knows what will come out, what will not come out and everyone can go home on time. Teams specifically put the internal deadlines for work.
It is much easier to gather one unplanned rally and spend 15 minutes than to spend 3 days trying to observe a process that, as a result, simply did not correctly interpret everything. The result is obtained only if all employees are aware that it is not enough to do their job well. Always think about what this work is done for and help others do the same.
In the near future we plan to introduce an updated testing system based on “self-testing with a package”. The point is that teams will be able to release their game bypassing the QA department if they prove the need for it. That is, they will clearly understand that the release is necessary, but, due to the delay, does not fall into the main testing grid. Under his own responsibility, of course. There is a hypothesis that in this case we will be able to reduce the burden on the department and increase the general labor discipline, since the teams will be more sober in assessing their strength, because doing additional work because of their own delay is not the most desirable case.
Final parting
To create a productive department, in addition to classical testing, it is also necessary to do what is rightfully called “quality control”. Make sure that the games come out for a reason, but for a specific purpose. Studying the needs of the audience and business will also not be superfluous in the conditions of a modern, dynamic market.
Lack of automation gives both limitations and opportunities. On the one hand, you need to check much more elementary things yourself. But, on the other hand, there is much more time to explore additional aspects of the business. And there are lots of tools that allow you to more effectively engage in testing. “Heuristics” alone or correctly compiled “checklists” deserve a separate article. But this need to talk separately.
When building a department and its processes, it is important and you need to remember and understand 2 things:
how to build a work process so that it does not infringe upon the interests of other employees;
how to respond to a violation of processes. The goal and the result is much more important than their strict observance.
Source: https://habr.com/ru/post/352410/
All Articles