"스프린트"의 두 판 사이의 차이
잔글 (→같이 보기) |
|||
(사용자 2명의 중간 판 10개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | '''스프린터'''(Sprinter) | + | '''스프린트'''(Sprint)는 소프트웨어 개발 시에 사용하는 [[테스트]] 방법이다. 스프린트는 주로 애자일 방법론을 사용하는 경우에 스크럼을 강조하면서, 5일 정도의 짧은 기간에 원하는 결과를 얻기 위해 테스트를 진행할 때 사용한다. '''스프린터'''(Sprinter)라고도 한다. 스프린트는 보통 Micro Focus Application Lifecycle Management, Quality Center 및 Micro Focus Mobile Center 솔루션과 함께 제공된다. |
==개요== | ==개요== | ||
− | 스프린터는 수동 테스트 유형이다. 소프트웨어 테스트 수동으로 테스터가 관련된 테스트 케이스 자동화 도구를 사용하지 않고 실행할 수 있다. 테스터는 실제로 애플리케이션 화면 뒤에 있으며, 테스트 케이스를 수행하고 그 결과를 확인한다. 수동 테스트는 테스트의 가장 | + | 스프린터는 수동 테스트 유형이다. 소프트웨어 테스트 수동으로 테스터가 관련된 테스트 케이스 자동화 도구를 사용하지 않고 실행할 수 있다. 테스터는 실제로 애플리케이션 화면 뒤에 있으며, 테스트 케이스를 수행하고 그 결과를 확인한다. 수동 테스트는 테스트의 가장 원시적인 형태입니다. 우리는 버그 찾는 데 사용한다. 자동화된 테스트를 수행하기 전에 모든 신규 또는 수정된 응용 프로그램을 먼저 수동으로 테스트해야 한다. 이것이 우리가 소프트웨어의 테스트 가능성을 결정하는 방법이다. 수동 테스트는 더 큰 노력이 필요하지만 응용 프로그램의 작동을 확인하는 데 필요하다.<ref>〈[https://ko.itpedia.nl/2017/10/11/wat-is-handmatig-testen/ 수동 테스트 란 무엇입니까?]〉, 《아이티피디아》</ref> 이 소프트웨어는 테스터 생산을 증가시키는 데 도움이 된다. 사용하기 쉬운 화면으로 강도와 정확성 툴바, 주석이 달린 스크린숏, 비디오 및 텍스트 테스트 단계 캡처, 지능형 결함 문서화, 자동 데이터 입력, 일반적인 오류를 포착하기 위한 베드 스캐너 절차 및 끊어진 링크와 같은 하나의 테스트를 실행하기 위해 여러 플랫폼에서 동시에 환경 지원을 한다.<ref>〈[https://www.calleosoftware.co.uk/upload/user/0qlzfceB/MF%20Sprinter%20-%20Overview.pdf 스프린터]〉, 《칼레오 소프트웨어》</ref> |
==등장배경== | ==등장배경== | ||
;스크럼 | ;스크럼 | ||
10번째 줄: | 10번째 줄: | ||
===장점 및 단점=== | ===장점 및 단점=== | ||
[[파일:수동 및 자동 테스트.png|썸네일|400픽셀|수동 및 자동 테스트]] | [[파일:수동 및 자동 테스트.png|썸네일|400픽셀|수동 및 자동 테스트]] | ||
− | 스프린터의 장점은 총 6가지가 있다. | + | |
+ | 스프린터의 장점은 총 6가지가 있다. 첫째 공식적인 테스터에서 단계로 사용자 동작을 캡처하는 강화된 탐색적 테스트, 둘째 데이터 주입은 테스트의 수동 반복을 제거하는 테이터자원, 셋째 환경 범위를 늘리기 위해 여러 컴퓨터에서 동시에 테스트를 실행하는 거울미러 테스트, 넷째 자동 결함 스캐너는 맞춤법 및 준수와 같은 주요 조건을 테스트하는 결함 스캐너, 다섯째 스마트 문서를 자동 생성하여 개발자 팀과의 커뮤니케이션을 향상하고, 마지막으로 간편한 UFT(Unified Functional Test) 통한 원 클릭 자동화이다. 하지만 자동화 테스트보다테스트에 비해 정확하진 않다. 수동테스트 주기의 기본 요소는 테스트 제작, 테스트 실행 및 결함 선적 서류 비치. 스프린터는 모든 단계에서 테스트 가속화 수동 테스트 수명 주기가 있다. | ||
;자동화 테스트 | ;자동화 테스트 | ||
− | + | 자동화된 소프트웨어 테스팅에서 테스터는 코드 실행과 테스트 스크립트를 작성하여 테스트 실행을 자동화한다. 테스터는 적절한 자동화 도구를 사용하여 테스트 스크립트를 개발하고 소프트웨어의 유효성을 검사한다. 목표는 적은 시간에 테스트 실행을 완료하는 것이다. 자동 테스트는 전 스크립트 테스트에 전적으로 의존하며 실제 테스트 결과와 예상 결과를 자동으로 비교한다. 이는 테스터가 응용 프로그램이 예상대로 수행되는지 여부를 결정하는데 도움이 된다. 자동화된 테스트를 통해 수동 테스터의 개입 없이 반복적인 작업 및 회귀 테스트를 실행할 수 있다. 모든 프로세스가 자동으로 수행되더라도 자동화는 초기 테스트 스크립트를 작성하기 위해 수동으로 약간의 노력이 필요하다.<ref name='나'>〈[https://testmanager.tistory.com/186 테스트의 모든것]〉, 《티스토리》, 2018-11-20</ref> | |
;수동 테스트 장점 및 단점 | ;수동 테스트 장점 및 단점 | ||
− | *'''장점''' : 빠르고 정확한 시각적 피드백 제공을하고 자동화 도구 및 프로세스를 위해 예산을 낭비 할 필요가 없으므로 비용이 저렴하다. 그리고 인간의 판단과 직감은 항상 수동 요소에 도움이된다. 마지막으로 | + | *'''장점''' : 빠르고 정확한 시각적 피드백 제공을하고 자동화 도구 및 프로세스를 위해 예산을 낭비 할 필요가 없으므로 비용이 저렴하다. 그리고 인간의 판단과 직감은 항상 수동 요소에 도움이된다. 마지막으로 작업 변화를 테스트하는 동안 자동화 테스트에는 시간이 많이 소요되는 코딩이 필요하다.<ref name="나"></ref> |
− | *'''단점''' : 사람이 수행을 해서 신뢰성이 낮은 테스트 방법이다. 항상 실수와 오류가 발생하기 쉽다. 수동 테스트 프로세스를 기록 할 수 없으므로 수동 테스트를 다시 사용할 수 없다. 이 테스트 방법에서는 특정 작업을 수동으로 수행하기가 어려워 소프트웨어 테스트 단계의 추가 시간이 필요한다.<ref name= | + | *'''단점''' : 사람이 수행을 해서 신뢰성이 낮은 테스트 방법이다. 항상 실수와 오류가 발생하기 쉽다. 수동 테스트 프로세스를 기록 할 수 없으므로 수동 테스트를 다시 사용할 수 없다. 이 테스트 방법에서는 특정 작업을 수동으로 수행하기가 어려워 소프트웨어 테스트 단계의 추가 시간이 필요한다.<ref name="나"></ref> |
;자동 테스트 장점 및 단점 | ;자동 테스트 장점 및 단점 | ||
*'''장점''' : 수동 테스팅보다 약 70% 정도 빠르고, 애플리케이션 기등들에 대한 더 넓은 테스트 범위를 가지고 믿을만한 결과, 일관성 보장, 시간과 비용 절약, 정확성 향상, 효율성 향상, 실행도중 사람의 개입이 필요하지 않다. 그리고 테스트 실행 중 더 나은 속도를 경험하고 재사용 가능한 테스트 스크립트와 철저한 테스트 기능을 가지고 있다. 마지막으로 시장 진입이 빨라진다는 장점이 있다.<ref>〈[https://sites.google.com/site/knowingmoresoftware/software-testing/automated-testing 소프트웨어 더 알기]〉, 《사이트스》</ref> | *'''장점''' : 수동 테스팅보다 약 70% 정도 빠르고, 애플리케이션 기등들에 대한 더 넓은 테스트 범위를 가지고 믿을만한 결과, 일관성 보장, 시간과 비용 절약, 정확성 향상, 효율성 향상, 실행도중 사람의 개입이 필요하지 않다. 그리고 테스트 실행 중 더 나은 속도를 경험하고 재사용 가능한 테스트 스크립트와 철저한 테스트 기능을 가지고 있다. 마지막으로 시장 진입이 빨라진다는 장점이 있다.<ref>〈[https://sites.google.com/site/knowingmoresoftware/software-testing/automated-testing 소프트웨어 더 알기]〉, 《사이트스》</ref> | ||
− | *'''단점''' : 인간 요소가 없으면 색상, 글꼴, 크기, 대비 또는 단추 크기의 같은 UI의 시각적 요소를 파악하기가 어렵다. 자동화 테스트를 실행하는 도구는 비용이 많이 들 수 있으므로 테스트 프로젝트의 비용이 증가 할 수 있다. 자동화 테스트 도구는 아직 완전한 증거는 아니다. 또한 모든 자동화 도구에는 자동화의 범위를 축소시키는 한계가 있다. 테스트 스크립트를 디버깅하는 것은 자동화 된 테스트의 또 다른 주요 문제이다. 테스트 유지 보수에는 많은 비용이 든다.<ref name= | + | *'''단점''' : 인간 요소가 없으면 색상, 글꼴, 크기, 대비 또는 단추 크기의 같은 UI의 시각적 요소를 파악하기가 어렵다. 자동화 테스트를 실행하는 도구는 비용이 많이 들 수 있으므로 테스트 프로젝트의 비용이 증가 할 수 있다. 자동화 테스트 도구는 아직 완전한 증거는 아니다. 또한 모든 자동화 도구에는 자동화의 범위를 축소시키는 한계가 있다. 테스트 스크립트를 디버깅하는 것은 자동화 된 테스트의 또 다른 주요 문제이다. 테스트 유지 보수에는 많은 비용이 든다.<ref name="나"></ref> |
===종류=== | ===종류=== | ||
− | *'''에이치피 스프린터'''(HP sprinter) : 마이크로 포커스(Micre focus)에서 지원하는 수동 소프트웨어 테스트 솔루션이다. 민첩한 테스트를 간소화하고 가속화하고, 공식테스트에서 단계로 사용자 조치를 할 수 있는 강화 된 탐색 테스트, 데이터자원 수동 반복 제거 | + | *'''에이치피 스프린터'''(HP sprinter) : 마이크로 포커스(Micre focus)에서 지원하는 수동 소프트웨어 테스트 솔루션이다. 민첩한 테스트를 간소화하고 가속화하고, 공식테스트에서 단계로 사용자 조치를 할 수 있는 강화 된 탐색 테스트, 데이터자원 수동 반복 제거, 정확하고 효율적인 수동 소프트웨어 제공, 수동소프트웨어 테스트 수행 및 정확성과 효과를 높인다. 그리고 자동 주입을 처리하고 속도를 높이는 테스트중인 피륻에 데이터를 수집 그리고 테스트가 실행 될 수 있는 정확성을 실현할 수 있다. 마지막으로 자동으로 기록 할 수도 있다. 실행할 때 테스터의 활동 및 조치를 기록한다.<ref>〈[https://translate.googleusercontent.com/translate_f HP 스프린터]〉, 《에이치피 스프린터》</ref> |
− | |||
− | |||
+ | *'''스크럼''' : 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지해 점진적으로 [[소프트웨어]](SW)를 산출하는 대표적인 [[애자일]] 방법론이다. Product Backlog를 바탕으로 하여 기술적으로 분할되고 재해석된 스프린터를 스크럼 팀을 통해 구현해 나간다. 스크럼은 XP와 달리 진행 체계 수립과 역할, 정의에 중점을 둔 프로젝트 관리 강조, 기존의 개발방법론, 표준, 공학적 접근법의 포괄적 수용을 하는 포괄적 정의, 포용, 15분 정도의 회의와 30일 정도의 개발 주기를 가진 시간적 조정 설정, 전체 제품 요구사항관리와 개발 주기 내 요구사항, 업무 진행 기사화를 하는 관리적 체계, 5~9명으로 팀을 구성하여 팀 내 역활 분담을 하고 팀원 구성 간 업무 교환을 하는 팀 중심적 성향의 특징들을 가지고 있다. 스크럼이 추구하는 5가지 가치는 아래와 같다.<ref name="가"></ref> | ||
#확약 : 약속한 것을 확실히 실현하는 것 | #확약 : 약속한 것을 확실히 실현하는 것 | ||
36번째 줄: | 36번째 줄: | ||
;도전 | ;도전 | ||
− | Hancock Bank는 마이크로를 활용한 수동 테스트를 위한 Focus sprinter를 효율적이고 효과적으로 했다. HancockBank는 ing 기능으로 문서화 스크립트를 테스트하고 이러한 문서를 조직이 채택한 교육자료로 활용했다.<ref name= | + | Hancock Bank는 마이크로를 활용한 수동 테스트를 위한 Focus sprinter를 효율적이고 효과적으로 했다. HancockBank는 ing 기능으로 문서화 스크립트를 테스트하고 이러한 문서를 조직이 채택한 교육자료로 활용했다.<ref name="다"></ref> |
;결과 | ;결과 | ||
− | Hancock Bank는 Micro focus 솔루션을 사용하여 테스트 결과를 통한 요구 사항의 추적성 개선과 테스트 노력을 통한 진취적인 느낌을 얻었다.<ref name= | + | Hancock Bank는 Micro focus 솔루션을 사용하여 테스트 결과를 통한 요구 사항의 추적성 개선과 테스트 노력을 통한 진취적인 느낌을 얻었다.<ref name="다"></ref> |
{{각주}} | {{각주}} | ||
45번째 줄: | 45번째 줄: | ||
==참고자료== | ==참고자료== | ||
*〈[https://ko.itpedia.nl/2017/10/11/wat-is-handmatig-testen/ 수동 테스트 란 무엇입니까?]〉, 《아이티피디아》 | *〈[https://ko.itpedia.nl/2017/10/11/wat-is-handmatig-testen/ 수동 테스트 란 무엇입니까?]〉, 《아이티피디아》 | ||
+ | *〈[https://www.calleosoftware.co.uk/upload/user/0qlzfceB/MF%20Sprinter%20-%20Overview.pdf 스프린터]〉, 《칼레오 소프트웨어》 | ||
*〈[https://needjarvis.tistory.com/317 SPRINT를 활용한 대표적인 AGILE 방법론, 스크럼(SCRUM)]〉, 《티스토리》, 2019-01-01 | *〈[https://needjarvis.tistory.com/317 SPRINT를 활용한 대표적인 AGILE 방법론, 스크럼(SCRUM)]〉, 《티스토리》, 2019-01-01 | ||
*〈[https://testmanager.tistory.com/186 테스트의 모든것]〉, 《티스토리》, 2019-11-20 | *〈[https://testmanager.tistory.com/186 테스트의 모든것]〉, 《티스토리》, 2019-11-20 | ||
*〈[https://sites.google.com/site/knowingmoresoftware/software-testing/automated-testing 소프트웨어 더 알기]〉, 《사이트스》 | *〈[https://sites.google.com/site/knowingmoresoftware/software-testing/automated-testing 소프트웨어 더 알기]〉, 《사이트스》 | ||
+ | *〈[https://translate.googleusercontent.com/translate_f HP 스프린터]〉, 《에이치피 스프린터》 | ||
*〈[https://www.microfocus.com/media/success-story/hancock_bank_ss.pdf 핸콕 은행]〉, 《마이크로 포커스》 | *〈[https://www.microfocus.com/media/success-story/hancock_bank_ss.pdf 핸콕 은행]〉, 《마이크로 포커스》 | ||
+ | |||
==같이 보기== | ==같이 보기== | ||
* [[애자일]] | * [[애자일]] | ||
* [[스크럼]] | * [[스크럼]] | ||
+ | * [[테스트]] | ||
* [[수동 테스트]] | * [[수동 테스트]] | ||
− | |||
* [[Micro Focus]] | * [[Micro Focus]] | ||
+ | * [[스프린터]] | ||
− | {{ | + | {{프로그래밍|검토 필요}} |
2020년 11월 15일 (일) 01:26 기준 최신판
스프린트(Sprint)는 소프트웨어 개발 시에 사용하는 테스트 방법이다. 스프린트는 주로 애자일 방법론을 사용하는 경우에 스크럼을 강조하면서, 5일 정도의 짧은 기간에 원하는 결과를 얻기 위해 테스트를 진행할 때 사용한다. 스프린터(Sprinter)라고도 한다. 스프린트는 보통 Micro Focus Application Lifecycle Management, Quality Center 및 Micro Focus Mobile Center 솔루션과 함께 제공된다.
개요[편집]
스프린터는 수동 테스트 유형이다. 소프트웨어 테스트 수동으로 테스터가 관련된 테스트 케이스 자동화 도구를 사용하지 않고 실행할 수 있다. 테스터는 실제로 애플리케이션 화면 뒤에 있으며, 테스트 케이스를 수행하고 그 결과를 확인한다. 수동 테스트는 테스트의 가장 원시적인 형태입니다. 우리는 버그 찾는 데 사용한다. 자동화된 테스트를 수행하기 전에 모든 신규 또는 수정된 응용 프로그램을 먼저 수동으로 테스트해야 한다. 이것이 우리가 소프트웨어의 테스트 가능성을 결정하는 방법이다. 수동 테스트는 더 큰 노력이 필요하지만 응용 프로그램의 작동을 확인하는 데 필요하다.[1] 이 소프트웨어는 테스터 생산을 증가시키는 데 도움이 된다. 사용하기 쉬운 화면으로 강도와 정확성 툴바, 주석이 달린 스크린숏, 비디오 및 텍스트 테스트 단계 캡처, 지능형 결함 문서화, 자동 데이터 입력, 일반적인 오류를 포착하기 위한 베드 스캐너 절차 및 끊어진 링크와 같은 하나의 테스트를 실행하기 위해 여러 플랫폼에서 동시에 환경 지원을 한다.[2]
등장배경[편집]
- 스크럼
일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로타가 1986년 1~2월 하버드 비즈니스 리뷰(Harvard Business Review)에 올린 새로운 게임 개발 상품(The New Product Developement Game) 에서 시작된다. 이 아이디를 기반으로 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, 난제, 옳은 해결책(Wicked Problems, Righteous Solutions) 에서 스크럼을 처음 언급한다. 스크럼이라는 용어의 탄생은 럭비(미식축구)에서 유래되었다.[3]
특징[편집]
장점 및 단점[편집]
스프린터의 장점은 총 6가지가 있다. 첫째 공식적인 테스터에서 단계로 사용자 동작을 캡처하는 강화된 탐색적 테스트, 둘째 데이터 주입은 테스트의 수동 반복을 제거하는 테이터자원, 셋째 환경 범위를 늘리기 위해 여러 컴퓨터에서 동시에 테스트를 실행하는 거울미러 테스트, 넷째 자동 결함 스캐너는 맞춤법 및 준수와 같은 주요 조건을 테스트하는 결함 스캐너, 다섯째 스마트 문서를 자동 생성하여 개발자 팀과의 커뮤니케이션을 향상하고, 마지막으로 간편한 UFT(Unified Functional Test) 통한 원 클릭 자동화이다. 하지만 자동화 테스트보다테스트에 비해 정확하진 않다. 수동테스트 주기의 기본 요소는 테스트 제작, 테스트 실행 및 결함 선적 서류 비치. 스프린터는 모든 단계에서 테스트 가속화 수동 테스트 수명 주기가 있다.
- 자동화 테스트
자동화된 소프트웨어 테스팅에서 테스터는 코드 실행과 테스트 스크립트를 작성하여 테스트 실행을 자동화한다. 테스터는 적절한 자동화 도구를 사용하여 테스트 스크립트를 개발하고 소프트웨어의 유효성을 검사한다. 목표는 적은 시간에 테스트 실행을 완료하는 것이다. 자동 테스트는 전 스크립트 테스트에 전적으로 의존하며 실제 테스트 결과와 예상 결과를 자동으로 비교한다. 이는 테스터가 응용 프로그램이 예상대로 수행되는지 여부를 결정하는데 도움이 된다. 자동화된 테스트를 통해 수동 테스터의 개입 없이 반복적인 작업 및 회귀 테스트를 실행할 수 있다. 모든 프로세스가 자동으로 수행되더라도 자동화는 초기 테스트 스크립트를 작성하기 위해 수동으로 약간의 노력이 필요하다.[4]
- 수동 테스트 장점 및 단점
- 장점 : 빠르고 정확한 시각적 피드백 제공을하고 자동화 도구 및 프로세스를 위해 예산을 낭비 할 필요가 없으므로 비용이 저렴하다. 그리고 인간의 판단과 직감은 항상 수동 요소에 도움이된다. 마지막으로 작업 변화를 테스트하는 동안 자동화 테스트에는 시간이 많이 소요되는 코딩이 필요하다.[4]
- 단점 : 사람이 수행을 해서 신뢰성이 낮은 테스트 방법이다. 항상 실수와 오류가 발생하기 쉽다. 수동 테스트 프로세스를 기록 할 수 없으므로 수동 테스트를 다시 사용할 수 없다. 이 테스트 방법에서는 특정 작업을 수동으로 수행하기가 어려워 소프트웨어 테스트 단계의 추가 시간이 필요한다.[4]
- 자동 테스트 장점 및 단점
- 장점 : 수동 테스팅보다 약 70% 정도 빠르고, 애플리케이션 기등들에 대한 더 넓은 테스트 범위를 가지고 믿을만한 결과, 일관성 보장, 시간과 비용 절약, 정확성 향상, 효율성 향상, 실행도중 사람의 개입이 필요하지 않다. 그리고 테스트 실행 중 더 나은 속도를 경험하고 재사용 가능한 테스트 스크립트와 철저한 테스트 기능을 가지고 있다. 마지막으로 시장 진입이 빨라진다는 장점이 있다.[5]
- 단점 : 인간 요소가 없으면 색상, 글꼴, 크기, 대비 또는 단추 크기의 같은 UI의 시각적 요소를 파악하기가 어렵다. 자동화 테스트를 실행하는 도구는 비용이 많이 들 수 있으므로 테스트 프로젝트의 비용이 증가 할 수 있다. 자동화 테스트 도구는 아직 완전한 증거는 아니다. 또한 모든 자동화 도구에는 자동화의 범위를 축소시키는 한계가 있다. 테스트 스크립트를 디버깅하는 것은 자동화 된 테스트의 또 다른 주요 문제이다. 테스트 유지 보수에는 많은 비용이 든다.[4]
종류[편집]
- 에이치피 스프린터(HP sprinter) : 마이크로 포커스(Micre focus)에서 지원하는 수동 소프트웨어 테스트 솔루션이다. 민첩한 테스트를 간소화하고 가속화하고, 공식테스트에서 단계로 사용자 조치를 할 수 있는 강화 된 탐색 테스트, 데이터자원 수동 반복 제거, 정확하고 효율적인 수동 소프트웨어 제공, 수동소프트웨어 테스트 수행 및 정확성과 효과를 높인다. 그리고 자동 주입을 처리하고 속도를 높이는 테스트중인 피륻에 데이터를 수집 그리고 테스트가 실행 될 수 있는 정확성을 실현할 수 있다. 마지막으로 자동으로 기록 할 수도 있다. 실행할 때 테스터의 활동 및 조치를 기록한다.[6]
- 스크럼 : 작은 개발팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지해 점진적으로 소프트웨어(SW)를 산출하는 대표적인 애자일 방법론이다. Product Backlog를 바탕으로 하여 기술적으로 분할되고 재해석된 스프린터를 스크럼 팀을 통해 구현해 나간다. 스크럼은 XP와 달리 진행 체계 수립과 역할, 정의에 중점을 둔 프로젝트 관리 강조, 기존의 개발방법론, 표준, 공학적 접근법의 포괄적 수용을 하는 포괄적 정의, 포용, 15분 정도의 회의와 30일 정도의 개발 주기를 가진 시간적 조정 설정, 전체 제품 요구사항관리와 개발 주기 내 요구사항, 업무 진행 기사화를 하는 관리적 체계, 5~9명으로 팀을 구성하여 팀 내 역활 분담을 하고 팀원 구성 간 업무 교환을 하는 팀 중심적 성향의 특징들을 가지고 있다. 스크럼이 추구하는 5가지 가치는 아래와 같다.[3]
- 확약 : 약속한 것을 확실히 실현하는 것
- 전념 : 확약한 것의 실현에 전념하는 것
- 정직 : 어떤 것이 자신에게 불리해도 숨기지 않는 것
- 존중 : 자신과 다른 사람에게 경의를 표하는 것
- 용기 : 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 통해 작업할 수 있는 용기
성공 사례[편집]
- 핸콕 은행(Hancock Bank) : 1899 년에 설립 된 핸콕 은행(Hancock Bank)는 미시시피, 앨라배마 및 플로리다에 위치한 서비스 금융 회사 이다. 서비스기존 및 온라인 뱅킹, 상거래 포함사회 및 민간 은행, 신탁 및 투자,모기지 서비스 등 사업을 한다.[7]
- 도전
Hancock Bank는 마이크로를 활용한 수동 테스트를 위한 Focus sprinter를 효율적이고 효과적으로 했다. HancockBank는 ing 기능으로 문서화 스크립트를 테스트하고 이러한 문서를 조직이 채택한 교육자료로 활용했다.[7]
- 결과
Hancock Bank는 Micro focus 솔루션을 사용하여 테스트 결과를 통한 요구 사항의 추적성 개선과 테스트 노력을 통한 진취적인 느낌을 얻었다.[7]
각주[편집]
참고자료[편집]
- 〈수동 테스트 란 무엇입니까?〉, 《아이티피디아》
- 〈스프린터〉, 《칼레오 소프트웨어》
- 〈SPRINT를 활용한 대표적인 AGILE 방법론, 스크럼(SCRUM)〉, 《티스토리》, 2019-01-01
- 〈테스트의 모든것〉, 《티스토리》, 2019-11-20
- 〈소프트웨어 더 알기〉, 《사이트스》
- 〈HP 스프린터〉, 《에이치피 스프린터》
- 〈핸콕 은행〉, 《마이크로 포커스》
같이 보기[편집]