“To make changes, understand why people resist them”: Jim Holmes on the culture of testing
What could the army teach the tester? What are the two extremes in testing approaches? How to explain that technical debt payment is red? What do the previous questions have in common?
The general thing is that for all their difference, they are all close to one person. At Jim Holmes behind several decades of IT experience, which began in the 80s in the US Air Force - it is not surprising that he is ready to tell a lot. The concept of “testing culture” is important for him, and we asked him questions that can vary greatly, but in the end, one way or another, they are connected with the testing culture.
mob programming . In general, I believe that automation is a tool, not a goal.
- The words “close cooperation with developers” are very close to us as the organizers of Heisenbug - even the conference slogan is “about testing, but not only for testers”. And in connection with this collaboration, I would like to ask the following question: what would you like as a person with extensive testing experience would like to say to our programmer readers?
- That we are not all evil! Testers by their own actions earned themselves notoriety. They find fault with the smallest details at meetings, often communicate with bugs, not words. The developer comes to work in the morning and sees 50 bug reports about grammatical errors and unaligned pages. I visited both roles, and I know how programmers react to this. This is part of the old school of testing, and I myself also once behaved like this. But testers who are more accustomed to the modern approach understand that than filling a programmer with bug reports, it is easier and better to just talk to him.
In my opinion, it is important for developers to understand that a good tester can be very valuable, and if you talk to him in advance, you can save yourself a lot of time and nerves. This is what the theory of constraints says. Suppose I am a developer, and I see that the tester found some problem. If instead of e-mailing to her in TFS or anywhere else, I just go to him and talk personally, then this conversation will help me reduce the number of defects in the code I am writing. Moreover, in personal communication, most testers, as a rule, are far from being so terrible. In general, you, as a developer, will be able to improve the quality of your code if you get rid of common stereotypes about testers - which, unfortunately, often have a basis, and we also need to work on this.
Therefore, I really liked that in your conference you are trying to gather people with different specializations. This is very important, because for a long time all the major conferences, both professional and community-based, have severely limited themselves — either only testers or developers. If we start to communicate with each other, it will be a great conference.
3r3167. If such a conference format is also close to you, and Jim is interested in you, pay attention: he, too, will speak at the nearest Moscow 3r-3267. Heisenbug [/b] where details. tell r3r3181. about your experience in a Fortune 10 company. How can you change the testing culture in a giant company, if giants are usually slow? On December 6-? on Heisenbug, it will be possible to find out about this, and 3r3r172. about many other things 3r3181. . 3r3174.
- I would like to compare developers with testers here. You wrote a book about leadership
“The leadership journey” . It is known that developers have a difficult attitude towards leadership: while for others this is a cherished dream, developers often associate it with a bunch of unpleasant responsibilities that are not related to the most interesting thing - writing code. Is such a look common among testers?
“I think this is a common mood for IT: it doesn't matter if you are involved in database administration, programming, testing, and project management.” You have work that you do well, you feel comfortable, you have experience, you have influence in this role. Compared to this, the need to take on more responsibilities and, oh, horror, working with people, sounds much less comfortable and causes rejection. Therefore, at the very beginning of my book, I suggest ways to find out if you really need all this, and what it means to be a leader.
Some leader functions can be performed without moving up the hierarchy. A person who within the team has more experience and skills than others will be in this team informally playing the role of leader. So it's not necessary to become a manager: perhaps you just think that you need to have a lot of influence in your team. Although in some organizations it is taken for granted that, having gained some experience, a person begins to occupy leadership positions. He is made a technical manager, and, in addition to writing code, he is now responsible for the qualifications of his team. And at higher levels, he generally stops writing code. So, in general, leadership can take many different forms. The specificity of our field is that we are afraid of holding managerial positions because we are afraid of losing our technical skills because we stop writing code or testing. In addition, if the tester is not engaged in the development, it will be terrible for him to lead programmers. All these problems are absolutely natural, overcoming them is an integral aspect of leadership in our industry.
- And one more question comparing developers and testers. Among the developers, there is an active discussion regarding remote work: some believe that this should be done a long time ago by default, while others object that live chat cannot be replaced with Skype. You work remotely - what is your opinion about the remote in testing?
“Of the 18 years since my daughter’s birth, I worked remotely at 13 or 14. So I really have an opinion on this issue.” In my opinion, remote work is an important tool, it allows you to expand the circle of people with whom you can potentially work. For example, with a person who lives in another state or on another continent. So I am a supporter of remote work, in some situations it is very useful.
At the same time, it is necessary to recognize that during remote work there are significant problems with communication and productivity. Purely from a technical point of view, a team that works completely or mostly at a distance should have a good infrastructure. Each member of such a team should work on the principle of DevOps. There should not be a situation when we cannot contact the server administrator in days to get logs for debugging. In addition, you need to seriously approach the organization of means of communication. And if you decide that you have enough Skype and some messenger, did not take Skype for Business and use the free version of Google Hangouts, then you will have problems. Remote work requires good infrastructure. In addition, you are required more responsibility and discipline. Yes, you can work even in pajamas, but you have to work and not play on the Xbox for days on end - I am ashamed to admit it, but I say this from my own experience.
In addition, conversations in the corridors and live communication are an integral part of any kind of work at all - people are just like that. And I must admit that here remote work has a significant drawback. Let you have a hangout running on Slack and live video chat - it's all wrong. This problem is solved, but time and discipline are needed for this, and for each new team member this problem needs to be solved anew.
Over the past 20 years, I have worked at a distance of two times more than in the office, as I said, this is a great tool. But at the same time it is necessary to have a clear idea of the advantages and disadvantages of such work. In addition, the organization needs to bring the entire team together for live communication at least four times a year to make connections that you cannot build via the Internet. Everyone needs to sit in the same room, work, argue, have fun. All this is very important for creating a well-coordinated team. If you think that remote work is just a way to reduce costs, you will be disappointed. I again had a rather long answer, but what to do, you ask interesting questions.
- You have a post with the title "Technical debt: payment plan". The phrase “technical debt” can be seen often, but in combination with the phrase “payment schedule” for the first time, although this is a very logical development of metaphor. Does this mean that we have not yet reached the degree of responsibility when we treat technical debt as seriously as money, and that we should be corrected?
- This is a very important question. I think that anyone who has worked in IT for a long time has necessarily faced the problem of technical debt. Here I need to thank Trish Khoo, she can be found on Twitter as hogfish. She is an excellent tester, I have known her for many years. She, in fact, wrote the post “Technical debt: payment plan”. I also wanted to write about it when I read this post, because for five years I made speeches at conferences where I expressed, in general, similar thoughts.
So, in our industry, the problem of technical debt has long been present; we all have to think about how to avoid it and what to do with it when it does arise. In my opinion, your proposal to think about it as a financial debt has very important consequences. If you do the appropriate research, you will see that this technical debt does lead to financial costs. Due to technical debt, your project takes more time on X, more people work on it on Y, and they all need to pay a certain salary. That is, these costs are quite measurable, although they may not be so easy to assess. Or suppose you had to fix 30 bugs within a month and a half due to problems with technical debt. This, again, leads to an increase in the price of the project in dollars. Moreover, we are talking not only about the costs in dollars, but also about the opportunity costs: for one and a half months you could do something else.
Many years ago I worked in a company where for every 10 days of work on a new functionality, there were 3 days to correct the problems with quality and technical debt. And for every 3 days, there was a day of correction. There were problems that were rediscovered many times. It all cost money. I left this organization, so that during the time I worked there, I could not change the culture that had developed there and make them admit that such a situation is unacceptable. The last straw was my unsuccessful attempt to explain to the director that out of three years that I worked there, we lost a year due to the correction of problems related to technical debt. I was not able to convey to him my thought, he turned the conversation to another topic. I believe that people working in IT need to learn to better explain the significance of technical debt and the costs to which it leads. We cannot just sit in our corner, work and not communicate with anyone. We need to learn to speak a language that will be understood by business. A business understands the language of dollars and lost time. Business begins to think when sales or renewal of licenses fall, and this is due to a drop in quality, which, in turn, is caused by technical debt.
The cause of technical debt is excessive pressure, attempts to save on important things and the fact that business does not understand the meaning of its decisions. Although our fault in this also happens when we do not have the appropriate skills, when we do not follow generally accepted recommendations and when we do not know how to conduct a dialogue with business. Learning to formulate technical debt in terms of financial debt, in my opinion, is a very important skill that we all need to work on. I repeat, you asked a very good question.
- I would like to add that I came across situations where writing modular and integration tests were related to technical duty, because there is no time left for them during the execution of the main tasks. Managers decide that since it works without tests, let's send everything to production as well, and leave refactoring and tests to the account of technical debt.
- This problem has two sides. It is not clear to business why to refactor and why to write automated tests. They only see that people spend on writing tests twice as long as writing code, and this seems monstrous to them. This is already a matter of education, so it is necessary to explain that development is a process that has been established for decades. There are statistics and studies that show that attempts to save on testing directly lead to costs in dollars due to delays and corrections. Business does not understand this.
For our part, we did not learn how to properly communicate with business, we did not learn how to convince. In addition, we often lack perseverance to explain that some things are not discussed, they cannot be ignored or put off. There are safe and productive practices that have developed historically, and if you, managers, follow them, in the end, you will be happy, because a great value will be created. This is a tough conversation, and we, IT professionals, do not know how to conduct it.
- Therefore, it is always good when a manager or team leader has experience in developing - then they understand these things. A good project is easier to create when management has technical expertise.
- In that company from Fortune 1? about which I spoke above, we had exactly the same problem. The lower and middle managers did not understand why testing is so important. We managed to restart the project and reach agreement on the question of when the project should be considered ready, that is, we managed to include managers in the dialogue. We have determined that the user history will be considered finished when there is documentation, when the support is well acquainted with the new functionality, when the product the operator checked the fulfillment of the requirements, which he also wrote using Acceptance Testing.
In addition, we have achieved the consent of the management to implement specific technical measures, which he did not understand. We agreed that the code should meet the standard indicators of static analysis (for example, analysis using the Sonar Cube), that is, it should not be too complicated, there should not be too many lines in the methods. Managers realized that in order to maintain a healthy code base, industry standards for how the code should look should be followed. In addition, in our definition of a finished project there was the phrase “necessary testing”, that is, we did not specify a certain number of tests to be performed, or a certain code coverage by automatic tests to be achieved. Thanks to this, the project team leader, the developer and the tester could determine with respect to each module which testing would be sufficient. Each time it happened in the course of a dialogue, and managers for a long time could not understand that this again corresponds to the generally accepted practices of the industry.
- At this our questions are over. Thank you very much for your detailed answers.
- Thank you, I liked your questions. I think it was obvious: you managed to raise a lot of topics that are very close to me personally.