● What is meant by the Super-fast solution
What I understand by the "Super-fast solution", is the kind of problems fixing model where there 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 the cooperation: developer-tester, tester-developer is the 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 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 tester is located within the development team, the process of implementation and whole development process is set to its best. The tester located physically within the development team means a lot: developers are trying more to do their best, because they know that this person will give no chance to their 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 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 there a brand new error window was implemented into a product. Tester will check the error window message, and he will find that the link to external help service is not working. He will check the source of the page and notice something is wrong. The link is like:
<a href="" target="_blank">http://company.com/helpform/</a>
It is obvious that developer forgot insert the website address into the href attribute, so only blank page will be opened when the link is used. In the 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 will have some time, he will fix the issue, and then he will send it back to the tester for retesting of the fix.
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 tester will find the issue, he will almost immediately ask the developer for solution of the problem.
They will look at the problem togehter, because they share the same room. Developer will make very quick change, so the problem will be fixed right now. And while talking and working on the issue, tester will notice that in fact it will be also 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 rename the link from:"http://company.com/helpform" to "We Will Help You"? Doesn´t it sound good? Doesn´t it look good?" Developer agree. It is a good idea. He 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 problem nr.1. The psychology of difference between mindset of developer and tester could be a huge obstacle. Find a solution how to get over the developer vs. tester gap, may be a quite difficult challenge. But the knowing that a better working software is our goal, must be enough valuable argument. Understand that we all are members of the one team with the same goal is absolutely crucial. When developers and testers will understand this, there is no problem to find a great solution for all problems they may face in the future work together. Also, since this very approach represents a noticeable saving of reporting bureaucracy that developers and testers hate, it could be welcomed by both sides.
There are of course some other problems according to this kind of approach. One of them is, for example, when the nature of issue found is quite technologically difficult and complicated. Some bugs are ugly and very hard to trace, debug and fix. Many information must be involved. Detailed description of the scenario, environment details, log files, even video recordings etc. The problem may be connected among several product´s modules or parts. In such a situation this approach probably may not be used. But in fact, that is not a problem at all. When small, trivial and minor issues will be covered by the "Super-fast solution" described, there will be more time for the major and critical ones.
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 to manage such an approach? How to report these issues that were found and solved so also the management of the project is satisfied? Well, if needed, the evidence may be collected and written down by tester in some kind of a simple document, so the management of the project will be informed about all these issues solved during the sprint review. I do think that there will be no big problem according the management, because when the result of such an approach is better and more stable software in 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 implemented straight into the development team as "just another members". Many social bounds are created, new friendships, several attacks of a tunnel vision view of developers' perspective, all this mean a great risk for our required and expected objective and outstanding view. Yet, this is the risk we must survive considering to the chance to create a 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 in psychological aspects of the team cooperation if correctly implemented into the team development process. When immediate both-sided communication between testers and developers who share the same working place (physically and within the same team) is ensured, this will be a great benefit for the better quality of the product in a reasonable time.