Article

snapshot-testing

Category: Expert stories

How to ensure the best collaboration between developer and tester

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.

Kamil Naja, front-end developer and emagineer

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?

Read also:
Seven mistakes every tester should avoid in QA

code illustration

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.

 

Communication and issue management

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.

computer-screen

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:

  • Exact path to where the error occurs, or a large screenshot also showing the URL path.
  • Information on whether it occurs only in this one place or if there is a risk that the component is broken in many places.
  • Steps to reproduce.

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.

Read also:
Painless bug tracking

 

  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.

Code

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.

Striving for collective success

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.

ndividuals 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?

supply-chain-security_body-image-2

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.

 

  It is also necessary to establish knowledge within the team that some errors have a very high priority and must be resolved as quickly as possible when they arise.

 

Collaboration in a project should not turn into competition. I have witnessed situations where a tester reported several tasks every day, and from the content, it was evident that they did not always understand how the application works. The programmers then rejected these reports, but among the rejected tasks were valuable insights. Eventually, the situation was resolved by project management.

 

To summarize

Effective collaboration between programmers and testers is easy to achieve, as long as each team member has the willingness to help and learn. This effectiveness naturally develops in teams where members work together for an extended period.

The most challenging situation arises when new people join the team and encounter the existing order of things. It is essential to ensure that when working with new team members, we:

  • Describe bugs more precisely.
  • Dedicate more time to new individuals when discussing new and ongoing functionalities.
  • Develop better quality standards in task execution.
  • Keep new team members informed about the reasons behind certain project decisions.

These guidelines are also worth implementing continuously within an already familiar and cohesive team to expedite task completion and provide greater value to the end client.

Team retrospectives can serve as a good platform for discussing improvements. It's valuable to adopt the assumption that nothing in the project is obvious and encourage asking questions and seeking support.

More from this author:
How to optimize your workflow as an IT specialist

Ready for your next challenge?

Get help with your CV and profile and be found for rewarding projects.

Register your profile

Blog

Explore our blog

Read more

left-arrow
right-arrow

Henrik Timm
Projects & Implementation
Succeed as a consultant

The project manager in the era of AI

The advent of artificial intelligence (AI) has sparked discussions across various industries about its potential impact on traditional roles and responsibilities. The field of project management is not exempt from these considerations, and as a project manager, it is only natural to ask yourself: How will AI affect my work? 
Project manager at a meeting with his team.
Projects & Implementation
Succeed as a consultant

Key considerations for aspiring project managers

This article serves as a guide to all aspiring project managers, discussing important considerations and essential skills needed to excel in this dynamic career.
Projects & Implementation
Succeed as a consultant

From risks to requirements: Project initiation from A to Z

As the first step in the project lifecycle, project initiation is critical in determining the ultimate success of a project. Learn the best practices and key considerations for successful project initiation.