ISTQB-MAT 공부 일지 1일차 - 소프트웨어 테스팅의 기초(1)

갑자기 회사에서 2023년도 1분기/상반기 KPI를 적어서 제출하라고 하네,, 다른 부서들은 수치상으로 보여줄만한 것들이 많을텐데 QA는 이슈 줄이는 것 말고는 마땅히 적을게 없어서 자격증 취득과 파이썬 개발 공부하기로 적어냈다. 아무튼 그래서 앞으로 한달은 공부해야 되는 이 개발조무사의 운명ㅠ.. ISTQB 모바일에 대해서 따로 출판되는 문제집은 없고, 기존 ISTQB에 모바일 도메인 특성을 결합한 형태의 문제를 자주 낸다고 하더라. 아무튼 나 상반기에 ISTQB-MAT 자격증 취득해야하는 상당한 부담감 느끼고 있는 중,, 회사 생활 쉽지않다. 정말 ㅎ..

---

사실상 말이 소프트웨어 테스팅의 기초지, 은근 헷갈리는 문제 많고 까다로운 섹터 같음. 아래부터는 혼잣말에 가까울 수 있다주의.. 그,, 메모하면서 해야 (그나마) 기억 잘하는 친구들 있잖아,, 그게 나라는 말쑴..

 

아래 문제는 그냥 문배(문제로 배우는 소프트웨어 테스팅II) 풀면서 혼자 메모한거..

 

1) 소프트웨어 품질 >

 

품질 뭐,, 실생활에서는 별 생각 안하고 쓰는 뜻이긴 하나 QA 입장에서 엣헴,, 품질이라 함은,, 명시된 요구사항을 충족 시키는 정도가 되겠다. 요건 실무에서도 많이 느끼긴 하는데 아무튼 명세, 즉 기획서에 대한 커버리지 충족이 주 타겟이 되는 느낌으로다가 접근한달까..? 기획서 상으로는 뭔가 이상하다 싶어서 문의 정도는 해 볼 수 있겠지만, (e.g. 1+1 =3으로 나와있는데요?) 그걸 내가 오류 또는 결함이라고 단정지을 수 없다는거다. 왜냐면 QA에서 명시하는 품질 자체가 명세 기반이기 때문(e.g. 그거 기획의도인데요?하면 할 말 없다이거야..) + 사용자 또는 고객의 필요와 기대를 충족시키는 것도 품질의 범주에 포함된다.

---

2) 오류, 결함, 장애 >

 

이것도 진짜 지독히 나오는 단어 중 하나 같은데, 보통 사람들은 그냥 별 생각없이 부르는 말을 여기서는 확실하게 정리하고 가야한다.

 

오류는 일단 실수랑 같은 말이고, 굳이 해석하자면 잘못된 결과를 낳는 인간의 행위가 되겠다. 뭐,, 개발자가 코딩을 하던 중, 원래 한 번 입력해야 할 p를 두 번 입력하였다. 정도?

 

결함은,, 친구가 많다. 흔히들 얘기하는 버그, 결함, 결점 모두 같은 말이다. 요건 오류로부터 시작되고 그로 인해 요구된 기능을 적절히 처리하지 못하는 것? 정도가 된다. p를 두 번 입력하여 pp로 코딩되었을 때 실행문이 실행되지 않는 것. 정도가 결함의 범주에 포함된다.

 

마지막 끝판왕은 역시 결함이다: 결함은 장애라고도 불리는데 아무튼 모시깽이 저렇게해서 결국 최종적으로 발생하는 현상을 일컫는다. 실행문이 실행되지 않아 크래시(crash)가 발생, 또는 버튼을 눌러도 실행되지 않음. 정도가 된다. 진짜 헷갈리는데 자주 나오니 꼭 기억할 것. (물론 나 자신에게 하는 말)

---

3) 테스팅 종료 조건 > 

 

테스팅 종료 조건 요건 실무랑 동일한 것 같다. 근데 약간 말장난 때문에 헷갈리긴 하는데 배포(또는 릴리즈) 준비가 완료될 시점이 종료 시점이 된다. 대고객 서비스 오픈했을 때 문제가 되는 부분이 있는지 확인하는 절차. 흠,, '고객들이에게 오픈할 때 문제되는 부분이 있는지' << 이 부분 실무자로써 약간 말,, 할 말이 많긴 한데 참아야지,, 읍읍..

---

4) QA가 소스코드를 볼 수 있다고? >

 

개발자들의 소스코드(Source Code)도 QA가 산출물 리뷰를 해줄 수 있다고 하네,, 졸 충격적;; 이건 월요일에 출근해서 개발자들한테 물어봐야겠다.. "멈뭄미 개발자님,, 제가 소스코드를 보고 산출물 리뷰 해줄 수 있는 부분이 있나요? QA책에서는 가능하다던데요..?" ㅎ.. 결코 내가 틀린 문제라 웅엥거리는게 아니야..

---

5. 효과성과 효율성 >

 

QA에서 말하는 효과성과 효율성에 대해 늘 헷갈린다. 그래서 효과는 커버리지 개념으로 접근했고 효율은 시간적인 개념으로 접근했다. 이게 맞나? 싶은데,, 혹시 잘못 알고 있다면 천재 QA님들께서는 과감히 댓글 달아주심 고마울 것 같아요.. 그러니까 효과성은 시간이나 가용 리소스보다는 실제 얼마 많은 양을 커버하고 오류를 줄이는데 목적을 둔 테스팅이고, 효율성은 시간이나 인력 등의 리소스에 조금 더 치중한 테스트 방법론이라고 이해하고 있음.

- 효과 > 계획했던 것을 얼마나 목적대로 창출하는지? 

- 효율 > 우웅,, 계획도 중요하긴 한데,, 상황에 맞춰 리소스 배치도 중요해;

---

7. 테스팅의 목적 > 

 

테스팅의 목적은 뭐 이런저런 이유 다 가져다가 붙일 수 있는 것 같음. 근데 헷갈리게 '~의 원인 식별' 과 같은 것들이 붙기도 하는데, 대부분 원인들은 우리 QA들이 찾는다기보다는 개발자분들이 찾아주시는 경우가 많다. 물론 재현스탭이야 우리가 찾아 개발자에게 전달해주는건 맞지만, 원론적으로는 어떤 이유나 요인(factor)을 찾는게 '원인을 찾는' 행위에 포함되기 때문에 원인은 개발자들이 찾아줘야 함 ㅎ.. 

---

10. 확인 테스팅과 리그레션 테스팅 > 

 

우선 리그레션 테스트는 실무에서 정-말 많이 쓰이는 테스트 중 하나다. 말 그대로 a라는 이슈를 수정하면서 다른 영역에 사이드 이펙트가 발생하지 않았는지를 체크하는 일종의 요약테스트? 정도다. 실제 일하면서 어 여길 수정했는데 왜 저기서 이슈가 발생하지? 라는 생각을 참 많이 하고 또 겪는데, 그래서 리그레션 테스트는 QA들에게는 선택이 아닌 필수로 진행하는 테스트 중 하나다.

 

확인 테스트는 얼핏 들으면 느낌은 리그레션 테스트와 비슷한데,, 전체적으로 테스트하는게 아닌, 수정된 영역을 다시 재확인하는 테스트라고 보면 된다. 위 예시에 비유하자면 '수정된 a이슈를 재확인하는 절차' 정도로 해석할 수 있을 것 같다. 이거 매일하는건데 말이지,,

---

11. 테스팅의 일곱가지 원리 > 

 

이거 무슨 일곱가지 죄악도 아니고 잊을만 하면 등장하는 내용인데, 사실 십계명마냥 줄줄이김밥 외울 필요는 없다. STEN이 주관하는 ISTQB 시험은 객관식으로 출제되는 문제인만큼 '~ 케이스는 요거에 속한다.' 정도만 알고 있음 될듯. 헷갈릴 것도 없고,,

 

1. 테스팅은 결함이 존재함을 밝히는 활동

2. 완벽한 테스팅은 불가능

3. 개발 초기에 테스팅

4. 결함은 집중 

5. 살충제 패러독스

6. 테스트는 정황에 의존적

7. 오류-부재의 궤변

 

2345는 한 번에 이해가 되는데, 1,6,7은 뭔소린가 싶기도 하다. 6번 정황에 의존적은 코난도 아니고 뭔데 정황에 의존한다는거지,, ㅎ.. 1번은 결함이 발견되지 않았더라도 해당 소프트웨어에 결함이 없다고는 할 수 없다.라는 의미로 해석하면 되고,, (사실상 2번과 비슷한 느낌) 6번은 테스트 방법은 테스트 주체에 따라 다른 방법론으로 접근할 수 있다는 말이다. 뭐 은행 소프트웨어와 게임 소프트웨어를 같은 테스트 방법론으로 접근할 필요는 없지. 마지막 7번은 개발된 프로그램이나 소프트웨어를 사용자가 찾지 않는다면 결함을 찾는 행위 또한 필요하지 않다. 라는 말. 생각해보면 내가 만든 앱이든 뭐든 쓰는 사람 아무도 없으면 뭐하러 QA를 하겠너,,

---

16. 완벽한 테스팅이 불가능한 이유 > 

 

무한경로, 무한타이밍(순서), 무한입력값 때문. 대충 비슷한 말 같은데 특히 타이밍은 실무에서 진짜 많이 체감한다. 아무튼 무한도전도 아니고 요 3가지 때문에 완벽한 테스팅이 불가능하다고 함

---

17. 살충제 패러독스

 

살충제 패러독스. 살충제의 역설 정도일려나. 그러니까 bug를 잡기위해 testcase라는 살충제를 도입했는데, 같은 살충제를 계속 사용하다보니 bug들이 면역이 생겨 더 이상 잡히지 않는다. 정도로 해석할 수 있을듯. 그래서 testcase는 가급적 재사용하지 않아야하고(확인 범위가 과거와 동일하다면 사용해도 됨) 추가 테스트 및 확장된 영역의 테스트 시에는 수정하여 사용해야 한다는 의미다. 하지만 현실에서 강한 살충제 뿌리면 벌레들도 내성 강해져서 잘 안죽던데,, 자강두천 같은 뭐 그런 느낌이야뭐야,,

---

18. 테스트 프로세스(짱짱 중요...)

 

이 부분 정말 헷갈려 죽어ㅠ.. 하지만 제대로 안외우면 시험 때마다 항상 나와서 당연히 먹고 들어가줘야 할 점수 다 놓치게 됨. 일단 순서 외우는 것부터 ...

 

1. 계획과 제어

2. 분석 및 설계

3. 구현 및 실행

4. 완료 조건 평가 및 리포팅

5. 테스트 마감 활동

 

사실 계획과 제어는 순서도 상으로 1번에 위치하지만 테스트 마감 활동까지 전반에 걸쳐 수행되는 친구들이다. 그래서 계획과 제어아래 2>3>4>5 순으로 테스트가 진행된다고 보면 될듯. 어휴 이 내용 다시 생각만 해도 너무 숨막히는 부분.. 요건 다음 편에 적어야지..