Error Prevention: Desk Check and Startup Meeting

When working on user stories, it’s very easy to make a mistake. If you do not identify an error before the start of development, the desired result can not be obtained at all. In the head of the analyst, the details of the project are simple and clear, but in practice they cannot always be adequately expressed in the form of a user story.

Today we will talk about how you can prevent the appearance of errors even before the start or in the early stages of application development. To do this, there are and apply a variety of techniques that help identify a potential flaw before it manifests itself.
')
Many of these techniques are described in the new book “ Fifty Quick Ideas To Improve Your Tests ” by Gojko Adzic. The most effective, from our point of view, were two approaches: holding a kick-off meeting and Desk Check (analysis of stories at the table).

The analyzed stories are better reviewed once again, so a team meeting where an analyst (or another team member with an idea of ​​the project) will present the intended stories, describe their value, origin and tell why they are needed is a good idea.

This will give the team an opportunity to discuss technical aspects and ask questions in order to clarify some requirements and assess the size of the story. All comments and comments received during the meeting can be taken into account in order to divide the story into several parts or, conversely, add more details and examples to it, that is, clarify the points that caused difficulties.

Starting meeting

At this stage, a list of questions (consisting of several points) is considered that must be answered before starting development. Questions may be of the following nature: is the analysis of the stories completed, and can development be started? What technical solutions should be given special attention during development? Is there enough information on visual design? What to do with error messages and tips?

Often there is such a problem when the developer does not share his ideas and does not coordinate them with the analyst (there is a misunderstanding).

That is why a pre-start meeting is held so that the team can communicate and share their thoughts. This allows you to consider all the details and important details; Each team member plays a role and has their own historical considerations.

Ideally, the presence of a business analyst, a QA engineer and developers is necessary at the starting meeting, then they will all become familiar with the application's functionalities being developed. This will make the discussion more productive and useful.

Here is an example of our list of issues discussed at the starting meeting:

1. Is history analysis complete?
2. Has the history been analyzed by a QA engineer?
3. Are all the details of the story taken into account, and is all the information correct?
4. Is the value of the story clear?
5. Does the story depend on subsequent stories?
6. Is there technical debt?
7. Is there a layout for the story?
8. Are error messages and other user feedback reflected in the history?
9. Are hints and tags identified by history? Where is it reflected?
10. Does the team suit the amount of history?

The business analyst, QA engineer, and development team must participate in the development process for the same reasons that they must attend the launch meeting. It is important to remember (especially for large stories) that it is possible to carry out checks directly in the course of development in order to make sure that everything is going according to plan. Try to ensure that the comments of the team do not go beyond the story, and if this happened, then most likely the analysis was not conducted very carefully.

Desk check

This type of analysis is carried out only when the development team is confident that development is complete. The list below presents the following questions: Has acceptance testing been carried out? Has unit testing been carried out? Have you invited anyone to check your code? Has the product been tested in all (popular) browsers?

These things are important, and they help to avoid problems in the future. For example, one or another application functionality will work fine in Chrome, but it will appear in Internet Explorer with errors, because the latter does not support the libraries you use.

Participants: business analyst, developers, customers (interested parties).

1. Have there been enough tests?
2. Is the code checked by another development team?
3. Has the story been tested "manually"?
4. Does the story affect anything else?
5. Have all customer requirements been taken into account?
6. Does the story need comments or corrections?
7. Has the user experience been tested?
8. Is the user interface consistent with the application?
9. Does the application work in all major browsers?
10. Is the text of the story consistent with all the inscriptions and labels in the application?
11. Did you check for grammatical errors?
12. Is the color solution consistent with the rest of the application colors?

Someone may say (and will be right) that the majority of defects and errors manifest themselves at this stage, since at this point history is realized, and preliminary functional tests can be carried out. However, we recommend paying special attention to the starting meeting, because it is there that all the differences that can lead to the result, far from ideal, become apparent.

Please note that the above are only examples of questions, and you should not take them as a reference. The benefit of this approach is that it can be verified that all important steps have been taken into account in the design process.

Another thing to remember is that all these lists must be personalized, since each project has its own characteristics and goals. Try to create your own and see what effect they have on the quality of development. Turn it into a habit, and it will grow into a skill.

---

Announcement:

September 16, 2015 (Wednesday) at 18:30 in the Accelerator of FRIA will be held a workshop with the ex-leader of mobile and desktop products LinguaLeo, the founder of AppCraft and the guru of metrics - Ilya Krasinsky.

Theme: “Grocery analytics: how to draw the right conclusions and focus on multiple growth points”. Registration is free.

---