More actions
imported>ccang8 ({CREATE}) |
No edit summary |
||
| Line 1: | Line 1: | ||
~~멍청하게 혼자 기획한 부회장과 그를 까기 위한 급조된 TF(라 읽고 거지같은 동기들이라 부른다)들의 모임~~ | |||
__TOC__ | |||
= 입출력 방식이 제각각인 것에 대한 대처 = | |||
* 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음. | |||
* 채점 | * TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음. | ||
= 출제자는 문제 상황에서 정확하게 동작하는 샘플 Program을 만들어야 한다 = | |||
* 부회장: 나중에도 말하겠지만, 손으로 검증할 수 있는 수준의 문제라고 생각해서 설마 준비한 테스트 케이스가 틀렸을 거란 걸 생각도 못한... | |||
* TF: 문제 출제자도 아니라서 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함. | |||
= 다른 사람에게 test case 제작을 맡기고 돌려서 검증 = | |||
* 부회장: 나는 테스트 케이스를 만들어보라고 요청했던 TF가 전부 내가 그 전에 문제 검증을 부탁했던 TF였다. 그래서 문제에 대한 이해도는 있을 줄 알았고, 각자가 만든 테스트 케이스는 각자 들고 다니면서 채점 용도로 쓸 거라고 말해줘서 자기가 사용할 테스트 케이스니까 정확한 테스트 케이스를 만들 것이라고 생각하고 테스트 케이스 제작을 부탁했다. 그리고 TF로부터 불완전한 테스트 케이스를 받았는데 검증할 수 있는 시간이 부족했다. | |||
* TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다. | |||
* 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다. | |||
= 테스트 자동화 -> 출력 형식이 엄격해야한다 = | |||
* 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남. | |||
= 출제자의 의도를 분명히 사전에 전달 = | |||
* 출제자가 타임 어택을 | |||
= 이런 의도를 TF가 확실히 공유 받고 참가자에게 전달해야함 = | |||
테스트 케이스 | * 사전 교육이 중요함. 주최자가 생각하는 진행 방식을 TF가 미리 알고 있어야 함. | ||
= 제출 방식 -> 이번 방식은 위키에 올렸는데, 좀 문제가 있음 = | |||
= TF 적절한 수로 해야됨 = | |||
= 문제의 난이도 = | |||
* 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다 | |||
* 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다. | |||
* 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ) | |||
= 튜터는 어느정도까지 관여 = | |||
* 처음에는 튜티들의 공평한 경쟁을 위해서 튜터가 최대한 관여를 안하는게 낫다고 생각했는데, 이번 대회의 의도는 서로 협력하는 게 의도였기 때문에 튜터의 지시에 제한을 거는 것은 문제가 있다고 판단함. | |||
* | |||
= 비공개된 테스트 = | |||
* 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...) | |||
* 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 두 가지 조건이 만족되어야 한다. | |||
# 제출 시간을 기록할 수 있을 것 | |||
# 다른 팀이 볼 수 없어야 함, 수정도 불가 | |||
= 결론 = | |||
* 문제가 코드가 길어지고 어려울수록 대회 전에 TF 많이 뽑아서 기획해야함... 그렇지 않으면 위의 문제가 발생할 수 있음. 그리고 언제나 대회의 의도는 모두가 미리 공유하고 있어야 함. | |||
------------------------------------------------------------------------------------------------------------------- | |||
[[CodeRace]] [[CodeRace/2016]] | |||
테스트 | |||
Revision as of 03:44, 21 May 2016
~~멍청하게 혼자 기획한 부회장과 그를 까기 위한 급조된 TF(라 읽고 거지같은 동기들이라 부른다)들의 모임~~
입출력 방식이 제각각인 것에 대한 대처
- 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음.
- TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음.
출제자는 문제 상황에서 정확하게 동작하는 샘플 Program을 만들어야 한다
- 부회장: 나중에도 말하겠지만, 손으로 검증할 수 있는 수준의 문제라고 생각해서 설마 준비한 테스트 케이스가 틀렸을 거란 걸 생각도 못한...
- TF: 문제 출제자도 아니라서 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함.
다른 사람에게 test case 제작을 맡기고 돌려서 검증
- 부회장: 나는 테스트 케이스를 만들어보라고 요청했던 TF가 전부 내가 그 전에 문제 검증을 부탁했던 TF였다. 그래서 문제에 대한 이해도는 있을 줄 알았고, 각자가 만든 테스트 케이스는 각자 들고 다니면서 채점 용도로 쓸 거라고 말해줘서 자기가 사용할 테스트 케이스니까 정확한 테스트 케이스를 만들 것이라고 생각하고 테스트 케이스 제작을 부탁했다. 그리고 TF로부터 불완전한 테스트 케이스를 받았는데 검증할 수 있는 시간이 부족했다.
- TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다.
- 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다.
테스트 자동화 -> 출력 형식이 엄격해야한다
- 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남.
출제자의 의도를 분명히 사전에 전달
- 출제자가 타임 어택을
이런 의도를 TF가 확실히 공유 받고 참가자에게 전달해야함
- 사전 교육이 중요함. 주최자가 생각하는 진행 방식을 TF가 미리 알고 있어야 함.
제출 방식 -> 이번 방식은 위키에 올렸는데, 좀 문제가 있음
TF 적절한 수로 해야됨
문제의 난이도
- 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다
- 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다.
- 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ)
튜터는 어느정도까지 관여
- 처음에는 튜티들의 공평한 경쟁을 위해서 튜터가 최대한 관여를 안하는게 낫다고 생각했는데, 이번 대회의 의도는 서로 협력하는 게 의도였기 때문에 튜터의 지시에 제한을 거는 것은 문제가 있다고 판단함.
비공개된 테스트
- 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...)
- 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 두 가지 조건이 만족되어야 한다.
- 제출 시간을 기록할 수 있을 것
- 다른 팀이 볼 수 없어야 함, 수정도 불가
결론
- 문제가 코드가 길어지고 어려울수록 대회 전에 TF 많이 뽑아서 기획해야함... 그렇지 않으면 위의 문제가 발생할 수 있음. 그리고 언제나 대회의 의도는 모두가 미리 공유하고 있어야 함.