Organization of convenient bug reports for browser browsers alfatesters

At the moment we are engaged in the development of a browser-based game and in sweat are preparing it for the nearest closed, open, alpha and beta tests. In this regard, it is necessary to create the most convenient system bugpot from the users. It should be borne in mind that despite repeated warnings of players that they are participants in the technical stage, their patience should not be tested. If you do not create any conditions for "improving the project", then everyone will simply spit on your difficulties and go to a thread of the released project, where you should know yourself - "play, love, pay."



It would seem that a conscious user can easily see the bug, open some kind of bugtracker open to the external one, correctly set a task there, etc. Theoretically, it can. Practically - see the ending of the last paragraph. By the way, this approach is often associated with the accumulation of the first negative to the project, because typing alpha testers also costs advertising money, the audience begins collecting, and it stumbles upon a product that they are asked to test, but they do not create the conditions for this - as a result, the cost increases advertising, general background around the project, etc.
But back to our sheep, i.e. bugs
')
What conditions?

• Browser project, strategy;
• Technologies - Flash + PHP;
• Internal bugtracker - Redmine.

What is needed

• Organize quick and casual bug reports by any player;
• The ability of the player to give a textual description of the bug;
• The ability of the player to attach a screen screen;
• The ability of the player to mark right on the screen what the player considers a visual manifestation of an error, or just to write three letters on the screen in red (of course, the word "BUG");
• The ability of the player to send with one click all the important information to the developers;
• The need for the developer to adequately place the task in Redmine and implement the main grouping of bugs by markers, and if possible, try to determine who specifically should send the bug (again, based on the marker);

How does it look from the player

The user is in the game and hopefully enjoying the gameplay. Then suddenly he notices a mistake. Well, let's say, the icon in the store "flew." It would seem a trifle and reach for what the thread of tricky reporting services to the player behind this is clearly laziness (“it doesn’t bother to play in general, and you probably know it developed”). To reduce the “laziness” threshold for a report, a user simply has to press F12. Then he will see the following picture directly on top of his current screen, no reboots and redeployment:


Pic.1

As is evident from the figure above, a tooltip appeared over the player’s city, indicating that the player is in bug report mode. Below is a minimalist form that allows you to enter a comment, select a marker color for notes and notes over the screen, cancel the action button and the "Send" button, which obviously sends the bug report to the negligent developers who allowed it.
Next, the player sees the completed error form opening on the adjacent tab:


Pic2

This is where the player’s concern about the report ends, he can close the tab and continue the game from where he left off.

How does the developer

Let's discuss a little implementation, and at the same time note how the final process is presented to the developer.
So:

• the client is completely “attached” to the server, i.e. checks in about 2400 places where the server sends what data, their correctness. If somewhere something does not agree, it generates an error. A simplified example of such a situation: after hiring a unit, 1000 gold had to remain, and 1001 remained;
• The error has a unique token consisting of the error code and the error location hash. Example: checking the validity of a response from a certain server method can check 100,500 methods, if this test is not passed, this is an error code, and another hash is assigned to it, which is unique to the data set on which the error occurred, thus each error in a particular place of the game has its own unique marker;
• if the client generates an error, or if the tester just sees the visual jamb in the game, it presses F12, and such a form appears as in Figure 1.
• when you click “send” in this form, the client creates an archive that contains: a screenshot (if there is a “graffiti” from the player - along with NMI), a file with a tester comment, an error log (if any), an error code ( if it was), the log of the varings (which could lead to an error)
• then this archive in the repository, where it is unpacked on the server and displayed to the user via an http-link in the form of a detailed and convenient error report, which can be seen in Figure 2.
• And finally, the most convenient: the server of this system creates a task in Redmine, tracking repeated tasks for the error marker, and assigns it to the project manager, assigning producer, as well as leading developers to the server and client to supervisors.
• The task will be linked to the player’s report.

It turns out the task in Readmine about the following plan:


Pic.3

If desired, or rather, if necessary, the system can be expanded and improved in several directions. For example, to introduce fairly objective (correct with 90% probability) criteria for direct sending a bug to an immediate lead, with the addition of PM and / or producer to the observers.

And that's enough?

... an inquisitive reader will ask. For convenient organization of collecting errors from users - yes. More than confident that over time the system will overgrow with buns, chips, expand functionally. If you increase the project team, you will probably have to enter selection criteria, as stated above.

Of course, do not forget about the correct logging. Often, the log attached to the error is much more useful than all the screenshots and notes from the user. This system, of course, must also be implemented at any stage of testing, and although the material is not about it, we will briefly state the theses:

• There is an in-game logging system, i.e. The game server writes every sneeze user in a special format (including errors) in text files. These logs are collected by the statistics server, where they can be viewed, grouped according to different signs (for example, the most frequent errors), see the way in which users arrive at an error by the sequence in the logs, etc.
• There is a system for receiving bugs from the client of the game (automaton) that simply informs the server that such and such an error occurred on the client, without logs, not through server services (which may hang), but through a separate script via an http request, this also gets into the game logs and server statistics.

Conclusion

The first checks on the convenience of the implemented system are already underway, players will report bugs, grouping helps to eliminate repeats, etc. As mentioned above, this approach is not unique, unique or universal. He is “some kind of working for us” - we share the reasons for its creation and an exemplary opinion about convenience. Of course, programmers will always have to dig in the logs on the statistics server, KMs search through forums for important reports, etc. But you can significantly simplify all this action for the players themselves. We hope that the reader will be able to benefit from the material and for their projects.