테스트의 성공과 성장 ⭐
🧍 업글인간
사람들에게 성장과 성공 둘 중 어느 것을 더 추구하냐고 물어본다면 많은 사람들이 여러 가지 이유에서 성장
이라고 답할 것이다. 업글인간이라는 신조어가 있다. 목표의 달성으로 끝나는 성공, 마침표가 아닌 계속해서 조금씩 발전해 나아가는 자기 계발 형태의 성장을 추구하는 사람이라는 뜻이라고 한다. 말 그대로 사람이 업그레이드가 된다는 것이다. 매년 핸드폰 OS 버전도 꾸준히 업그레이드가 되듯이.
개인적으로 또 다른 이유를 대자면, 성장은 오롯이 내 기준으로 판단 가능하지만, 성공은 내 기준이 될 수도, 다른 사람들은 각자의 기준으로 판단될 수도 있다고 생각한다. 남의 눈치를 많이 보는 한국 사회에선, 사실상 성공을 없애지 않을 수 없다. 하지만 성공을 중시한 목표를 두고 성장을 찾아보는 것이 아닌, 성장을 중시한 목표를 세우고 그 안에서 자잘한 성공 포인트들은 찾아낸다면, 내 마음이 조금은 덜 조급하고 편해지지 않을까 생각된다.
🤖 업글테스트케이스
테스트 또한 대부분 테스트 케이스를 따라 각 스텝에 따라 성공과 실패로 결과가 나온다. 테스트 케이스는 가능하면 따로 시간을 투자해 업데이트를 진행하고, 그 후 다시 테스트를 실행 시 사용된다. 사람은 본인이 배웠던 것을 적용하는 때에도 무언가를 또 배울 수 있고, 발전할 수 있다. 꾸준히 성장할 수 있다는 것이다. 하지만 테스트 케이스는 이용하는 방식 자체가 성공 확인을 위해 성장을 지속적으로 멈추는 방식이다. 이와 반대로 성장을 위한 경험 바탕의 테스트 방식을 도입해 보는 것은 어떨까?
📝 세션 기반 테스트 관리
Session-based test management (세션 기반 테스트 관리)
는 탐색적 테스팅을 기반으로 한다. 이는 임시/즉흥적 테스트를 더욱 제대로 문서화하고 관리하기 위해서 만들어졌으며, 사실상 제대로 콘셉트가 도입된다면, 오래된 테스트 케이스 방식 테스트 관리법에서 넘어갈 수도 있다.
세션 기반 탐색적 테스트는 테스트 케이스가 아닌, Charter
가 기반이 된다. 이는 테스트의 목적과 목표를 Mission statement
와 테스트를 수행할 분야를 설정으로 시작한다. 몇 가지 탐색적 테스트를 어느 방향으로 탐색할지 첫 방향을 잡고 시작하는 것이다. 세션 기반이기 때문에, 그에 따른 필요한 시간을 30분, 90분 등 정확하게 정해놓고, 그 시간 동안 집중해서 목적과 목표를 기준으로 탐색적 테스팅을 수행하는 것이다.
탐색적 테스트를 수행하면서, 실시간으로 테스트 노트를 세세하게 적는다. 어떤 액션을 취했고, 어떤 일이 일어났는지, 의문점이나 예상 범위 등 여러 가지 새로 고려하는 것들 또한 적고, 버그나 이슈가 찾아졌다면 링크를 달기도 한다. 테스트가 완료되면, 성공과 실패로 결과를 도출하기보다는 다른 사람이 Debrief (브리핑)
을 진행한다. 브리핑은 PROOF
를 기반으로 5가지가 확인되어야 한다. 1. Past (이력) - 세션 중 어떤 일이 있었는가. 2. Results (결과) - 세션 중 무엇을 달성했는가?, 3. Obstacles (장애물) - 좋은 테스트를 방해한 것들이 있었는가? 4. Outlook (예측) - 어떤 것들이 더 이루어져야 하는가?, 5. Feelings (느낌) - 수행자는 이 결과에 어떻게 느끼는가?
이러한 브리핑 방식으로 테스트가 더 필요한지, 현재의 소프트웨어 퀄리티가 만족스러운지를 사용자의 입장에서 파악할 수 있다. 하지만 이러한 방식이 기본적으로 보통 자유롭게 행해지는 탐색적 테스트에 너무 많은 관료 행위가 적용되는 것이 아닌가 하는 우려가 있을 수 있다. 여기서 조심해야 할 부분은, 테스트 관리 방식은 수직적이 아닌, 수평적인 방식으로 이루어져야 하며, 어느 누구도 수행할 수 있으며, 어느 누구도 브리핑을 진행할 수 있다. 이러한 부분에서 자유로워야 탐색적 테스팅의 기반을 제대로 유지함과 동시에 관리라는 것을 할 수 있을 것이다.
'👨🏻💻 QA이야기 > ⚙️ Quality Engineering' 카테고리의 다른 글
왜 QA의 연봉은 오르지 않는가 💰 (2) | 2020.05.08 |
---|---|
피해야 할 6가지 QA의 성향 🧍 (1) | 2020.05.03 |
기술적 전략에서 🤼 팀 능력 전략으로 (0) | 2020.04.27 |
알고리즘과 휴리스틱의 차이 💡 (0) | 2020.04.24 |
한국에선 왜 🏆 ISTQB 자격증에 목메는가 (0) | 2020.04.21 |
댓글
이 글 공유하기
다른 글
-
왜 QA의 연봉은 오르지 않는가 💰
왜 QA의 연봉은 오르지 않는가 💰
2020.05.08🤔 왜? 국내 IT 인력의 연봉은 꾸준히 올라가고 있다고 한다. 개발자의 연봉이 3천만 원대에서 5천만 원, 7천만 원대로 쭉쭉 상승해가고, 해외 대기업 출신 스타 개발자들이 연봉 1, 2억을 받는 동안, QA의 연봉은 제자리걸음이다. 오히려 테스터의 포지션이 더 많고, QA가 테스터 대우를 받으며 연봉이 낮아져 가고 있다. Quality란 분명 어떤 제품에서도 뺄 수 없는 중요한 것임에도 불구하고, 그것을 담당하고 이끌어 나아가는 QA의 위치는 매우 산만하고 불안정하며, 대우 또한 하락하고 있다고 볼 수 있다. “좋은 QA를 찾기는 어렵다”라고 말하는 회사들은 봤어도, 그에 맞는 대우를 해주는 곳은 없다. 해외에서 QA 연봉은 개발자와 같은 레벨이다. 그만큼 중요하다는 것을 인지, 그에 맞는 대우를 하… -
피해야 할 6가지 QA의 성향 🧍
피해야 할 6가지 QA의 성향 🧍
2020.05.03☑️ 수행자 유형 어떤 사람은 수동 테스트 스크립트를 실행하고 완료되면 확인하는 것을 좋아한다. 테스트의 통과 결과를 보고 만족감을 느끼는 것이다. QA가 테스터 취급을 받으며 가장 쉽게 빠지는 유형이기도 하다. 이러한 사람들은 간혹 소프트웨어가 어떻게 작동하는지 제대로 이해하지 못하는 경우를 특히 신경 쓰지 않는다. 단순히 테스트의 시간 내 완료 상태 그리고 결과에 만족한다. 테스트를 하는 소프트웨어를 이해하지 못하고 테스트 스크립트만 실행한다면, 중요한 버그가 누락되는 경우가 생기곤 하며, 이를 찾아내면 테스트 스크립트를 추후에 업데이트한다. 조금 이상한 현상을 보더라도, 스크립트에 명시되어있지 않다면 그냥 넘어가게 되는 이상현상 정도로 인지 할 뿐이며, 분석은 다음으로 넘긴다. 이것은 QA가 아닌 … -
기술적 전략에서 🤼 팀 능력 전략으로
기술적 전략에서 🤼 팀 능력 전략으로
2020.04.27⚙️ 기술적 전략은 Adjust - 때에 맞춰 변화시키는 것 테스트 전략을 수립한다고 하면, 보통 어떠한 방법론, 기술을 언제 그리고 어떻게 적용할 것인가가 대부분 초점에 맞춰진다. 그리고 그 기술적 전략에 맞게 사람들이 배치되게 된다. 기술적인 부분은 그때마다 가장 적절한 전략이 수립된다. 프로젝트 또는 스프린트 내에서의 소프트웨어 내에 변경될 범위, 크기, 안전 위험 분석 등을 바탕으로 테스트 전략을 맞춰 계획하고, Regression (회귀) 테스트, Exploratory (탐색적) 테스트, User Acceptance (사용자 인수) 테스트, Smoke (스모크) 테스트 등 여러 가지 방법들을 알맞은 때에 실행하는 계획 등을 세운다. 이 부분은 QA 직군의 어느 정도 연차가 있다면 적어도 어느 정… -
알고리즘과 휴리스틱의 차이 💡
알고리즘과 휴리스틱의 차이 💡
2020.04.24📋 테스트 케이스의 효율성 소프트웨어의 높은 Quality를 위해 테스트를 진행할 때, 테스트 케이스를 작성하여 이에 따라 테스트를 실행하고, 실패율로 품질을 측정하는 방식을 선택하는 회사들이 많다. 하지만 현재까지 제품의 모든 경우의 수가 고려되고 전부 테스트 케이스로 옮겨지는 것은 사실상 현실적으로 불가능하며, 이러한 부분은 따라서 수치로 계산되지 못한다. 그렇다면, 이러한 테스트 결과 수치가 소프트웨어의 품질을 증명한다고 할 수 있을까? 테스트 케이스는 시간이 지나며 제품의 기능이 발전하고 늘어날 수록, 같이 늘어난다. 그만큼 테스트 수행 시간도 늘어나기 때문에, 결국 부분적 회귀 테스트를 테스트 전략을 많이 선택한다. 이러다 보면, 오랫동안 건드려지지 않는 위험요소가 적은 부분도 있을 테고, 그 …
댓글을 사용할 수 없습니다.