소프트웨어 테스팅에서 "안전 언어"가 중요한 이유

테스터로서 출시를 준비하기 전에 질문을 받을 수 있습니다.

"다 테스트 해보셨나요? 버그는 없나요?”

또는 이러한 라인에 따른 질문. 옳지만 아마도 더 잘못된 것은 사람들이 우리를 테스터로 보고 안심시키려고 하고 때로는 (다시 잘못) "출시 승인"이라고 생각한다는 것입니다. 내가 처음 테스트를 시작했을 때 이것이 지금보다 더 일반적이었다는 것을 인정해야 합니다. 그때 나는 그들의 질문을 액면 그대로 받아들이고 답장을 했을 것입니다(지금 돌아보면 아주 순진합니다)

“예, 모든 것을 테스트했습니다. 버그나 문제가 없습니다."

수년에 걸쳐, 나는 내가 어떻게 이 질문들에 잘못된 방식으로 답하고 있는지 깨달았습니다. 내가 이것을 이해하는 데는 한 특정한 순간이 필요했습니다.

나는 그 역할에서 약 2년의 경험을 가진 다른 회사에서 테스트를 하는 비교적 신참이었습니다. 저는 Agile 팀에서 일하고 있었고 유일한 테스터였습니다. 우리는 꽤 큰 변화를 발표했습니다. 위와 같은 질문을 받았습니다. 나는 위에서 언급한 것과 거의 같은 방식으로 대답했습니다. 보라, 출시 이후에 문제가 있었다. 제품 소유자가 나에게 와서 "당신은 모든 것을 테스트했다고 말했습니다."라고 말했습니다.

물론, 당신과 나는 알고 있습니다. 내가 모든 것을 의미하지는 않았습니다 . 소프트웨어 테스터는 모든 것을 테스트할 수 없다는 것을 알고 있습니다. 릴리스가 시스템의 다른 부분에 의도하지 않은 영향을 미쳤습니다. 우리(팀)가 건드리지 않은(또는 그렇게 생각한) 시스템의 일부는 범위를 벗어났습니다. 그 결과 내가 실수를 했다는 것을 알았고, 당시 몇몇 동료들과 이야기를 나누었고, 그들은 "안전 언어"에 대해 언급했고 내가 그것을 통해 어떻게 혜택을 받을 수 있었는지에 대해 언급했습니다.

왜 중요합니까?

절대값을 다룰 때 실수할 여지가 없습니다. 나중에 오류가 발견되면 신뢰를 잃게 됩니다.

신뢰성이 중요합니다. 소프트웨어 테스터로서, 우려 사항이나 문제가 있을 때 귀하의 말을 들어줄 사람들이 필요하기 때문에 더욱 그렇습니다. 예를 들어, 테스트 범위를 알 수 있도록 수행한 테스트를 설명할 때 사람들이 당신의 말을 들어줄 필요가 있습니다.

안전 언어를 사용하여:

• 문제가 있는 경우에도 여전히 신뢰를 유지합니다.
• 당신은 당신이 테스트한 것에 대해 여전히 개방적이고 정직합니다.
• 당신은 버그 를 발견 하지 못했다는 점에서 사실입니다. 소프트웨어는 결코 버그가 없을 수 없기 때문에 버그가 없다고 말하는 것이 아닙니다.

모든 것을 테스트할 수는 없습니다 . 가장 위험하다고 느끼는 영역을 테스트할 수 있습니다. 테스터로서 이러한 영역을 식별하는 방법은 귀하에게 달려 있습니다.

고위험 영역에 테스트를 집중합니다. 당신이 이 일을 하는 이유는 당신이 속한 분야의 전문가가 이 분야에서 가장 큰 가치를 얻을 것이라고 느끼기 때문입니다. 자동 검사를 사용하여 테스트하고 탐색할 위치를 안내할 수 있습니다.

자동화된 검사는 일부 버그가 통과하지 못하도록 차단한다는 점에서 그물과 같습니다. 그러나 어떤 그물이든 항상 문제가 발생합니다. 여기에서 전문 지식과 테스트 사고 방식을 사용하여 테스트 노력에 집중할 수 있습니다.

소프트웨어 개발은 ​​어렵다. 고려해야 할 사항이 많이 있습니다. 암호; 회로망; 외부 의존성 및 기타 여러 가지. 모든 것을 테스트 하는 것은 불가능합니다.

Michael Bolton 은 다음과 같이 말합니다.

소프트웨어 테스터로서 우리의 임무는 소프트웨어를 깨뜨리는 것이 아닙니다. 소프트웨어에 대한 사람들의 환상을 깨기 위한 것입니다.

본질적으로 소프트웨어 자체는 이미 고장났고 우리는 그것이 어떻게 고장났는지 그리고 고객 및/또는 비즈니스에 미치는 영향을 강조할 수 있었습니다.

그럼 원래 뭐라고 말했어야 했나?

이 블로그 게시물의 시작 부분에서 내가 말한 내용에 아무런 문제가 없다고 생각할 수도 있습니다.

원래 질문했던 내용을 되돌아보면...

"다 테스트 해보셨나요? 버그는 없나요?”

릴리스를 위해 몇 가지 테스트를 수행했는데 버그가 전혀 발견되지 않았습니다. 그러나 이것은 내가 말한 것이 아닙니다. 내가 말했어야 하는 것은 이렇습니다.

“예, 우리가 논의한 대로 테스트를 수행했으며 여기에 문서화되어 있습니다. 내가 수행한 테스트에서 버그나 문제를 발견하지 못했습니다."

차이점이 뭐야?

나는 내가 테스트한 것, 테스트한 방법, 심지어 그 뒤에 있는 문서(노트든, 당시 테스트 케이스든)를 정확히 강조하고 있습니다. 내가 말하는 사람에게 어떤 테스트가 수행되었고 (일반적으로) 그들이 어떤 형태로든 계획에 참여했을 것이라는 점은 분명합니다. 나는 또한 내가 수행한 테스트에서 버그를 발견하지 못했다는 점을 강조했습니다. 이것은 이 소프트웨어에 버그가 없다는 의미가 아닙니다.

안전 언어의 다른 예는 무엇입니까?

내가 알아차린 한 가지는 안전 언어를 여러 가지 방법으로 사용할 수 있다는 것입니다.

다음에 재현하기 위해 고군분투하는 버그를 발견하면 다음과 같이 말하지 마십시오.

"이 버그를 찾았지만 재현할 수 없습니다."

이것은 다시는 그런 일이 일어나지 않을 것이라는 의미이거나 애초에 그런 일이 일어나지 않았을 수도 있음을 의미합니다. 테스터로서 마주치는 모든 단일 버그는 이유가 있습니다. 이러한 이유를 밝혀내는 것이 테스터로서 우리의 임무입니다. 다시 만들 수 없다면 아직 원인을 찾지 못한 것입니다. 따라서 재현할 수 없다고 말하는 대신 다음과 같이 말하십시오.

"이 버그를 찾았지만 현재로서는 재현할 수 없습니다."

대부분의 경우와 마찬가지로 사고 방식과 정보 전달 방식의 작은 변화입니다. 그러나 대부분의 경우와 마찬가지로 가장 큰 영향을 미칠 수 있는 작은 변화일 수 있습니다.

이전에 버그를 발견했을 수 있습니다. 로그 및 콘솔을 탐색하고 근본 원인이 무엇인지 알고 있다고 생각합니다. 그래서 개발자에게 가서 이렇게 말합니다.

"이 버그를 찾았습니다. 이것이 원인입니다...."

개발자는 우리가 논의한 대로 문제를 수정하고 다시 테스트하기 위해 가는데 문제는 여전히 존재합니다. 문제? 단일 문제에 대한 깊은 거짓말 원인이 있을 수 있습니다. 내가 말했어야 하는 것은:

"이 버그를 찾았습니다. 이것이 문제를 일으키는 원인 중 하나일 수 있습니다..."

이 접근법을 취함으로써 우리는 그것이 하나의 원인이라는 것을 알지만 그것이 유일한 원인이라고 말하지는 않았습니다. 따라서 우리는 더 많은 것을 탐색하고 당면한 버그를 유발할 수 있는 다른 원인을 찾을 수 있습니다.

이제 뭐?

이 게시물을 읽고 안전 언어가 소프트웨어 테스터로서의 커뮤니케이션에서 가질 수 있는 역할을 이해하게 되었기를 바랍니다. 우리는 모든 테스터가 이해 관계자와 의사 소통할 때 안전 언어를 사용하도록 권장합니다.

테스트는 정보에 관한 것입니다. 이 정보를 전달하는 방식이 절대적으로 중요합니다. 이것이 바로 훌륭한 소프트웨어 테스터가 훌륭한 스토리텔러가 되는 이유입니다. 테스트 스토리를 전달하고 사람들에게 명확하고 간결한 방식으로 수행한 작업을 설명하고 테스트 스토리에 참여하여 그들이 어디에 적합한지 더 잘 이해할 수 있도록 도와야 합니다.

다음에 누군가가 당신에게 질문을 하면, 당신의 대답을 어떻게 구성할지 신중하게 생각하십시오. 다음에 무언가를 선언할 때 그것이 어떻게 전달되고 그것이 당신에게 어떤 의미가 있는지 신중하게 생각하십시오.

질문을 하는 사람들을 위한 교육 자료도 있습니다. 그들은 릴리스의 "승인"(그들이 요구하는 대로)을 위해 한 사람에게 가서는 안 됩니다. 모든 사람이 참여하고 누구나 소프트웨어에 대한 정보를 제공할 수 있는 보다 협력적인 경험이 필요합니다.

Safety Language의 좋은 실제 사례가 있습니까? 댓글로 알려주세요!