In this article, emagine’s front-end developer delves into the common challenge of bridging the gap between client feedback and task execution in software development. He discusses practical strategies to improve the collaborative process between programmers and testers, ensuring a smooth workflow and successful results.
In an ideal software development team, feedback from the client translates into excellent requirements. These requirements are then transformed into precisely described tasks that encompass everything necessary for the development and testing of the application.
Typically, a developer seeks details about the project from the business, analysts, graphic designers, and UX designers since a lot of knowledge may be scattered. Subsequently, a tester examines the solution and may not be certain why certain things work the way they do.
The same applies in the opposite direction – tester reports may contain all the information and pertain only to actual bugs, but more often than not, additional information needs to be gathered, variables need clarification, and explanations need to be provided.
Collaboration from the beginning of requirements development
There’s nothing wrong with this, as long as we strive to continually improve our collaboration. There are ways to enhance this process, and in this article, I attempt to list them.
From a programmer’s perspective, I observe the following pattern of behavior. Functionality is developed for several days/weeks without the presence of a tester, and then, upon its release, the tester poses the sacramental question to the programmer – How is it supposed to work?
This question arises from a lack of business knowledge about the functionality.
Collaboration on application development should proceed jointly. Testing should not be limited to testing only those things that the tester learned from the GUI creator. A good solution may be to show the tester early in the implementation what functionalities we will be working on and discuss the reasons behind them.
Understanding how the application works is easier when we already see the user interface than based on dry documentation. At an early stage, it is also easier to incorporate any feedback from the tester. The tester can also participate in meetings regarding the application’s operation, which take place at the beginning of the sprint.
It is also valuable to include communication regarding functionalities and decisions in Jira.
Requirements that are often repeated, or must be implemented consistently, should be documented in the form of non-functional requirements.
The topic can also be approached in the reverse way because the problem does not only concern testers. A programmer spends several days on functionality they do not fully understand because they did not participate in its creation. It would be valuable to then meet with the tester and discuss test cases that currently exist. The person with more experience with a given component should help the less experienced one start their work effectively.
Through collaboration from the very beginning, it is easier to develop a test plan, prepare test environments, and detect errors at an early stage of their occurrence.
According to Jim Rohn, communication is one of the most important soft skills you can possess and work on. It becomes even more critical when new team members join, often asking many questions and struggling to navigate new projects. Good communication saves time.
For example, a tester may receive several tasks for testing that they have never seen before and are unsure where they should be implemented. The same may apply to a programmer who has received corrections to make.
Now, if the team communicates improperly, such as only talking to each other in daily status meetings, it is certain that delays will occur in the project, or functionalities will be checked/executed in the wrong place. There is nothing worse than starting work with a sense of uncertainty about whether we are doing something where it is needed.
In my opinion, a symbol of such improper communication lies in inappropriate use of Jira – without a description, with a screenshot the size of a postage stamp, showing only some bug. It is much easier to work if the person reporting the issue creates a task that includes:
Clear and detailed communication, especially in tools like Jira, can significantly enhance the efficiency of the development process, reduce misunderstandings, and ensure that tasks are executed in the right context.
Good communication saves time.
Writing these details in each report may seem tedious at the moment, but from a time perspective, it brings value.
Imagine that as the person reporting an issue, you want to revisit a bug from six months ago. If errors are described accurately, it is much easier to infer what went wrong even from a historical perspective. It also makes it easier to understand why a particular decision contributing to a change was made. Ideally, a bug in the issue tracking system does not require additional explanations, and if they arise, they are provided on the spot.
The best means of communication is direct contact or video conversation. When we establish certain things or make decisions during such a meeting, let’s document them in Jira to avoid overlooking them later. Good communication leads to increased trust within the team, resulting in more efficient work.
Assigning bug elimination tasks to the appropriate person is crucial. In a large project, each programmer is only interested in completing their tasks (excluding immediate assistance to team members). Creating a task in Jira without assigning it to someone may lead to it not being completed (of course, until someone is assigned).
An even more confusing situation arises when a tester reports a bug that has already been reported by someone else. Therefore, before creating a bug alert, it’s worth checking whether a similar report already exists.
In a good team, decisions about the application’s operation should be made collaboratively. The same applies to resolving errors in the best possible way.
For example, the front-end team may encounter errors originating from the back-end, but the back-end is created by another team. In such a situation, a tester encountering a proverbial “500 error” in the console (an error returned from the back-end) should review whether the correct data is being sent to the back-end. If so, they should report the error in the appropriate layer.
A tester without technical knowledge or with a negative attitude may report every error to the GUI team (because that’s where they saw the error) without considering which layer it pertains to. Working with such a person can be very difficult, and it adds extra work to the other teams.
Solutions are constantly changing, improving, and adapting to the client's needs. It's important not to take it personally when a tester provides feedback.
It’s necessary to consider how not to add extra work to other team members. For instance, if it’s apparent that a screen containing a form is not visible because, for example, we do not fulfill a specific business role to see it, do not report 20 errors like “missing field A” and “missing field B.” A simple statement that the entire screen is not working is sufficient.
Programmers can also be criticized in this regard. Sometimes functionality may only work on certain environments and not on others (the famous “it works on my machine”), which should, of course, be checked by the appropriate person.
Individuals who can independently handle basic technical tasks are an excellent addition to the entire team. For example, after being informed that the code is ready for deployment, a tester can log in to Jenkins and upload the appropriate version to the environment they need without involving a programmer in an action that diverts them from their daily tasks.
Additionally, what if none of the programmers is currently available, and a tester cannot log in to basic CI tools to prepare their work?
Programmers often become attached to their work, believing that if they have spent a lot of time on a solution, it must be perfect. Unfortunately, in reality, solutions are constantly changing, improving, and adapting to the client’s needs. It’s important not to take it personally when a tester provides feedback. Let’s be open to feedback.
In many projects, task prioritization is a key factor. From my perspective, it’s worth addressing the resolution of earlier errors first, and then moving on to new functionalities. The entire team must be aware of what is important.
Front-end developer
