The development process consists of a sequence of milestones. Each milestone ends with the release of a version of the application that supports the planned functionality. The last milestone of the development phase ends with the release of the alpha version.
The alpha version refers to an application that can be used, although it contains bugs.
Milestone
During each milestone , the following works are performed:
Work planning
takes from 2 man-days to 1 man-week
is carried out by the lead programmer
sometimes it requires intensive discussion with the Customer of individual requirements
Development (takes 4-5 weeks)
Bug fixing (takes 1 week)
Tasks
During the planning of the milestone, the work that needs to be done by the end of the milestone is divided into tasks. Tasks are evaluated, and the tasks themselves are entered into the task control system. We use JIRA as such a system, but it does not make a significant difference. Instead, you can use any other task control system: from the free Redmine to the expensive DevTrack.
All tasks can be conditionally divided into two categories, each of which reflects a certain view of the planned work. In our case it is:
Custom tasks
Technical tasks
Custom tasks
User tasks are determined by the final result to be achieved. This result is clearly visible to the end user, and therefore user tasks are easily verified by a QA engineer: the result is either there or it is not.
Examples of such tasks:
Create a drop-down panel for texture selection
Add a color selection form
However, along with the advantages, user tasks also have disadvantages: they are difficult to evaluate, they may have cyclic dependencies (for example, to complete task B, you must first complete task A, and to complete task A, in turn, you must complete task B).
User tasks can be divided into two categories:
Tasks that characterize some observable part of the program, for example, a separate window, a complex control, or some service function (for example, exporting a document to a specific format).
Tasks that set criteria for completing tasks from the first category.
Tasks-criteria are a kind of checklist items. A QA engineer can go through it, conditionally tick the boxes (if the items are fulfilled) and close the parent task if all the “ticks” are put down.
Note: It should be noted that the criteria tasks are designed as subtasks for the tasks of the first category.
There are 3 types of criteria:
Criteria that describe the composition of a component (a separate form, a separate control)
When formulating such criteria, you should ask yourself questions:
What does the component consist of?
What elements does it include?
Criteria that characterize the key visual characteristics of the component
When formulating such criteria, questions should be asked:
- What color is the background of the component?
- What color is the text?
- What font is used?
Note: It is not necessary to list all the visual characteristics to the smallest detail. It’s too time-consuming and unnecessary. Attention should be paid only to key characteristics or only to those characteristics that differ from the standard ones.
The purpose of the criteria formulation is not to create a detailed description of the component in the smallest details, but to draw the attention of the QA engineer so that he does not forget to check certain characteristics before “closing” the task.
example. If the background color, text color and font of the window does not differ from the standard ones, then all these checks can be formulated as a single task:
Check that the background color, text color, typeface and font size match the manual.
Criteria that describe behavior
When formulating such criteria, questions should be asked:
- What does the element do?
- How will it react to a certain user impact?
- What should the user do to make the element behave in a certain way?
- Does the behavior of an element depend on time?
- Can the user cancel this or that action?
examples:
As a user, I can control the grid display by clicking on the Grid button
Make sure that the list can be expanded or collapsed by clicking the arrow on the left side of the header
Reports in software development
Another advantage of public reports is that the work of each team member is in plain sight. It is impossible to hide the lack of results. This is an additional stimulating factor both for the person who failed to advance on his task, and for the team: someone can give a hint or offer to take part of the work on the task on themselves.
After the reports, it is the turn of discussions. If there are any problems, they are briefly discussed and approaches to their solution are developed.
The practice of our team has confirmed the high usefulness of such meetings. And in order for the benefits to continue in the future, it is important that meetings do not escalate into lengthy and fruitless discussions of all existing problems.
“Discussion” in the communicator program
Before starting work on the project, we also create a “discussion” in the communicator program. Our company uses slack for this purpose. But you can also use other programs such as HipChat, skype, etc.
Such a “discussion” (“conversation”, “group” or “conference”) allows you to connect a team with people who work on a project remotely, for example, with internal Customers who may be in another office or even in another country, or with some remote employees.
In our company, the “discussion” in the communicator is actively used by both developers and Customers. Developers use it to ask short questions to Customers and to inform them about new features of the released version of the application. Customers leave their feedback in the “discussion” and requests to fix any critical bug if it needs to be done urgently.