버그를 대하는 자세는 어떤가요?

 

0. 버그를 대하는 자세

 안드로이드 클라이언트 개발자로 취업을 한 지, 3개월이 지나고 있습니다. 2019.12.05. 버그를 수정하면서 겪은 경험을 공유하려고 합니다.

- Fact :
ㄱ. 토스트를 띄우는 과정에서 Context가 소실되어서 토스트를 못 띄우는 사례가 있었습니다. 그러한 과정에서 context가 null일 때, 토스트를 띄우지 못 하고 있는 것을 발견했습니다.

ㄴ. 그렇다면 Context가 null인 지, 체크해서 null이 아닐 때, 토스트를 띄우면 되겠다고 생각을 했고, 반영을 했습니다.

ㄷ. 결과는 Context가 null일 때, Toast에 Context를 넣는 과정에서 Toast에 context를 넣지 않고, view를 넣는 대참사가 만들어졌습니다.

 

- Feeling :

ㄱ. 버그를 인지했다.

ㄴ. 버그가 어떤 상황에서 발생하는 지 알았다.

ㄷ. 해당 버그가 그런 상황에서 나니까, 버그를 고쳤다.

ㄹ. 버그가 더 큰 괴물을 만들었다.

 

 이러한 버그를 고치는 방법에 대해서 잘못된 과정이 없다고 생각을 했습니다. 이전까지 버그를 대할 때, 이와 같이 단순히 버그의 내용만 보고 버그를 개선했는데, 이번 일을 겪고 난 후, 버그를 개선하는 것에 있어서 좋지 않은 습관이 있다는 것을 알게 되었습니다. 저는 이번 일이 발생하기 전까지, 버그는 단순히, 앱이 해당 이유에 의해서 죽는 것으로만 인지했습니다. 그래서 빠르게 버그를 제거하고 싶다는 생각만 앞섰습니다. 그리고, 더 큰 부작용을 겪게 되었습니다.

 이번에 느낀 점은 해당 버그가 발생하는 것을 막아야하는 것이 아닌, '우리 앱에서는 이러한 이유로 이러한 시나리오에서 버그가 일어나고 있습니다.'라는 것을 모두에게 공유해야하는 것을 알게 되었습니다.

 그래야만, 해당 버그에 대해서 시나리오를 세우고, 테스트를 하며, 버그를 고칠 때, 다양한 테스트를 하고, 테스트에 대한 결과를 확인하기 때문에 부작용이 줄어들 것입니다.

 

Before : 211번 째 줄에서, context가 null 이여서 앱이 죽었다.

개발 : context가 null 이어서 앱이 죽었으니, 앱을 고쳐야 한다.

운영 : ?

기획 : ?

 

After: 결과를 반영하고 난 후, 나오는 토스트 메시지에서 'A라는' 케이스에서 토스트가 나와야하는 시나리오에서 죽고 있습니다. 인지해주세요.

개발 : 토스트가 나오는 시나리오를 인지했습니다. 그런 시나리오에서 context가 null일 때, 버그가 발생하지 않도록 고쳤고, 테스트 결과 해당 버그가 정상적으로 고쳐진 것을 확인했습니다.

운영 : 해당 시나리오의 유저들에게 대처하겠다.

기획 : 인지했고, 일정에 반영하겠다.

 

1. 버그를 대하는 자세의 변화의 필요성

ㄱ. 버그를 인지했다.

ㄴ. 버그가 어떤 상황에서 발생하는 지 알았다.

ㄷ. 실제 테스트를 통해서 버그가 어떤 시나리오에 발생하는 지 명확하게 인지한다.

ㄹ. 팀원들에게 버그가 해당 시나리오를 통해서 버그가 발생하는 지 공유한다.

ㅁ. 해당 버그가 그런 상황과 구체적인 시나리오에 의해서 발생하니, 버그를 고쳤다.

ㅂ. 버그를 고친 후, 다양한 시나리오에서 버그를 고친, 테스트 한다.

 

 그렇기에 우리는 버그를 하나의 완벽한 시나리오로 마주할 수 있습니다.

또한 앱을 서비스하는 것에 있어서, 단순히 개발의 영역에서 끝내야하는 것이 아닌, 팀들과 함께 서비스를 제공한다는 것을 잊으면 안 되고, 개발만이 대처해야하는 것이 아닌, 모두가 대처해야한다는 것을 잊으면 안 된다는 것을 알게 되었다.