- 어떤 프로덕트가 품질이 좋다고 할 수 있는가?
이건 프로덕트마다 다르지 않을까 하는 생각이 요즘 새롭게 들고있다. 원래 생각이라면 기본적으로 기획대로 동작하며 기획되지 않은 예외 케이스들까지 탐색적으로 이슈 및 개선 사항을 찾아 좋은 UX를 제공하는 프로덕트가 품질이 높다고 생각했다. 소프트웨어를 사용자에게 빈번하게 전달할 수 있도록 하여 가치를 제공하고 제품이 실제로 어떻게 사용되는지 빠르게 피드백을 얻기 위해 지속적 통합 및 배포를 하는 조직에서는 어떻게 품질을 제고할 수 있을까? 더 빨리 전달해야한다는 비즈니스적 압박이 생산되는 제품의 품질을 저하해서는 안된다. 사업적으로 혁신적인 아이디어와 기능을 제공하더라도, 사용자는 안정적으로 작동하는 소프트웨어를 기대하기 때문이다.
- 선형적 접근 방식을 넘어서
소프트웨어 테스트는 품질을 보장하는 데 필수적이다. QA 단계가 코드 개발 및 통합 이후의 단계가 된다면 릴리스 프로세스가 지연될 리스크를 안게 된다. 짧은 반복 주기와 애자일 접근 방식에서 새로운 코드가 적절히 작동하는지, 다른 코드의 손상은 없는지 빠르게 검증하는 일은 필수적일 것이다. 테스트는 파이프라인 전체의 여러 단계에서 수행되어야 할 것이다. CI/ CD의 핵심은 팀에서 최대한 빨리 문제를 파악할 수 있게 지원하는 긴밀한 피드백 루프이다.
- 자동화는 수동 테스트의 종말일까?
자동화는 리소스 효율을 높인다. 반복 작업에 시간을 소비하는 대신 테스터는 테스트 케이스를 정의하고, ATC를 작성하고, 탐색 테스트를 통해 창의성과 독창성을 발휘하여 기획과 개발에서 누락된 다양한 케이스에 대한 검증 하는데 집중할 수 있다. 탐색 테스트가 점차 수동적이고 반복적인 테스트로 변질되어서는 안된다. 탐색 테스트의 취지는 매번 동일한 테스트 세트를 수행하지 않는 것이다. 메뉴얼 테스트는 테스트의 목적이 될 수 없다. 테스터의 시간을 효율적으로 사용하려면 자동화된 테스트를 모두 통과한 후에 수동 테스트를 실시해야 한다. QA에게 무엇을 자동화 할지, 어떻게 자동화 할 수 있을지에 대한 고민은 이제 필수가 되어버린 것 같다.
