| |
 |
|
| ▲ 정해영 투비소프트 품질관리팀장(jhy1977@tobesoft.com) |
많은 테스트를 진행했다 해서 품질이 높아지는 것은 아니다. 그러나 세간에는 QA가 테스트에 의해 결정된다고 믿는 이들이 많다. 물론 테스트의 역할이 없는 것은 아니지만, 테스트만으로 QA가 되는 것은 아니다. 품질을 높이기 위해서는 올바로 설계된 프로그램에 맞춰 구현해야 하며, 그 ‘올바로’를 위한 활동이 QA 활동이다. 오히려 구현 이후 테스트를 통해 발견된 버그는 모두 처리할 수 없다. <편집자>
|
연재 순서
1. 테스트라는 잘못된 인식이 불러온 오해(이번호)
2. 실효가 있었던 경험 위주의 QA에 대한 진실들
|
QA부서라고 하면 가장 먼저 떠오르는 것은 무엇인가? 아마도 대부분 개발이 완료되고 고객에게 전달하기 전에 개발이 완료된 프로그램을 다양한 환경에서, 다양한 테스트를 반복적으로 수행하는 부서쯤으로 생각되곤 한다. TV광고에서도 QA가 수만 번의 테스트를 수행한 제품이라고 당당하게 이야기하기도 하고, 개발이 다된 프로그램을 인수받는 고객도 QA를 거쳤는지 묻곤 한다.
또한 QA관련 교육을 받고자 찾아보면 교육 기관들의 커리큘럼은 온통 소프트웨어 테스트 전문가 과정이나 테스트 방법론이 대부분이다. 이러한 환경이 우리가 오해하게끔 만들고 있다. 물론 QA에 테스트의 역할이 없는 것은 아니지만 전부도 아니다. 즉 QA는 테스트가 아니다.
QA가 테스트라는 오해로 파생된 예가 또 하나 있다. 테스트는 QA라는 논리가 성립되면서 테스트를 많이 하면 품질이 높아진다는 시각이다. 이는 일부분도 성립될 수 없는 커다란 오해다. 테스트는 단지 제품의 상태를 점검하는 것이지 그 것으로 품질을 높일 수 없다.
프로그램 개발 전반에 숨어있는 QA 활동들
프로젝트가 올바른 프로그램을 구현하기 위해서는 사전에 결정하고 확인해야 할 것들이 많다. 요구사항을 수집·분석하고 개발 프로세스를 결정한 뒤 시스템 설계를 하고, 아키텍처 설계와 모듈 설계를 한다. 여기서부터 QA 활동이 시작된다.
이때 활동은 프로그램 구현 이후 테스트활동보다 더 신경 써야 할 시기다. 이미 구현이 완료된 상태에서 설계와 요구사항의 변경이 발생할 경우 프로그램은 엄청난 비용을 지불하게 되고, 그동안 공들인 소스는 꼬일 대로 꼬이게 되기 때문이다. 앞서 말했듯이 개발 후반부에 테스트는 ‘큰일났다!’를 알려줄 뿐이다.
● 요구공학에서 QA 활동
요구사항 수집·분석에서 요구공학자가 고객의 요구를 수집한다면, QA는 고객의 요구에서 품질 목표를 도출해야 한다. 요구사항은 고객으로부터 오기도 하고, 만들고자 하는 프로그램의 시장에서 요구되는 내용이기도 하다. 전자의 경우 고객은 요구사항이 명확하지 않다. 알아서 잘 해달라고만 하는 고객부터 인터뷰 때마다 요구사항이 바뀐다던가, 배타적인 요구사항이 있기도 하다. 심지어 인터뷰하는 고객이 결정권자가 아닐 때도 있다.
후자의 경우에는 시장의 상황과 해당 분야의 방향을 전망하는 조사들이 필요하다. 주로 영업과 같은 고객의 접점에서 나오는 정보와 개발하는 프로그램의 방향과 관련한 전문가로부터 요건들을 수집하는 과정을 거친다. 요구사항은 인터뷰 기술이나 설문 기술부터 사람의 행동 패턴, 심리까지 파악할 수 있어야 한다. 이런 과정을 통해 고객의 내면에 숨겨져 있는 요구를 수집하고 분석해야 한다.
이렇게 정의된 요구사항들은 서로 배타적인 것은 없는지, 누락이나 중복되는 것은 없는지 등을 검증하는 과정을 거친다. 또한 정의된 요구사항을 추적 관리하며 이해 당사자에게 공유하는 일련의 활동들, 이것이 요즘 주요하게 이야기되는 요구공학이다.
| |
 |
|
| ▲ 요구공학 프로세스 |
요구공학에서 정의된 요구사항을 QA는 품질 요구사항으로 재정의해야 한다. 고객이 요구하고 요구공학에서 분석해 정의한 내용을 테스트 관점에서 재정의할 필요가 있기 때문이다. 예를 들어 <표 1>과 같이 로그인 화면에 대한 요구사항 정의서가 있다고 가정해보자.
| |
 |
|
| ▲ <표 1> 로그인 화면에 대한 요구사항 정의서 |
QA는 이 요구사항 정의서를 <표 2>와 같이 테스트 요구사항으로 재정의할 수 있다.
| |
 |
|
| ▲ <표 2> 테스트 요구사항 |
테스트 요구사항으로 정의하면서 모호하거나 명확하지 않은 것은 요구사항 분석가와 협의해 정의해 나간다. 이렇게 정의된 테스트 요구사항은 프로젝트가 진행되면서 계속 변경되기도 하며, 이를 반영해 나가면서 이력을 관리한다. 테스트 요구사항은 요구사항 수집가, 설계 및 구현 담당자에게 공유해 설계 및 구현 단계부터 테스트 통과 기준을 반영하도록 해야 한다. 이 테스트 요구사항 정의서는 추후 품질 목표부터 테스트 아키텍처, 테스트 설계, 이슈관리, 테스트 계획 등 이후 모든 품질 활동의 주축이 된다.
● 개발 프로세스 결정에서 QA 활동
개발 프로세스 결정에서 QA는 개발 프로세스 단계별로 테스트 프로시저 및 테스트 케이스 도출이 유용한 프로세스이고, 프로세스가 요구사항 및 이슈 추적에 용이한지 프로젝트 매니저와 같이 고민해야 한다.
테스트 프로시저 및 테스트 케이스 도출이 유용한 프로세스로는 보편적으로 V모델을 선호한다. V모델의 좌측에 요구분석, 아키텍처 설계, 모듈 설계 단계에서 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트의 테스트 케이스 및 프로시저를 미리 준비할 수 있다. 물론 개발 도중 수시로 변경되기 때문에 미리 준비된 결과물의 수정이 용이해야 한다.
| |
 |
|
| ▲ V모델은 프로그램 개발 프로세스를 단계별로 테스트 종류와 연결하고 있다. |
프로세스는 진행단계, 요구사항 달성 및 커버리지의 지표와 추적이 가능해야 하며 구현 기간 형상 변경이 확인되도록 시스템화 돼야 한다. 또한 이 시스템은 개발 표준 준수 여부 확인과 테스트 커버리지 및 테스트 결과가 수치화 돼서 개발되는 품질의 수준을 측정할 수 있어야 한다. 이러한 시스템의 개발 및 도입을 QA에서 하기도 한다. 이를 위해 레드마인(Redmine), 맨티스(Mantis), 소프트웨어 시각화(SW visualization) 등의 도구를 도입할 수 있으며, 자체 개발을 하기도 한다.
● 테스트 설계에서 QA 활동
테스트 설계는 QA가 구현 전부터 시작하는 주요 활동으로 테스트 아키텍처, 리스크 분석, 품질 목표 설정을 하고 품질 목표에 기반한 테스트 계획서를 만단다. 테스트 아키텍처는 테스트하고자 하는 프로그램의 테스트 관점들을 도출하고, 그 관점들의 관계를 분석해 어떤 테스트를 해야 할지 도식화하는 과정이다.
| |
 |
|
| ▲ 제2회 한국 테스트 디자인 콘테스트에서 발표한 테스트 아키텍처 |
이렇게 만들어진 아키텍처를 모두 높은 강도로 테스트하면 좋겠으나 주어진 자원과 시간은 너무나 부족하다. 안타깝게도 아직까지 소프트웨어 개발 테스트에 주어지는 자원과 시간은 더욱 촉박하다. 때문에 위험한 부분과 중요한 부분을 찾아내서 나열하고, 그 수준에 따른 테스트 설계에 차등을 둘 수밖에 없다.
| |
 |
|
| ▲ 리스크 분석 그래프 |
그래서 리스크 분석이 필요하다. 리스크 분석은 품질 목표를 결정하는데 요구자와 개발자 간 이해를 돕고, 서로의 오해를 최소화 시킬 수 있다. 품질 목표를 확정하지 못할 경우 개발사는 많은 손해를 볼 수 있다. 명확하지 않은 품질 수준으로 요구자 또는 고객과 개발자가 또는 개발사와 이견이 생기면 안타깝게도 대부분 고객이 이긴다. 그럼 생각지 못한 추가 비용이 발생하게 되고 개발 기간과 공수의 추가가 불가피하다.
그래서 QA는 이해관계자와 품질 목표를 정해야 한다. 품질 목표를 정하는데 우선 ‘무결한 소프트웨어는 없다’를 전제로 해야 한다. 소프트웨어가 무결하다는 것은 증명하기 어렵고, 여러 모듈과 개발자가 섞여서 개발하다 보면 무결한 소프트웨어를 만들기 어렵다. 그리고 무엇보다 비용이 많이 든다. 때문에 소프트웨어에 투자하는 비용에 따라서 품질 목표가 정해진다. 즉 원하는 시간에 원하는 비용만큼의 품질 목표가 정해진다.
● 프로그램 구현에서 QA 활동
프로그램을 본격적으로 구현하게 되면 QA는 정적 분석과 테스트를 위한 이슈 관리를 해야 한다. 정적 분석은 프로그램을 개발하기 위해 개발자 간 약속한 개발 표준과 형상관리를 검증한다. 이 약속이 깨졌을 경우 많은 시간 낭비와 반복되는 작업을 하게 되는 불상사가 일어난다. 이는 바로 품질에 악영향을 미칠 수밖에 없다. 때문에 QA는 정적 분석을 통해 이러한 이슈들을 도출해야 한다.
정적 분석은 표준을 준수하는지 의미 없는 변수 선언이나 소스의 알고리즘이 논리적인지를 확인하는 툴을 이용하기도 하고, 다양한 회의 방식이나 동료 검토 등 각 분야의 사람이 모여 고충과 의견을 나누며 이슈를 도출한다. 또한 구현하면서 수행하는 단위 테스트나 통합 테스트에서 발견되는 버그도 이슈로 도출한다.
단위 테스트는 주로 구현 개발자 본인의 소스에 문제가 없는지 확인하는 과정이 보편적이다. 개발자 본인이 해결하기 어려운 상황이거나 기한 내 해결하기 어려울 경우 이슈로 도출돼야 한다.
단위 테스트를 마치면 단위 간 인터페이스 위주로 통합 테스트를 수행한다. 통합테스트는 주로 기능 위주의 테스트로 구현에서 수행을 하는 것으로 보지만, 실질적으로 테스트 전문가가 같이 테스트를 수행하곤 한다. 시간적 제약도 있겠지만 코딩한 본인의 소스 외에 다른 소스까지 살펴봐야 하기 때문에 할당된 개발도 힘든 상태에서 통합 테스트를 개발자가 신경 써야 하는 것도 한계로 보인다.
프로그램에 품질에 영향이 있는 이슈는 분석하고 관리해야 한다. 이슈의 분석은 이슈의 내용이 추적되는 테스트 요구사항과 배치되는 것은 없는지, 품질 수준에 의해 해소 대상인지, 파생되는 추가 이슈가 있다면 추가 이슈 도출까지 해야 한다. 이렇게 분석된 이슈들은 해소될 때까지 처리과정을 추적하면서 내용에 따라 관련자에게 알리거나 처리해야 한다.
이슈가 해소되면 QA는 앞서 작성된 테스트 아키텍처 및 테스트 설계를 보완해야 한다. 아키텍처는 이슈를 처리하는 과정에 변경되는 요구사항을 주로 반영하며, 이렇게 변경된 아키텍처와 각종 이슈 내용을 기반으로 리스크를 계속 확인한다. 변경되는 리스크에 기반해 테스트 설계를 계속 보완해 감에 따라 도출되는 이슈의 양은 엄청날 것이다. 때문에 매 이슈마다 보완할 수는 없으므로 프로젝트 상황에 따라 모아서 보완한다.
● 프로그램 개발 마무리에서 QA 활동
프로그램 마무리 시점이 되면 QA는 시스템 테스트와 인수 테스트를 수행하고, 고객에게 인계 또는 공식 배포까지 품질 상태를 알려야 한다. 시스템 테스트 시기가 되면 QA는 프로그램 개발 초기부터 본격적인 개발 기간 동안 작성하고, 보완·변경한 테스트 계획서와 구현에서 도출된 매뉴얼에 따라 올바른 프로그램이 됐는지 테스트를 수행한다. 테스트를 수행하기 전 다시 한 번 리스크 분석을 하고, 테스트 계획서를 보완하고, 테스트 설계에 제시된 방법에 의해 테스트 케이스를 도출한다. 개발하는 프로그램 성격에 따라서 샘플 개발이 필요할 수도 있다. 테스트 계획서에 제시되는 테스트 케이스 도출 및 테스트 방안은 다양하다.
테스트 케이스 도출은 보통 산출된 문서에 기반한 명세기반 방안에 각 전문가의 경험에 기반한 경험기반 방안, 개발된 프로그램을 공부하면서 도출하는 탐색적 방안을 이용하여 테스트 케이스를 개발한다. 보통 경험기반이나, 탐색적 기범은 테스트케이스를 만들지 않는다고 한다. 물론 개발 기간 문서작업은 제한된 시간 내에 부담일수 밖에 없다. 하지만 이번 테스트가 1회성으로 끝나지 않고 앞으로 유지보수 하면서 지속적으로 테스트한다면 만들어 두는 것이 좋다.
유지보수 기간 만들어진 테스트 케이스에 추가되는 경험을 명세화해 추가하면 회귀(Regression) 테스트에 유용하게 사용된다. 각 방안별 테스트 방법은 상태전이 테이블, 결정 테이블, Coase Effect Graphing 등 다양한 기법이 있다. 각 기법은 테스트 성격 및 테스트 강도와도 연관돼 있어 테스트 아키텍처와 분석된 리스크 기반에 맞춰 계획을 세우고 테스트를 하면 된다.
테스트 방안으로는 사용성 테스트, 성능 테스트, 보안 테스트, 기능 테스트 등 테스트 아키텍처에 분류된 테스트 속성에 따라 다양한 방법을 적용해야 한다. 이렇게 테스트하면서 발견한 결함은 이슈로 알리고 처리를 한다. 하지만 이때 발견한 결함을 모두 처리하면 좋겠지만 역시 시간과 자원의 한계로 그 범위를 결정해야 한다. 이 때 결정 기준 역시 품질 목표에 있다.
인수 테스트 시기가 되면 QA는 테스트 결과가 품질 목표에 도달했는지 확인한다. 고객이 있는 프로젝트의 경우 고객이 테스트를 수행한다. 제품 같은 불특정 대상이 사용자라면 테스트 전문가나 베타 테스트로 일부 사용자 대상 테스트를 수행한다. 이 때 테스트 결과는 같이 합의된 품질 목표에 도달했는지를 확인한다. 무결한 프로그램이 아닌 합의된 품질 목표만 도달하면 된다.
시스템 테스트도 마찬가지지만 이 시기에는 더욱 수정 및 변경이 부담스럽다. 앞서 말했듯이 완성된 프로그램에 수정은 편법이나 덜 이해한 소스를 수정하면서 파생되는 버그로 인해 기능 문제나 품질 수준의 저하를 가져온다. 때문에 더러는 품질 목표를 수정하고 합의하기도 한다.
이렇게 프로그램이 완성되면 때에 따라 여러 품질 인증을 갖기도 한다. CMMI나 GS인증 등 품질 인증 심사를 받는 것도 QA업무에 포함된다.
● 유지보수에서 QA 활동
개발을 완료했다면 유지보수를 하게 된다. 유지보수는 개발 기간에 비해 자원이 줄어든다. 즉 적은 자원으로 여러 사람이 개발한 프로그램에 대응해야 한다. 또한 개발 기간 했던 활동들은 줄어들지 않는다. 고객 요청에 의한 개발은 개발 기간이 끝나고 계약된 유지보수 기간만 대응 하면 된다고 생각하지만, 그렇다고 유지보수 업무가 사라진 것은 아니다. 관리 주체가 개발사에서 고객사로 이관된 것뿐이다. 제품을 만드는 회사라면 제품이 소멸될 때까지 불특정 고객과 시장의 변화에 대응하기 위한 유지보수 업무가 지속된다.
유지보수 기간 QA의 업무는 프로그램 구현 기간과 이후 업무의 반복이 주로 이뤄지며 구현 기간 이전 업무도 병행하게 된다. 결국 자원이 많던 기간 업무를 모두 하게 된다. 유지보수 기간이 되면 QA는 우선 인수, 인계 자료를 확인한다. 개발 기간 활동한 QA가 유지보수도 이어서 할 경우, 개발 기간 도출된 문서와 프로세스를 점검해야 한다. 유지보수는 수많은 개발자가 개발한 프로그램을 한정된 자원으로 진행해야 하기 때문에 개발 기간 산출물에 의존할 수밖에 없다.
유지보수 기간 업무를 해내기 위해 효율성을 높이는 전략도 세워야 한다. 고객의 요구를 효율적으로 추적할 수 있어야 하며, 기 작성된(없다면 만들어야 하는) 테스트 아키텍처와 테스트 시나리오 및 테스트 케이스 같은 테스트 베드를 효율적으로 업데이트해야 한다.
테스트 부분은 효율성을 더욱 지속적인 노력이 필요하다. 유지보수 기간이 얼마나 될지 모르나 길게 내다본다면 테스트 효율화는 필수다. 완성된 소스를 수정하는 것은 파생되는 문제를 만들기 마련이다. 때문에 영향도 테스트는 필수다.
영향도의 범위가 작을수록 좋겠지만 앞서 활동한 QA의 역할이 잘 반영되지 못한 경우는 수정 사항도 많고 영향도도 어마어마하기 때문에 매번 많은 테스트를 수행할 수밖에 없다. 프로그램 개발 기간 프로세스 시각화를 잘 해둬 이슈 추적 관리나, 테스트 베드의 유지보수가 용이 하다면 이 시스템을 활용하면 된다. 없다면 구축하거나 오픈소스를 이용해 운영할 수 있다. 정적 분석 또한 개발 기간에 잘 만들어 뒀다면 지속적으로 활용하면 된다. 방법은 동일하다.
하지만 테스트와 빌드, 배포 부분은 다르다. 개발 기간 테스트는 일회성으로 끝나기 때문에 테스트 시스템을 구축하는 일은 적다. 개발 기간 만들어진 테스트 아키텍처 및 테스트 시나리오와 케이스 등 문서 및 이력만 남는다(이것이라도 남아있으면 다행이다). 때문에 QA는 효율적인 테스트 방안으로 자동화 테스트, 프로그램 지식이 없는 사람도 테스트를 수행할 수 있게 하는 시스템을 만들어 수행한다.
빌드 및 배포도 자동화는 필수다. 수정사항이 발생해 다시 빌드하는 과정이 있다면 이 빌드 과정에 잘못된 소스를 반영하거나 여러 빌드 절차 과정 중 일부를 누락하는 경우 잘 고쳐놓고 잘못된 프로그램을 배포할 수 있다. 자동화는 시간을 줄여주기도 하지만 빌드 과정에 발생할 오류를 예방하는 역할도 한다.
테스트 자동화 고려
추가로 유지보수 기간 수시로 소스 수정이 일어난다면 일일 빌드 및 테스트 자동화를 고민해야 한다. 배포에 맞춰 수정되는 소스를 기다리다가 테스트하고 결함이 발견하면 추적도 어렵고, 시간적 여유가 없다. 시간적 여유 없이 수정된 소스는 대부분 파생 결함을 갖고 있다. 다시 확인할 시간 또한 부족해 발견하지 못하고 배포할 뿐이다. 이 과정은 보통 CI환경을 만들어 운영하곤 한다.
유지보수를 위한 업무 효율화는 지속적으로 진행하면서 유지보수가 진행된다. 유지보수 프로세스는 3가지의 프로세스로 이뤄진다. 고객 및 사용자가 사용하면서 발견하는 버그 정도의 이슈 처리 절차와 신규로 추가되는 기능 및 스펙 변경 요구에 의한 이슈처리 절차, 새로운 환경에 대한 보증 절차가 그것이다.
고객 및 사용자가 사용하면서 발견하는 버그 정도의 이슈 처리의 경우 모두 버그 수정으로 이슈 해소를 하지 않는다. 앞에서 언급했듯이 버그 수정은 파생 결함을 야기한다. 때문에 가능하면 다른 방법을 가이드해서 해소하는 것이 좋다. 반드시 수정해야 한다면 이 이슈는 수정하고 배포할 때까지 이슈 관리하고, 배포할 경우 파생 결함을 찾기 위해 수정 부분 외에 영향도 테스트를 한다. 이런 이슈가 많은 프로그램의 경우 안정된 버전을 만들기 위해서는 정기적 테스트를 통해 배포되는 패치를 유도하는 것이 좋다. 정기적 테스트에는 처리된 이슈가 요구사항과 일치하는지 확인하는 인수 테스트와 파생 결함이 없는지 회귀 테스트를 수행한다.
신규로 추가되는 기능 및 스펙 변경 이슈는 개발 기간의 프로세스와 유지보수 프로세스가 섞여 있다. 신규 및 변경되는 부분은 그 부분대로 요구사항 분석과 아키텍처 설계, 설계상세 구현 및 단위, 통합 테스트, 시스템 테스트, 인수 테스트를 수행한다. 그리고 완료되면 추가 및 변경된 기능에 의해 발생하는 파생 결함을 확인하기 위한 회귀 테스트를 수행한다.
새로운 환경에 대한 보증절차는 신규 OS가 시장에 나온다던가, 관련 모듈의 업데이트가 필요할 경우 이에 영향을 받아서 발생하는 문제가 없는지 확인하는 절차다. 먼저 기술 검토를 하고 테스트를 통해 현재 품질 목표에 부합하는지 확인하는 과정을 밟는다.
QA 활동 향후 방향
● QA는 테스트를 탈피하자
다시 한 번 강조하지만 QA는 테스트만 하는 것이 아니고, 테스트만 해서 품질을 높일 수는 없다. 프로그램이 완료된 이후 테스트는 문제 제시일 뿐이다. 고품질의 프로그램을 만들기 위해서는 개발 전 요구사항 분석을 정확하게 하고, 프로젝트 규모에 맞는 품질 목표를 정해야 한다. 이후 테스트 아키텍처와 품질 리스크 분석을 한다.
이를 기반으로 개발 기간 지속적인 품질 관리를 해야 한다. 지속적인 품질 관리란 품질 리스크 분석에서 리스크가 높은 부분 위주로 품질 수준을 설계 및 구현자와 공유하고, 구현자가 공유한 품질 수준을 위한 개발을 해야 한다. 지속적인 대화를 통해 도출되는 이슈를 해결하면서 요구사항을 추적하고 품질 목표와 품질 리스크를 보완해 나가며 올바른 제품을 유도하는 과정이다. 테스트는 그 이후 문제다.
● 다양한 기술을 습득하고 품질을 연구하자
지금은 소프트웨어 세상이라고 할 수 있다. 스마트폰을 비롯한 각종 웨어러블 기기는 이미 우리 생활의 일부가 됐다. 다양한 형태로 진화하는 소프트웨어는 사용자로 하여금 더 편리하고 안전하며 빠른 품질을 요구하고 있다. 때문에 QA 전문가는 더욱 많은 기술을 필요로 한다.
요구사항을 다양한 관점으로 분석하기 위한 요구공학, 다양한 사용자의 패턴 및 관심분야를 파악하기 위한 빅데이터 지식, 자율주행 자동차나 농업에서 부각되는 IoT에서 요구되는 위험성을 확인하는 안전 전문가, 핀테크 같은 금융의 안정된 거래를 위한 소프트웨어의 보안 지식을 비롯해 각종 이슈로 쏟아져 나오는 정보를 수치화하고 통계를 내는 기술 등 다양한 능력들이 요구된다.
필자 또한 QA에 몸담은 실무자로서 빠르게 변화하는 환경에서 QA 전문가들이 어떤 방법으로 품질을 관리하고, 기술 발전에 따라 파생되는 문제들을 예방할 수 있을지 기대된다. 새로운 방법과 기술은 소프트웨어 밖에서도 찾을 수 있다. 다양한 지식을 습득하고, 편견들을 깨나가면서 사용자를 연구하고, 사용자가 좀 더 안전하고 편리하게 소프트웨어 세상을 살 수 있도록 품질에 대한 관심과 노력이 필요한 시기다.
품질은 QA 전문가의 노력만으로 높아지지 않는다. 개발에 투입되는 모든 전문가와 관리자가 품질에 대한 관심과 노력을 기울이고, 여기에 품질 관련 기법들이 더해질 때 소프트웨어는 안정된 높은 품질을 보증할 수 있다. |
webmaster@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
