Terms
Error guessing, independence.
Background
the mindset to be used while testing and reviewing is different to that used while developing software With the right mindset developers are able to test their own code, but separation of this responsibility to a tester is typically done to help focus effort and provide additional benefit. such as an independent view by trained and professional testing resources. Independent testing may be carried out at any level of testing.
A certain degree of independence (avoiding the author bias) is often more effective at finding defects and failgures. Independence is not, however, a replacement for familiarity, and developers can efficiently find many defects in their own code. Several leveles of independence can be defined:
- Tests designed by the person(s) who wrote the software under test (low level of independence).
- Tests designed by another person(s) (e.g. from the development team).
- Tests designed by a person(s) from a different organizational group (e.g. an independent test team) or test specialists (e.g. usability or performance test specialists).
- Tests designed by a person(s) from a different organization or company (i.e. outsourcing or certification by an external body).
People and projects are driven by objectives. Perople tend to align their plans with the objectives set by management and other stakeholders, for example, to find defects or to confirm that software works. therefore, it is important to clearly state the objectives of testing.
Identifying failures during testing may be perceived as criticism against the product and against the author. Testing is, therefore, often seen as a destructive activity, even thought it is very constructive in the management of product risks. Looking for failures in a system requires curiosity, professional perssimism, a critical eye, attention to detail, good communication with development peers, and experience on which base error guessing.
if error, defects or failtures are communicated in a constructive way, bad feelings between the testers and the analysts, designers and developers can be avoided. This applies to reviewing as well as in testing.
The tester and test leader need good interpersonal skill to communicate factual information about defects, progress and risks, in a constructive way. For the author or the software or document, defect information can help them improve their skills. Defects found and fixed during testing will save time and money later, and reduce risks.
Communication problems may occur, particularly if testers are seen only as messengers of unwanted news about defects. However, there are several ways to imporove communication and realationships between testers and others.
- Start with collaboration rater than battles. "remind everyone of the common goal or better quality systems."
- Communicae findings on the product in a neutral, fact-focus way without criticizing the person who created it, for example, write objective and factual incident reports and review findings.
- Try to understand how the other person feels and why they react as they do.
- Confirm that the other person has understood what you have said and vice versa.
용어
에러 추정, 독립성
배경
테스팅과 리뷰 과정에서의 사고 방식은 소프트웨어의 개발의 사고 방식과 다르다. 적절하고 객관적인 사고 방식을 지닌 개발자는 자신의 코드를 테스트 할 수 있다.
그러나 개발자가 이런 책임을 테스트 엔지니어로부터 분리하는 것은 개발 활동에 집중하는데 도움이 되고, 교육받은 전문적인 테스팅 리소스 또는 전문가가 독립적인 시각을 제공하기 때문에 추가적인 장점이 있을 수 있다. 독립적인 테스팅은 테스트 레벨 어디에서나 적용 가능하다.
일정 수준의 독립성 확보는 (작성자의 편견을 줄이면서) 결함과 장애를 찾아내는데 보다 효과적이다. 그러나 독립성이 의미하는 바가 테스스트 제품을 잘 알면 안되는 의미는 아니다.
독립성이 낮은 개발자도 효율적으로 자신의 코드에 있는 많은 결함을 발견할 수 있다.
테스트의 독립셩을 몇 단계로 정의해 보면 다음과 같다.
- 테스트 중인 소프트웨어의 작성자가 설계한 테스트 (독립성 낮음)
- 다른 사람이 설계한 테스트 (예, 개발팀 내외)
- 독립적인 테스트 팀과 다른 그룹의 인원 또는 테스트 전문가가 설계한 테스트 (예, 사용성 또는 성능 테스트 전문가 등)
- 다른 아웃소싱 회사 소속의 인원이 설계한 테스트 (에, 외부적인 조직에 의한 인증, 아웃소싱)
일반 사람들과 마찬가지로 테스터들도 그들의 계획을 테스트 관리자나 다른 관련자가 설정해 놓은 목표 (예, 결함 발견 또는 소프트웨어 동작의 확인 등)와 일치하려는 경향이 있다.
그러므로 테스팅의 모표를 명확하게 정의하는 것이 테스팅을 성공적으로 수행하는데 있어 중요한 위치를 차지한다.
테스트 과정 동안에 장애를 식별하는 거은 테스트 대상 제품을 비평하거나 작성자에 대해 비평하는 것으로 간주될 수 있다. 그런 이유로 테스팅의 제품의 리스크(Risk) 관리 측면에서 매우 건설적인 활동임에도 불구하고, 종종 파괴적인 활동으로 여겨진다. 시스템에서 장애를 찾아내는 능력은 호기심, 전문적인 비평, 비판적인 사고, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험을 필요로 한다.
오류나 결함, 장애가 건설적인 방법으로 의사소통이 되면, 테스터와 개발자(분석가, 설계자) 간에 발생할 수 있는 감정 악화를 피할 수 있다. 이것은 테스팅 뿐만 아니라 리뷰 과정에서도 그대로 적용된다.
테스터나 테스트 리더는 결함이나 테스트 진행 상황, 리스크 요소에 대한 사실적인 정보를 건설적인 방법으로 현명하게 전달할 수 있는 좋은 대인 관계가 필요하다. 결함 정보는 소프트웨어나 문서의 작성자가 해당 관련 기술을 개선하는데 도움을 줄 수 있다. 테스팅 기간 동안 결함을 발견하고 수정하는 것은 향후의 시간과 비용 절감을 가능케 하고, 리스크 요소를 줄여준다.
테스터가 결함을 지적하는 불쾌한 소식만을 전하는 것으로 비춰지는 것은 걸설적인 대인관계 형성에 매우 위험하다. 테스트는 다른 관련 인원 간의 의사소통과 친분을 개선할 수 있는 몇가지 방법은 다음과 같다.
- 다툼보다는 협력으로 시작한다. "더 나은 품질의 시스템을 개발하고자 하는 공통적인 목표를 모든 사람에게 주지시킨다."
- 소프트웨어를 개발한 사람에 대한 비평 없고 중립적이고 사실에 근거하여 제품에서 찾아낸 사항을 전달한다. 예를 들어, 객관적이고 사실적인 결함 리포트를 작성하고 찾아낸 사항을 리뷰한다.
- 다른 인원이 어떻게 느끼는지 왜 그렇게 반응하는지 이해하도록 노력한다.
- 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다.