Error Prevention: Desk Check and Starting 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 analyst’s head, the details of the project are simple and understandable, but in practice they cannot always be adequately expressed as a user story.

Today we’ll talk about how you can prevent the occurrence of errors before or at the early stages of application development. For this, various techniques exist and are applied that help to identify a potential deficiency before it manifests itself.

Many of these tricks are described in Gojko Adzic’s new book, Fifty Quick Ideas To Improve Your Tests.". The most effective, from our point of view, turned out to be two approaches: holding a kick-off meeting and Desk Check (analysis of stories at the table).

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

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

Starting meeting

At this stage, a list of questions (consisting of several items) is considered, which must be answered before starting development. The questions may be of the following nature: is the analysis of the stories completed, and can development begin? What technical solutions should be given special attention during development? Is there enough visual information? 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 agree with the analyst (there is a misunderstanding).

That is why a pre-launch meeting is held so that the team talked and shared their thoughts. This allows you to take into account all the subtleties and important details; Each team member plays a role and has his own thoughts regarding the stories.

Ideally, the start meeting requires the presence of a business analyst, a QA engineer and developers, then they will all get acquainted with the developed functionality of the application. This will make the discussion more productive and useful.

Here is an example of our list of issues discussed at the kick-off meeting:

1. Is history analysis complete?
2. Has the story 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 understood?
5. Does the story depend on subsequent stories?
6. Is there a technical debt?
7. Is there a layout for the story?
8. Do you see error messages and other user feedback in the history?
9. Are clues and tags defined by history? Where is this reflected?
10. Does the team like the volume of the story?

A business analyst, a QA engineer, and a development team should participate in the development process for the same reasons that they should be present at the launch meeting. It is important to remember (especially for large stories) that you can carry out checks right 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 scope of the story, and if this happened, then most likely the analysis was not very accurate.

Desk check

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

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

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

1. Have enough tests been done?
2. Was the code checked by another development team?
3. Has the story been tested “manually”?
4. Does history affect anything else?
5. Have all customer requirements been considered?
6. Does the story need comments or adjustments?
7. Has all user capabilities 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 marks in the application?
11. Have grammar errors been checked?
12. Is the color scheme consistent with the rest of the application colors?

Someone may say (and will be right) that most defects and errors appear at this stage, since at this point the story is realized, and preliminary functional tests can be carried out. However, we recommend that you pay special attention to the kick-off meeting, since it is there that all disagreements that can lead to a 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 you can verify that all important steps have been taken into account during the development process.

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

---

Announcement:

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

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

---