3 Methods for Better Communication and More Effective Testing

3 Methods for Better Communication and More Effective Testing

https://www.stickyminds.com/article/3-methods-better-communication-and-more-effective-testing?fbclid=IwAR3Zu9w0Jpm7qMsDm4H-gjY0OqiQhzWSiDZJ0eK6bz_WcQts19UwLCURsP4

3 Methods for Better Communication and More Effective Testing

더 나은 의사소통과 더 효과적인 테스팅을 위한 3가지 방법

By Ajay Balamurugadas - October 22, 2018

Summary:

Successful delivery of software requires the entire team, so it’s imperative that everyone choose their words carefully so they convey what they really mean, are sensitive to others’ feelings, and consider all aspects of a problem. Here are three questions to remember when communicating about your software testing projects to ensure you’re considering the power of words.

요약: 소프트웨어의 성공적인 출시는 팀 전체를 요구한다. 따라서 실제로 의도한 말을 전하기 위해 모두가 자신의 단어를 신중히 선택해 다른 사람의 감정에 신경쓰고 한 문제의 모든 측면을 고려하는 것이 필수적이다. 다음은 당신이 말의 힘을 고려하고 있는지 확인하기 위해 당신이 소프트웨어 테스팅 프로젝트에 대해 의사소통할 때 기억할 세 가지 질문을 제시한다.

Ask anyone who has been in the software industry for a while, and they can tell you stories about projects they’ve worked on that were on a death march. Many projects fail even before they can reach customers, and it’s more disappointing when the failure is entirely preventable.

잠시동안 소프트웨어 산업에 있었던 누구에게라도 요청해 보면 그들은 당신에게 자신들이 죽음의 행진에서 일했었던 프로젝트에 관한 이야기 해줄 것이다. 심지어 많은 프로젝트들이 고객에게 도달하기 전에 실패한다. 그리고 그 실패는 완전히 예방할 수 있었다는 점에서 더욱 실망스럽다.

One common cause of preventable failures is miscommunication. Successful delivery of software requires the entire team, so it’s imperative that everyone choose their words carefully so they convey what they really mean, are sensitive to others’ feelings, and consider all aspects of a problem.

예방이 가능한 실패의 공통적인 원인 중 하나는 잘못된 의사소통이다. 소프트웨어의 성공적인 출시는 팀 전체를 요구한다. 따라서 실제로 의도한 말을 전하기 위해 모두가 자신의 단어를 신중히 선택해 다른 사람의 감정에 신경쓰고 한 문제의 모든 측면을 고려하는 것이 필수적이다.

Here are three questions to remember when communicating about your software testing projects to ensure you’re considering the power of words.

다음은 당신이 말의 힘을 고려하고 있는지 확인하기 위해 당신의 소프트웨어 테스팅 프로젝트에 대해 의사소통할 때 기억할 세 가지 질문을 제시한다.

1. What are you emphasizing?

1. 강조하고자 하는 바가 무엇인가?

In every project I’ve worked on, there has been at least one instance when the software testers were asked, “Why did you miss the bug?”

내가 일해왔던 모든 프로젝트에서는 “당신이 그 버그를 놓친 이유가 무엇인가?”라고 소프트웨어 테스터에게 질문하는 사례가 적어도 하나는 있었다.

How do you feel when you hear that question? Did you interpret it as “Why did you miss the bug?” or “Why did you miss the bug?” Did you start thinking of an answer to the question based on how you heard it?

당신이 그 질문을 들었을 때 어떤 기분이 드는가? 당신은 그 질문을 “당신이 그 버그를 놓친 이유가 무엇인가?”로 이해하는가 또는 “당신이 그 버그를 놓친 이유가 무엇인가?”로 이해하는가? 당신이 그것을 어떻게 들었는지에 근거해 그 질문에 답을 생각하기 시작했는가?

It’s helpful to think of the “Mary had a little lamb” heuristic from Jerry Weinberg’s books: Emphasise each word of the sentence and notice what thoughts arise as a result of every emphasis. For instance, consider the question “Are you going home early again today?” If you emphasize “Are you going home early again today?” it could mean the asker also was hoping to go home early. If you emphasize “Are you going home early again today?” it could mean the asker thinks you’re going home early too often. And if you emphasize “Are you going home early again today?” it could mean the asker thinks there’s something important you should stick around for.

제리 와인버그의 책에 나오는 “매리는 작은 양을 가졌네.”라는 자가학습적인 방법이 도움이 된다. 즉 문장의 각 단어를 강조하고 모든 강조 단어의 결과로 어떤 생각이 드는지 인지하는 것이다. 예를 들어 다음의 질문을 생각해 보자. “당신은 오늘도 역시 집에 일찍 갈 건가요?” 만일 당신이 “당신은 오늘도 역시 집에 일찍 갈 건가요?”로 강조한다면 그것은 질문자도 집에 일찍 가기를 희망한다는 의미일 수 있다. 만일 당신이 “당신은 오늘도 역시 집에 일찍 갈 건가요?”로 강조한다면 그것은 질문자가 당신이 너무나 자주 집에 일찍 간다고 생각한다는 의미일 수 있다. 그리고 만일 당신이 “당신은 오늘도 역시 집에 일찍 갈 건가요?”로 강조한다면 질문자는 당신이 오늘 회사에 머물러야 하는 무언가 중요한 것이 있다고 생각한다는 의미일 수 있다.

In the “Why did you miss the bug?” example, the person asking the question might want to know the reason behind not discovering the bug earlier, but the question could be interpreted as a personal attack. The person answering the question may get into a defensive mode and come up with excuses for why the bug could not be found during testing. The real issue is hidden in how the question was asked.

“당신이 그 버그를 놓친 이유가 무엇인가?”의 예제에서 그 질문을 하는 사람은 그 버그를 일찍 발견하지 못한 숨은 이유를 알고 싶어 할 수도 있다. 하지만 그 질문은 개인적인 공격으로 해석될 수도 있다. 그 질문에 답하는 사람은 방어적인 태도로 들어가 왜 테스팅에서 그 버그가 발견되지 않았는지에 대한 이유를 떠올린다. 어떻게 질문을 하게 되었는지에 대한 실질적인 이슈는 감춰져 버린다.

Consequently, I’ve reduced the “Why” questions and rephrased them to sound like a discussion rather than an interrogation. Instead of “Why did you miss the bug?” I ask, “How do you think we could have found this bug before release?” I immediately get some good solutions we can implement. It also gives me an idea of where the actual problem is.

결과적으로 나는 “왜”라는 질문을 줄였다. 그리고 심문하기 보다는 토론 같은 형태로 그것을 변형했다. 나는 “당신이 그 버그를 놓친 이유가 무엇인가?” 대신 “우리가 출시 전에 이 버그를 발견할 수 있었을까요?”라고 묻는다. 나는 즉시로 몇 가지 좋은 해결책을 얻게 되어 그것을 실행할 수 있었다. 또한 그것이 나에게 실제 문제가 어느 부분인지에 대한 아이디어를 주었다.

The next time you want to ask someone on your team a question, pause for a second, think of the “Mary had a little lamb” heuristic, and see if the question can be misinterpreted. This can save a lot of time and effort later in the project.

다음 번에 당신이 당신의 팀원 중 누군가에게 질문을 하려고 할 때 잠시만 멈춰서 “매리는 작은 양을 가졌네”의 자가학습적인 방법을 생각해 내고 그 질문이 잘못 이해될 수 있는지 확인한다. 이것은 이후 프로젝트에서 많은 시간과 공수를 절약해 준다.

2. Are you considering different perspectives?

2. 당신은 서로 다른 관점을 고려하고 있나?

When project teams get bigger, the interactions between people gradually reduce. Silos start to creep in and teams communicate less, which results in people failing to recognize any perspective other than their own. Tunnel vision comes to the fore and people miss out on getting a taste of different perspectives.

프로젝트 팀이 점점 커지면 사람들 사이의 상호작용도 점차 줄어든다. 사일로는 기어가기 시작하며 팀의 의사소통은 줄어든다. 이것은 사람들이 자신이 아닌 다른 사람의 관점을 인지하지 못하게 되는 결과를 낳는다. 터널 비전이 전면에 생기고 사람들은 서로 다른 관점이 가지는 진의를 얻지 못하게 된다.

(참고: 터널비전은 어두컴컴한 터널 안으로 들어갔을 때, 주위가 아닌 오직 저 멀리 정면의 빛만 보게 되는 일종의 시각장애를 일컫는 말로, 심리학적으로는 숲이 아닌 나무만 보는 인간의 제한된 시야와 사고를 설명하는 단어로 사용되기도 한다.)

In any of the discussions where I am called to act as the facilitator, I ensure that the right participants are in the discussion - and only the involved parties, so we get the necessary perspectives.

나는 내가 퍼실리테이터의 (facilitator) 역할을 해달라고 요청 받았던 토론 자리 어느  곳에서나 올바른 참석자들이 토론에 참여했고 관련자만 참석했는지 확인한다. 따라서 우리는 필요한 관점을 얻는다.

As the saying goes, there are three sides to every story: your side, my side, and the truth. This sums up the typical problems in any conversation. The assumptions behind a statement usually don’t come up, and we fail to understand why our choice of words might be giving a totally different picture to the listener.

속담에도 있듯이 모든 이야기에는 세 가지 면이 존재한다. 당신 생각, 나의 생각 그리고 진실이다. 이것은 어떤 대화의 전형적인 문제를 요약해 준다. 한 문장에 숨은 가정은 대체로 드러나지 않는다. 또한 우리는 왜 우리가 선택한 단어들이 청자에게는 완전히 다른 그림으로 비춰지는지 이해하지 못한다.

For example, statements like “I want this done by the end of the day” doesn’t convey why the task needs to be done today. And with such an authoritative tone, you can hardly expect anyone to ask clarifying questions. It slowly affects the morale of the team, to the detriment of the deliverable.

예를 들어 “오늘 퇴근전까지 이것을 마치고 싶다”와 같은 문장은 왜 오늘 그 과업을 완료해야 하는지를 전달하지 않는다. 또한 당신이 그런 권위적인 어조를 띄면 누군가가 명확하게 질문을 할 것을 기대하기 어렵다. 이것은 점차로 팀의 사기와 결과물에 해로운 영향을 준다.

In the same situation, think of the difference if the request was posed as, “Considering the time needed for fixing any critical issues that could be discovered, can we aim to finish all our tasks by end of the day?” Yes, there are definitely more words, but the meaning they convey has changed. The tone of the conversation is more respectful, and a channel for discussion has opened for both the parties.

마찬가지 상황에서 “발견할 수 있는 다른 치명적인 이슈를 수정하는데 필요한 시간을 고려해서 오늘 퇴근 전까지 모든 작업을 마치는 것을 목표로 할 수 있을까요?”라는 요청의 차이를 생각해 본다. 그렇다. 확실이 더 많은 단어가 있다. 하지만 그것들이 전달하는 의미가 바뀌었다. 대화의 어조가 좀 더 존중적이며 토의를 위한 채널을 양쪽 집단을 위해 열어 둔 것이다.

3. Is your criticism constructive?

3. 당신의 비평이 건설적인가?

Have you been in meetings where every proposal was shot down even before the speaker finished explaining the idea? Many people fail to realize the power of their words - especially the negative words. Testers are critical thinkers, and their first thought usually is how an idea won’t work.

당신은 심지어 제안자가 그 아이디어의 설명을 마치기도 전에 모든 제안이 폐기되는 회의를 겪은적이 있나? 많은 사람들이 특히 부정적인 말의 경우 자신의 말이 가진 힘을 인식하는데 실패한다. 테스터들은 비판적 사고가이다. 따라서 대체로 그들의 첫 번째 생각은 아이디어가 어떻게 동작하지 않는지에 대한 것이다.

Speakers shouldn’t always take these words to heart; it is good to have constructive criticism. But constructive criticism is different from how naysayers behave.

말하는 사람은 항상 이 단어들을 마음에 두어서는 안 된다. 건설적인 비평은 좋은 것이다. 하지만 건설적인 비평은 비관론자들이 행동하는 것과는 다른 것이다.

There was an instance where we kept having a customer report an issue that was due to a special character. There were different modules and special characters were allowed in all of the modules, and we were constantly patching the system one bug at a time. We realized that it was the interaction across modules that was causing the issue, so we wanted to brainstorm about how to find such issues.

우리에게는 특수 문자 때문에 이슈를 제기했던 고객이 존재했던 사례가 있다. 서로 다른 모듈이 있었고 특수 문자는 모든 모듈에서 허용되었다. 그래서 우리는 한 번에 한 버그씩 지속적으로 시스템을 패치해 나갔다. 우리는 그 이슈가 모듈 간의 상호작용에 있음을 알게 되었고 그런 이슈를 어떻게 찾을 것인지에 대해 브레인스토밍을 하기 원했다.

The ideas started flowing:

• Restrict special characters in the whole system
• Test the main flows and ignore the other flows
• Rewrite the whole code
• Create a mock customer with just the special characters and automate the flows
• Sanitize the data getting in and out of the database

다음과 같은 아이디어로 시작했다.

• 전체 시스템에서 특수 문자를 제한한다
• 주요 흐름을 테스트하고 다른 흐름은 무시한다
• 전체 코드를 재작성한다
• 그냥 특수 문자를 가진 가상 고객을 만들고 그 흐름을 자동화한다
• 데이터베이스에 들어오고 나가는 데이터를 정제한다

While all the ideas were being discussed, there was one voice that kept shooting down every suggestion:

• Without special characters, we would miss out on security
• Every flow is important, and we have a lot of customers
• Legacy code needs lot of rework
• We don’t have the bandwidth to automate the regular flows, and this would take extra time
• It’s not an ideal solution

모든 아이디어를 논의하는 중에 모든 제안을 격추시킨 하나의 목소리가 있었다.

• 특수 문자가 없으면 우리는 보안성을 놓칠 수도 있다
• 모든 흐름이 중요하고 우리는 많은 고객을 가지고 있다
• 레가시 코드는 많은 재작업이 필요하다
• 우리는 정규 흐름을 자동화할만 작업 대역폭을 가지고 있지 못하다. 따라서 이것은 추가 시간이 필요할 수도 있다
• 그것은 이상적인 해결책이 아니다

After fifteen minutes of discussion, that person left the meeting for a call. The group immediately opened up. We discussed the pros and cons of every approach and finally decided on an implementation to solve the issue. The naysayer is a good person at heart, but he never realized the impact his words had on the morale of the team.

15분의 논의 끝에 그 사람은 전화를 받으러 회의를 떠났다. 그 그룹은 즉시 마음을 터놓게 되었다. 우리는 모든 접근법의 장단점을 논의했고 최종적으로 그 이슈를 해결할 실행 방법을 정했다. 그 비관론자는 본심은 좋은 사람이었지만 그의 말이 팀의 사기에 가져올 영향은 전혀 인식하지 못했다.

After I got to know about Edward de Bono’s concept of the six thinking hats, I started applying it in discussions to give everyone a fair chance of sharing their views. “Wearing the yellow hat” forces everyone to focus on the positives, so the naysayer’s effect is reduced considerably. Slowly, the habit of appreciating the good in every idea before criticizing it spread within the team. We started having productive discussions, thanks largely to the six thinking hats concept.

내가 에드워드 드 보노의 여섯 가지 모자 기법을 알게 된 후 나는 토론에서 모든 사람들이 자신의 관점을 공정하게 공유할 기회를 얻도록 하는데 적용하기 시작했다. “노란 모자를 쓰는 것”은 모든 사람들이 긍정적인 것에 집중하게 만들었고 비관론자의 효과는 크게 감소했다. 천천히 그것을 비평하기 전에 모든 아이디어의 좋은 점을 칭찬하는 습관이 팀 내부로 퍼져나갔다. 우리는 건설적인 토의를 가진 채로 시작했고 여섯 가지 모자 기법 개념에 크게 고마워한다.

We all tend to blurt out words as we come up with them. It is important to realize that each word is powerful and has the potential to either boost or damage any conversation. Remember to ask yourself these three questions in every interaction, and it will help your team engage in better communication - and have more effective software testing.

우리 모두는 떠오르는 대로 말을 무심코 하는 경향이 있다. 각각의 말이 강력하며 어떤 대화든지 상승시키거나 피해를 줄 수 있는 잠재력을 가지고 있다는 점을 인식하는 것이 중요하다. 모든 상호작용에서 이 세 가지 질문을 스스로에게 되묻는 걸 기억한다면 그것이 당신의 팀이 더 나은 의사소통을 경험하는데 도움이 되어 더 효과적인 소프트웨어 테스팅이 될 것이다.

- END