- Mistake
- Anomaly
- Fault
- Failure
- Error
- Exception
- Crash
- Bug
- Defect
- Incident
- Side effect
T.B.D
- Mistake
- Anomaly
- Fault
- Failure
- Error
- Exception
- Crash
- Bug
- Defect
- Incident
- Side effect
T.B.D
항상 소프트웨어는 Defect를 가지고 있다 그렇다면 원인은 무엇일까?
지금 읽고 있는 testingexperience 잡지에 정의하고 있기로는 아래 사항들에 의해서 Defect이 일어난다고 한다.
- 잘못된 의사소통
- 정확하지 못한 기술들
- 복잡한 기술
- 프로그래밍 에러
- 여유 없는 일정
- 잘못 작성된 문서
- 요구사항들의 변경
- 팀과의 의사소통 없이 하는 행동
- 도메인 지식의 부족
역시 의사소통이 중요해.. 의사소통이 2개나 있자 나 ..ㅎㅎ
- Miscommunication
- Inappropriate skills
- Complex technology
- Programming errors
- Tight schedules
- Poorly documented code
- Changing requirements
- Failure to communicate and act as a team
- Lack of domain skills
QA 업무를 진행하면서 언제 Defect이 발생하는지 항상 생각한다.
Testingexperience를 보던중 정리된 내용이 있어서 다시 정리해본다.
1. 명세서에서는 동작 해야 한다고 정의되어 있으나 동작 안 할 때
2. 명세서에서는 동작하지 말아야 한다고 정의도어 있으나 동작할 때
3. 명세서에서 언급되지 않은 내용이 동작 할 때
라고 3가지를 정의하고 있었다.
과연 그럴까? 그런 것 같다.
근데 명세서 자체가 없을 땐? 테스터의 눈으로 보기에 이해하기 어렵고, 사용하기 힘들고, 느리고, 잘못 동작한다고 보여 질 때 라고 말하는 것 같다…
맞는지는 직접 확인해보시길.^^
- The software doesn’t do something that the specification says it should do
- The software does something that the specification says it shouldn’t do
- The software does something that the specification doesn’t mention
The software doesn’t do something that the specification doesn’t
mention but should; the software is difficult to understand, hard
to use, slow, or – in the software tester’s eyes – will be viewed by
the end user as just plainly not right.
Mistake metamorphism- bytrinadh kumar bonam