2009-12-07 2 views
0

나는 클라이언트 용 건물 웹 사이트가 있습니다. 나는 지금 나와 함께 프로젝트에 대한 테스터를 가지고있다.테스터는 무엇을보고해야합니까?

나는 테스터가 필요하다고 느낍니다. 정말! 내 코드를 테스트 할 수 없습니다. 나는 또한 눈의 새로운 세트의 가치에 감사드립니다. 그러나보고를 원하는 것은 무엇입니까?

모든 것이보고되어야한다고 말하기는 쉽지만 중요하지 않은 요청을 걸러 내기 위해 나와 나와 테스터 사이에 사람이 없습니다. 테스터는 시스템이나 대상 사용자를 잘 알지 못합니다. 그녀는 나에게 프로젝트 매니저가 아니라 태스크를 할당하고있다. 나는 이것이 곧 바뀔 것이라고 생각하지만 그것이 이루어지기까지, 당신은 무엇을 추천합니까? 우리 사용자들은 전에도 interent를 전혀 사용하지 않았으며, 바위처럼 바보 같다고 믿는 것 같습니다.

내가 겪고있는 문제는 테스터가 제안하는 모든 것이 자동으로 받아 들여지고 나에게 할당된다는 것입니다.

나는 내 턱을 떨어 뜨리고 "정말로? 너 진심이야?이게 문제가 되니?"라고 말하는 많은 경우가 있습니다.

예 : 필수 입력란에 "* = Required"라고 표시된 페이지 상단에 텍스트를 추가해야합니다.

혹시 이런 느낌이 들었습니까? 그걸 어떻게 다뤘 니?

지금은 말씀 드린대로하고 있지만 분명히 동의하지 않습니다.

+3

나는 위선적 인 말이지 만, "꼭 필요한 필드에"* = Required "라고 쓰여있는 페이지 상단의 텍스트가 필요합니다." 좋은 버그보고 같은데. 모든 사용자가 작은 별표가 무엇을 의미하는지 알지 못합니다. 소프트웨어를 사용하는 미숙련 사용자가 항상있을 것이므로 사용자는이를 수용해야합니다. – Glen

+3

테스터를 데려온 이유를 알고 계십니까? – DOK

+0

우리는 프로세스를 변경하고 있습니다. 모든 프로젝트의 모든 코드는 개발 그룹 외부의 사람이보기 전에 테스트됩니다. –

답변

5

테스터가 옳은 일을하는 것처럼 들립니다. 응용 프로그램을 테스트 할 때 어떤 수준의 사용자 전문 지식도 가정 할 수 없습니다. 사용자가 무언가를 깨뜨릴 수 있다면 그렇게 될 것입니다.

귀하와 귀하의 테스터는 심각도 척도를 산출해야합니다. 특이 사항 (인터넷 경험이있는 사람이라면 누구나 사용할 수있는/절대로 안타를 것입니다)은 우선 순위가 낮은 항목을 두 드릴 때까지 낮은 우선 순위로 간주되어 뒤쪽 버너에 앉습니다.

... 절대 외계인은 기록에 남아 있어야합니다. 왜냐하면 그들은 결국 엉덩이에서 당신을 물지 않기 위해 돌아올 수 있기 때문입니다.

+0

감사합니다. 나는 조금은 아기가되고있는 것 같아. 모든 우선 순위가 완료되며 다른 프로젝트로 넘어 가고 싶습니다.변경 사항을 작성하는 것보다 수정 사항을 문서화하는 데 더 오래 걸립니다. –

+0

럭키! 나는 그와 같은 몇 가지 더 많은 일이 있었으면 좋겠다. – Nathan

0

시간과 비용면에서 각 변경 사항에 대해 고객에게보고 할 것입니다. 합법적 인 버그 인 경우 (계약서에 달리 명시되어 있지 않는 한) 필요할 때마다 수정해야 할 수도 있습니다. 설계/주관적인 문제로 비용을 할당 할 수 있어야합니다. 고객에게 비용이 들게 될 것을 알게하고 진행 여부를 결정할 수 있습니다.

프로젝트가 완료된 시점과 프로젝트 범위에 포함되지 않은 사항을 알기 위해 클라이언트가 서명 한 프로젝트 사양이 있습니다. 그렇지 않다면 손에 약간의 싸움이있을 수 있습니다. 프로젝트 범위 밖에 있다고 생각되는 변경 사항에 대해서는 타협해야 할 수도 있습니다. 비용을 저렴하게 청구하거나 비용을 분할 할 수 있습니다. 이러한 상황에 처한 경우 프로젝트 사양에 문서화 된 모든 것을 얻는 것이 좋은 학습 경험이므로 프로젝트 범위 밖의 내용에 대해서는 의문의 여지가 없습니다. 나는 그곳에 가봤습니다 -이 한 번의 경험은 당신이 당신의 사양에 더 많은 작업을 할 수 있도록 가르쳐주기에 충분합니다.

+0

그냥 변경하는 것보다 추정하는 것이 더 오래 걸립니다. 진짜 문제는이 프로젝트를 끝내고 끝내기를 원한다는 것입니다. 귀하의 답변에 감사드립니다. –

2

문제의 우선 순위를 추가해야합니다. 이렇게하면 중요한 문제를 먼저 처리 할 수 ​​있고 미용 문제는 지속될 수 있습니다.여기 락스에서 예를 들어 우선 순위입니다 :

  • 우선 순위 1 - 재현 충돌; 특정 기능의 추가 테스트 또는 개발을 차단하는 문제. 사용자의 영구 데이터 손실 거대한 메모리 누출
  • 우선 순위 2 - 제품 출시 전에 해결해야 할 주요 문제. 사용자가 기능을 사용할 수 없게합니다. 파트너에게 부정적인 영향을 미친다. 자주 사용하는 기능에서 중요한 메모리 누수가 발생합니다.
  • 우선 순위 3 - 제품 출시 전에 수정해야하는 사소한 문제. 사용자가 제품을 사용하는 것을 방해하지는 않습니다. 매우 눈에 띄는 유용성 문제; 거의 사용하지 않는 기능에서 메모리 누수가 적습니다.
  • 우선 순위 4 - 완전히 외형적인 문제입니다. 기능에 영향을주지 않습니다
0

모든 것을 알리고 분류합니다. 약간의 시간이 지나면, 그녀는 과거의 선별 검사와 그렇지 않은 검사를 이해하기 시작할 것입니다. 인간은 배울 수 있습니다. 가르치다.

1

실제로 테스터가 올바른 것을하고있는 것처럼 들립니다. ("* = required"는 매우 좋은 아이디어입니다.)

보고서의 우선 순위에 대한 제안 외에도 사용자 경험이나 기능을 언급하는지 여부에 대한 보고서를 분류하는 것이 좋습니다.

1

당신과 테스터는보고 할 필요가있는 것에 정확히 동의하지 않습니다. 문제에 대한 우선 순위를 올바르게 설정하고 우선 순위가 높은 항목을 먼저 수정하십시오.

절대적으로 원하지 않는 한 가지는 테스터가 버그를 제기하지 못하게하는 것입니다. 그것은 배가 무언가가 완전히 망가 졌을 때 당신을 물으러 돌아올 것이고, 그들은 "그것이 그것이 어떻게 효과가 있었는지 생각했습니다"라고 말합니다.

개발 일정 및 상태를 제대로 전달하고 있으므로 테스트가 완료되지 않은 기능을 테스트하는 데 시간을 낭비하지 않아야합니다.

관련 문제