The Pros and Cons of the Super-Fast Solution
The Pros and Cons of the Super-Fast Solution
A QA engineer discusses his idea for making a more collaborative environment between tester and devs, and how he envisions it working.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
What I Mean by 'Super-Fast Solution'
What I understand by the "Super-fast solution," is the kind of problems fixing model where a tester and a developer are located within the same team, within the same room, and, of course, within the same project, so the response is as fast as possible. In this model situation, the communication between the two is the best available, and cooperation (developer-tester, tester-developer) is at its most effective. And last but not least, the development process and the quality enhancement of the product is rapid, smooth, and progressive.
The Pros of the Solution
When the tester is located in the same room with the developer, the communication is quick and straightforward. Any solution can be explained and tested almost immediately after the implementation.
When the tester is located within the development team, the process of implementation and the whole development process is set to its best. Having tester physically located within the development team means a lot: developers are trying more to do their best because they know that this person will find any possible mistakes. And what's more, if they are not sure about anything concerning the product, they can ask the tester for his opinion. On the other side, the tester is well informed, he is a proactive and valuable member of the team, so there is also a kind of different view on the application's functionality and usability ensured in almost zero time. When the tester is well informed, there is a valuable lack of non-valid errors or pseudo-bugs reported, because our tester has a deep understanding of the product tested.
Simple Example of the Super-Fast Solution
Imagine a situation where a brand new error window was implemented into a product. A tester will check the error window message, and he will find that the link to the external help service is not working. He will check the source of the page and notice something is wrong. The link looks like:
<a href="" target="_blank">http://company.com/helpform</a>.
It is obvious that developer forgot to insert the website address into the
href attribute, so only a blank page will be opened when the link is used. In this common situation, the tester will create a bug within a management tracking system, and this bug will be assigned to a developer. When the developer has some time, they will fix the issue, and then send it back to the tester for retesting. The process will take some time - depending on the bug's priority - while the issue is fixed and the fix is verified.
On the other hand, in the situation of the "Super-fast solution" approach, when the tester finds the issue, they will almost immediately ask the developer for the solution to the problem. They will look at the problem together because they share the same room. The developer will make a very quick change, so the problem will be fixed right then. And while talking and working on the issue, the tester will notice that, in fact, it would also be great to change the description of the link. He will say to the developer: "Look. The referenced website name is 'We Will Help You,' so why not change the name of the link from 'http://company.com/helpform' to 'We Will Help You'? Does that sound good? Does it look good?" The developer agrees. It is a good idea. They will make another small change, and here we are: after five or ten minutes after the issue was discovered, the link is working, and it is also better looking:
<a href="http://company.com/helpform" target="_blank">We Will Help You</a>.
We just solved one bug and one (pro-marketing) improvement at once in just a few minutes. Lovely cooperation.
Cons of the Solution
People are always the number one problem. The psychological difference between the mindset of a developer and a tester could be a huge obstacle. Finding a solution to get over the developer vs. tester gap may be quite a difficult challenge. But the argument that creating better working software is our goal is a pretty valuable argument. Understanding and communicating that we all are members of the same team with the same goal is absolutely crucial. When developers and testers understand this, there is no problem in working together to find a great solution for all problems they may face in the future.
There are of course some other problems with this kind of approach. One of them is, for example, when the nature of the issue found is quite technologically difficult and complicated. Some bugs are pretty ugly and very hard to trace, debug, and fix. A lot of information is involved. A detailed description of the scenario, environment details, log files, even video recordings, etc. The problem may be connected to several product's modules or parts. In such a situation, this approach will probably not be used. But, in fact, that is not a problem at all. When small, trivial, and minor issues are covered by the "Super-fast solution" described, there will be more time for the major and critical issues.
Another potential problem of the approach may be found in the missing tracking data. When all these little problems are solved without any evidence in the management tracking system, how do you manage such an approach? How do you report these issues that were found and solved so that the management of the project is satisfied? Well, if needed, the evidence may be collected and written down by the tester in some kind of simple document, so management will be informed about all the issues solved during the Sprint review, for example. Tough, I don't think there will be any big problems for management because when the result of such an approach is better and more stable software at the end of an iteration, the missing report information is negligible.
We, as testers, are also facing the potential risk of losing objectivity and criticism when we are put straight into the development team as "just another member." Many social bonds are created, new friendships, et., and this mean a great risk to our required and expected objectivity. Yet, this is the risk we must take in order to create better software.
I believe that the solution presented in the article will help not just developers and testers, not just the quality of the development process, but will also bring some benefits to psychological aspects of team cooperation, if correctly implemented, into the team development process. When immediate communication between testers and developers is ensured, this will be a great benefit for the better quality of the product in a reasonable time.
Opinions expressed by DZone contributors are their own.