두명 세명 네명 .. 너도 이미 정수 숫자라는 형식이라고 가정하고 생각하고있네
그게 기본이고 그걸 기본으로 생각하고 만드는데,
생각지도 못 한 인풋때문에 에러가 생길 수 있으니 다른 형식도 고려를 해야한다는말
강도가 0.1명 -1명
강도는 사실 존재하지 않음, 임포스터였음
강도대신 강아지가 들어온다던가
같이
한 QA가 하라는 검수는 안하고 하루종일 치마 밑 빤쓰를 볼 수 있는 각도만 연구한 끝에, 사실 빤쓰가 구현돼있지 않다는 사실을 발견했다.
QA는 이 사실을 버그로서 리포트했고, 3D 담당은 그것이 사양서에 따른 것이라고 주장했지만, 기획자가 이를 보고는 모든 캐릭터 그래픽에 빤쓰를 넣을 것을 지시했다.
나는 이 이야기를 참 좋아한다.
13년차 QAE입니다. (원문의 저 테스트는 바운드리 테스트라고 부르죠. 대부분의 버그는 경계선상과 복합조건에서 나옵니다. 페어와이즈 기법을 사용하는 이유)
저건 뭐가 문제냐면....
SRS 및 SDS 문제입니다. (소프트웨어 요구사항 문서/소프트웨어 디자인 문서)
개발자는 요구사항대로 만들어주는 거에요, 뭔가 더 붙는다면, 그 디자인 하는 사람과 리뷰를 통해서 넣는거에요. 그것도 그다지 좋은 경향은 아니죠.
QA는 대체적으로 SRS 문서대로 TCL를 만듭니다. 그외의 10~20%정도를 그외 사항을 더 넣을까 하다가 넣는거에요.
다 앞단의 작업인데, 대부분 가장 신경 안쓰죠. 심지어 SRS 문서가 제대로 구비조차 안된 회사가 대부분이라고 보시면 됩니다. 그래놓고 QA한데 모든 책임을 다 구겨넣죠.
권한이라도 많이주던가. 권한도 안주고 시간도 안주면서 책임은 다 우겨넣어.
개발자도 개발자대로 SRS 물어보러가면 제대로 안되어 있어서 지가 창작하고 있는 상황.
그리고 많은 개발자와 SRS/SDS 문서 제작자가 간과하는 건데.
되는건 당연히 되야 하는거고
안되는걸 안되게 하는 건 되게 중요합니다. <--- 무한의 테스트 케이스가 되게 만드는 주범중 하나
안되는 게 되는 경우도 있는데 이것도 마찬가지입니다.<-- 이게 흔히 말하는 버그성 플레이..
프로그래머 특징 : 과거의 나가 지금의 나보다 똑똑할 수도 있음
내가 짜놓고도 주석 안달리면 뭔지 헷갈린다.
검수의 중요성이지. 그 뭐더라. 게임 출시 전에 검수해보는 사람들ㅋㅋ 뭣! 발매 전 게임을 미리 할 수 있다고? 신난다! (×) 네? 벽을 향해서 3시간동안 점프만 하라구요? (0)
QA 질의서 계획할때 주문한다는 코딩만 생각하고 다른걸 물어볼수 있다는건 생각 안한 결과. 길 물어보기 강도가 들어온다 갑자기 차가 문을 무수고 들어온다 등의 퀘스천도 생각했어야..
- 프로그래머 : 그래서 술집에 들어오면 무조건 int 범위에 포함되는 정수 개수만큼의 맥주만을 주문할 수 있게 제한을 걸었습니다 - 클라이언트 : 아니 난 술집에서 화장실을 가고 싶다구요 - 프로그래머 : 아무튼 버그는 없어졌죠
QA가 중요한 이유
그렇다고 과거의 내가 지금의 나보다 덜 ㅄ인것도 아님..
프로그래머 특징 : 과거의 나가 지금의 나보다 똑똑할 수도 있음
코코아맛초코우유
그렇다고 과거의 내가 지금의 나보다 덜 ㅄ인것도 아님..
부정할수가... 없다...
우와 이거 누가 만들었지....엣 수년전의 나..?
대충 시로아처짤
1년 지난 내 코드를 보고 내가 이렇게 똑똑했었나 놀라기도 함
나도 접기전에 만들어놓은 와우 매크로들 보고 똑같이 느꼈는데...
그치.. 그땐 머리가 팽팽 돌아가는 나이였고 체력도 좋았으니까 ㅠ
QA가 중요한 이유
내가 짜놓고도 주석 안달리면 뭔지 헷갈린다.
주석 달아놔도 헷갈린다. O
어둠의 QA로 유명한 연두를 고용하면 되겠네
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
화장실이 뭐지?? 이런건 정의된 적 없어!!!! 오 신이시여!!! 어찌하여 하늘은 맥주를 낳고 도마뱀을 낳고 화장실도 낳았단 말입니까!!!
QA 질의서 계획할때 주문한다는 코딩만 생각하고 다른걸 물어볼수 있다는건 생각 안한 결과. 길 물어보기 강도가 들어온다 갑자기 차가 문을 무수고 들어온다 등의 퀘스천도 생각했어야..
근데 그런식이면 강도가 들어온다 강도가 두명 들어온다 강도가 세명 들어온다 강도가 네명 들어온다 강도가 다섯명 들어온다 이런것도 다 생각해야 하는거 아냐???
강도가 들어온다는 개념 자체에 대한 예외처리가 필요하다는거 차가 문 부수고 온다는 사람 말고 다른 뭔가가 들어오는 경우에 대한 예외처리가 필요한거고
두명 세명 네명 .. 너도 이미 정수 숫자라는 형식이라고 가정하고 생각하고있네 그게 기본이고 그걸 기본으로 생각하고 만드는데, 생각지도 못 한 인풋때문에 에러가 생길 수 있으니 다른 형식도 고려를 해야한다는말 강도가 0.1명 -1명 강도는 사실 존재하지 않음, 임포스터였음 강도대신 강아지가 들어온다던가 같이
너무 간단해서 망가지는 경우가 많....출력같은 단순한거 제외하면
뭐 사실은 출력도 무슨 변수결과나 값 리턴에서 꼬인경우도 많았고...
대충 온라인 겜에서 인벤토리 꽉찬 상태에서 우편물을 받을시 벌어지는 상황 체크
우편물을 다시 보내게 하기 무한으로 우편을 받아 서버를 죽이기 우편을 조건부로 받게 하기 90개를 주는 우편을 인벤토리에 10개 채운 상태로 받아 1개를 증발시키기 결국 뭐 못하게 하는게 제일 쉬운 이유
맥주시키다 꽐라되는거보니 마시면서 테스트했구나!
검수의 중요성이지. 그 뭐더라. 게임 출시 전에 검수해보는 사람들ㅋㅋ 뭣! 발매 전 게임을 미리 할 수 있다고? 신난다! (×) 네? 벽을 향해서 3시간동안 점프만 하라구요? (0)
이거니까 ai 자동화 연구하는거임
요즘 자동화 연구 비용보다 사람이 싸서 외주 메타가 대세임....
간단한 방법(하면꼬임)
하지만... 서류 제출 용도로 파일 사이즈 제한을 300메가로 제한해서 만든 시스템을 A컴퓨터에서 B컴퓨터로 자료 옮기는 용도로 쓰는 사용자때문에 제한을 4기가로 늘려달라는 소리를 하잖아!!! 진짜 상상도 못했다고!!!
큰파일 용량이 안올라가요!라는 버그리포트가 왔을땐 내가 잘못본줄알았어!!!!
그건 버그가 아니라 요구사항이잖아!
그러니깐 그리고 심지어 처음 요구는 100메간가 그럈다고 ㅋㅋㅋㅋ
글고 솔까 회사에선 그정도 용량이면 usb나 하드 써서 옮기는게 맞음 ㅇㅇ... 자료전송시스템 따로 있어도 네트워크 대역폭 엔간히 거지같은데
안맞아. 우리회사는 보안프로그램이 usb 쓰기를 막아놨다고!
그건 보안usb안쓰는 회사가 문제인거에용 시발 1테라짜리 하나가 40만원이야
ㅋㅋㅋㅋ 넘 현실적이라 웃프다..
수정전 : 이 코드는 왜 이모양이지? 과거의 나란 녀석 ㅉㅉㅉ 수정후 : 아 ㅅㅂ 이래서 그랫었지
솔직히 소비자입장에서 생각해야한다 라는말이 제일 먼저 적용되야 할 분야라고봄 ㅋㅋㅋ
개발하다 보면 등뒤로 귀신이 슥 지나가는 느낌이 날때가 있음 그건 환상이 아님. 뭔가 ㅈ된걸 발견했는데 뇌가 구체적으로 처리 못한거임 찾아라!
- 프로그래머 : 그래서 술집에 들어오면 무조건 int 범위에 포함되는 정수 개수만큼의 맥주만을 주문할 수 있게 제한을 걸었습니다 - 클라이언트 : 아니 난 술집에서 화장실을 가고 싶다구요 - 프로그래머 : 아무튼 버그는 없어졌죠
??? : 안주도 시켰더니 터졌는데요?
int범위? uint가 아닌 벌 달게 받으라. 맥주 -10개 주세요!
qa는 원래 뜬금없는짓 잘 하는 사람 시켜야됨 내 코드 내가 테스트 하면 딱 의도에 맞게만 움직여서 버그 발견이 안됨 ㅋㅋㅋ
개발자 네 놈들은 주머니 속 상자에 물건을 넣어 소매치기하는 것을 넘겼지. 개발자 네 놈들은 주머니에 상자를 넣고 거기에 무건을 넣어 소매치기하는 것을 넘겼지. 개발자 네 놈들은.....
qa의 기본자세 : '이 새1끼들이 하라는대로 하기 싫어!'
왠 대머리가 화장실을 물어봐서 가게가 망했어요
아이 니드 뚜 유스 어 배쓰-룸.
그래서 난 코딩할 때 내가 정한 룰 외에 다른건 전부 안되게 해놨는데 아직 진짜 큰 규모나 오랫동안 서비스한 적은 없어서 저런 경험은 없음
그럼 이제 문을 통해서 손님이 아니라 적들이 나타납니다! 같은 이벤트 넣을때 대가리 부서짐
그런 경험을 하게되면... 생각해볼게...
100%이해는 안되는데 너무 확실한 예시라 존나 웃기네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이렇게 간단한 방법이 있는데 왜 이리 복잡하게 코딩하냐 → 컴파일하고 돌리는 순간 한 두 군데는 빠져있음
내가 만들 때 예상하지 못한 일들이 반드시 일어난다는 것만 이해하면 됨.
코드 짰는데 자기들끼리 얽혀서 오버플로우 일으키다가 정상작동하길래 어쨌든 혹시 모르니 수정해야지 하니까 그냥 냅두라던 사수가 생각난다
한 QA가 하라는 검수는 안하고 하루종일 치마 밑 빤쓰를 볼 수 있는 각도만 연구한 끝에, 사실 빤쓰가 구현돼있지 않다는 사실을 발견했다. QA는 이 사실을 버그로서 리포트했고, 3D 담당은 그것이 사양서에 따른 것이라고 주장했지만, 기획자가 이를 보고는 모든 캐릭터 그래픽에 빤쓰를 넣을 것을 지시했다. 나는 이 이야기를 참 좋아한다.
난 저렇게 해달라고 거래처 담당자에게 사정을 했는데 안해줌
결국 버그는 있을수 밖에 없고 검수도 결국 흘리는 부분이 있을수 밖엔 없음 사람이 하는일이 다 이렇지 뭐
저거 고치면 다음사람이 물달라함
QA는 흔히 ㄸㄹㅇ 기질이 있는 사람이 잘 하더라 ㅋㅋ
결국에는 UI에서 사용자가 생각하게 해서는 안됨 단호하게 이것만 할수 있게 해야하는데 어디ㅜ대표님이나 계획자가 이것도 되냐 저것도 되냐 이미 게임 뜬남
버그스낵스 게임에서 제작한 프로그래머랑 QA 담당자 데려다놓고 버그성 스피드런 영상 보여주는데 프로그래머가 '저게 왜 되지 ㅋㅋㅋㅋㅋㅋ' 하는데 옆에서 QA 담당자가 '아 저거 전에 찾았던건데 굳이 안 고쳐도 될거 같아서 말 안 했음'
손님에게 요강을 줘서 해결
대부분은 왜 그 '간단한 방법'을 아무도 시도하지 않았는지 생각해보려다가 그냥 '간단한 방법'을 쓰지 않기로 함.
예외처리는 프로그래밍의 기초중 기초인데 불이 왜나 그냥 에러내면 되지.
'그냥' 이 더럽게 어렵거든.
베타테스트라 불 다 끄고 다시 술집은 재부팅했다네요
13년차 QAE입니다. (원문의 저 테스트는 바운드리 테스트라고 부르죠. 대부분의 버그는 경계선상과 복합조건에서 나옵니다. 페어와이즈 기법을 사용하는 이유) 저건 뭐가 문제냐면.... SRS 및 SDS 문제입니다. (소프트웨어 요구사항 문서/소프트웨어 디자인 문서) 개발자는 요구사항대로 만들어주는 거에요, 뭔가 더 붙는다면, 그 디자인 하는 사람과 리뷰를 통해서 넣는거에요. 그것도 그다지 좋은 경향은 아니죠. QA는 대체적으로 SRS 문서대로 TCL를 만듭니다. 그외의 10~20%정도를 그외 사항을 더 넣을까 하다가 넣는거에요. 다 앞단의 작업인데, 대부분 가장 신경 안쓰죠. 심지어 SRS 문서가 제대로 구비조차 안된 회사가 대부분이라고 보시면 됩니다. 그래놓고 QA한데 모든 책임을 다 구겨넣죠. 권한이라도 많이주던가. 권한도 안주고 시간도 안주면서 책임은 다 우겨넣어. 개발자도 개발자대로 SRS 물어보러가면 제대로 안되어 있어서 지가 창작하고 있는 상황.
그리고 많은 개발자와 SRS/SDS 문서 제작자가 간과하는 건데. 되는건 당연히 되야 하는거고 안되는걸 안되게 하는 건 되게 중요합니다. <--- 무한의 테스트 케이스가 되게 만드는 주범중 하나 안되는 게 되는 경우도 있는데 이것도 마찬가지입니다.<-- 이게 흔히 말하는 버그성 플레이..
짜기만 하고 테스트를 제대로 못 하면 그건 프로그래머가 아니지 특히 내부 툴 같은거 아트 쪽에 넘겨주면 진짜 기상천외 하게 사용함 ㅋㅋ
난 어제도 느꼈음...내가 이걸 어떻게 짰지? 이해가 안돼 ㅋㅋㅋㅋㅋ
나도 생체인식 개발하면서, QA하면서 몇날몇일동안 내 생체정보로 만명중에 한명으로 오류 일으킬수 있는지 테스트했었음. 당연히 테스트 통과하고나서 아 생체인식기술은 믿을만하지 못하구나 싶어서 그후로 퇴사하고 지문인식을 비롯한 기술들을 신뢰하지않음....
그게 제조사,회사마다 다르겠지만, 통과율을 낮추면 통과를 못하겠지만 그랬더니 본인도 본인이라고 인증이 안되는게 10여차례 이상 발생하더라. 실제로 나도 주민센터가면 내 지문으로 내꺼 못뽑음. 20분동안 지문오류내고있었더니 이사람도 오고 저사람도 오면서 도우려고 하던데, 끝끝내 못함. 아마 주민센터는 통과라인이 높았던거 아닐까 싶음.
ㅈ같이 만들었네 하고 커밋한사람 보면 나임...
똥이 마려웠을 뿐인데 해커가 되어버린 천재를 아시오
클라:이게 뭘 의미하는 수치죠? 나:아 이거 뭐더라...
실제 사용자가 어떻게 사용할지는 예측이 불가능함
보통의 경우 프로그래머 : 왜? 그렇게 사용하지? 사용자 : 왜? 그렇게 안되지? 의 무한 반복.
사실 이건 비단 프로그래머 뿐만 아니라 디자인 엔지니어 입장에서도 출력 라인에 입력을 넣는사람과 맞지도 않는 보드를 강제로 밀어 넣어 핀을 다 휘어버리는 사람과 전기가 돌아가는 보드에 손을 대서 감전 당하는 사람을 모두 대체 해야 합니다.
QA가 항상 버그를 놓치는 이유는 그들은 본능적으로 버그가 재현될 감지하고 피하는 QA 센스를 가지고 있기 때문이다.
짤하고 본문 내용하고 전혀 딴 얘기를 써놨네