Driving software tester Gojko Adzic

One of my resources for learning software testing craft is my Twitter list testingLearn. I recommend all testing professionals form that list because they all know a lot about software testing. My humble goal is to meet in person and talk about software testing with all members from that list. This week, I got an unexpected opportunity to meet Gojko Adzic. Ericsson Nikola Tesla, the company I work for, organised Agile Day. I am very satisfied that my company took the initiative to be one of the Croatian Agile spokesman. Gojko held keynote named 'Specification by Example'. The topic is well explained in his book that I am currently reading, 'Specification by Example'. Unfortunately, it was in house event, so I could not invite any of my Zagreb STC fellow testers. I contacted Gojko one month before event if he will be available for attending Zagreb STC #7 meetup, but because of his busy schedule, he had to leave immediately after his keynote. I informed my fellow tester, Zeljko Filipin that Gojko is in the house, and because he is a software tester, he gave simple but brilliant idea that I should offer Gojko free ride to the airport (because he knows that great software testers, like James Bach and Michael Bolton, will accept something similar). Well, it was not actually for free, because Gojko gave me 30 minutes free consultancy about testers position in software development process pipeline, which is far more valuable than a ride to the airport. Gojko accepted the offer, and I am very grateful for that.
Here is my first testing interview.

Karlo: I received feedback from my colleagues about your statement that developers are supposed to do automated testing. Could you elaborate more on that?

Gojko: I see that big companies want to optimization only part of their software development process pipeline. And often, they do not do that with the bottlenecks in their process. Problem with 'big' companies is that it is hard for them to see whole software development process pipeline. If process bottleneck are testers, and If they only optimize development process by introducing test driven development (TDD), and developers become very good at that craft, this could produce even greater problem for whole process pipeline. Developers will start to produce faster software that is ready for testers, and this will produce even greater pipeline bottleneck.
We should optimize bottleneck part of process pipeline. Only in that way we will be able to provide better software in shorter cycles. If analysis part is bottleneck we should optimize that part of the process pipeline. Problem with tester is that they often take to much responsibilities. Testers are not responsible for automated tests. Testers should tell developers what they should test using automated tests. Because developers are good at that. When development is finished? When all test that were specified by testers are automated and green! What added value testers bring to software development pipeline? Not to automatize, because developers are better for that task, but to critically think about the product and discover how to test the product (The little test book on test design is recommended by the blog post author) and from a number of test cases to decide what should be tested first (priority).

Who is the most important person that will drive implementation of specification by example in some company?

Every company is sum of a number of smaller companies. Sell it to real product owner, and that is person who has the money.

When I write test plan, I sometimes do not put immediately everything what should be tested in test plan. For example, we should test web application on Chrome, Firefox and Chrome.

Agile brings team responsibility concept. Google introduced 'Attribute components capability metrics'. You can implement that idea using simple online spread sheet and start things in movement. When you have your first capabilities and their attributes, put 
priorities on them and start testing!

Karlo: In your keynote you mentioned that there is no such thing as nonfunctional requirements. All requirements are functional. That statement also generated a lot of disturbance in developers filed at my company department.

UX (usability) is the only non functional test. Scalability, performance, security, they all have function. But, it does not matter how we call it! Give me REAL EXAMPLE for those capabilities, which means what product owner wants, and developers must implement it, and testers must test it. 'None functional' requirements usually do not have discrete values. You have to test interval values. Quper model is very good at communicating those interval values. This is how product owner can communicate what he wants to be implemented.

Karlo: Tell us little bit about yourself.

My first computer was Commodore 64, and I was the only child in the neighborhood that did not own cassette player or disk drive for it, which automatically led to fact that I did not own any computer game. So I started to write my own games (actually my father bought computer for himself, I was just excuse so he could justify that purchase to my mother). Together with him, I wrote my first game at the age of six.

Gojko may think of this conversation as his simple and common sense gesture. But as software testing in Croatian software development community has not been recognized yet as equaly important part of software development community, this simple gesture will help software testing to be recognize in Croatian software development community.

Thank you Gojko!