[팀블로그] 소프트웨어 테스팅 참고서

     

 

질문

챕터 1.2.1의 "성공을 위한 테스팅의 기여" 부분에 보면, 대표적인 예로 든 「요구사항 리뷰」를 언급했는데, 요구사항은 기획자가 리뷰하는 것이 아닌가요? 테스트를 하다가 요구사항 리뷰도 할 수 있나요? 

 

ISTQB 버전

ISTQB Syllabus 2018

 

답변

본 글은 2개로 나누어 구성하였습니다. 현재 보고 계시는 글은 두 번째 편으로 요구사항에 대한 좀 더 깊은 이야기에 대해 설명하고 있으며 기본 이해 편에서는 요구사항에 대한 기본 개념과 테스트와의 관계에 대한 설명하고 있으니 해당 부분도 함께 참고하여 주세요.

요구사항 리뷰를 왜 해야 하나요?

 전쟁터 같았던 직장생활을 뒤로하고 이제 꿈에 그리던 멋진 은퇴를 꿈꾸는 당신. 저 푸른 초원 위에 그림 같은 집을 지어서 제2의 인생을 꿈꾸며 살아가고자 합니다. 그래서 이제 정말로 집을 짓고자 합니다. 잔디가 있는 넓은 마당에서 친구들과 바비큐를 하고, 수영장에서 운동을 즐기며, 나만의 영화관에서 영화를 보고, 밤이 되면 쏟아지는 별들과 함께 잠이 들어 큰 창문으로 들어오는 아침 햇살에 눈을 뜨는 아침을 시작할 수 있는 집을 여러분들도 원하시는지요?

 

 무엇을 꿈꾸던 당신이 원하는 집을 지으려면 이렇게 당신이 원하는 것이 무엇인지 하나씩 나열해 봐야 합니다. 그것들이 모이면 짓고 싶은 집을 어떻게 만들지에 대한 기초가 될 것이며 그것을 바탕으로 집을 만드는데 길잡이가 될 것입니다. 이와 비슷하게 소프트웨어 개발의 기초는 요구사항입니다. 요구사항이란, 어떤 소프트웨어를 만들고 싶어 하는 것인지 나열한 것을 바탕으로 어떤 기능이 어떻게 동작해야 할 것인가를 프로젝트 참여자들이 이해할 수 있도록 만든 기록물이며, 그것을 바탕으로 우리는 개발을 하고, 테스트를 하고, 마케팅을 할 수 있습니다. 머릿속에만 있는 것을 개발할 수는 없으니 문서나 그림 등을 만들어서 공유해야 하는데 여기서부터 어려운 부분이 시작됩니다.

 

 자, 그럼 저 푸른 초원 위 집에 그네를 하나 설치해 볼까요?

프로젝트가 어떻게 흘러가는가를 보여주는 예제

 

 지금 이 글을 읽고 계시는 독자분은 어떤 그네를 원하셨나요?

 

 누군가의 머릿속에 있는 생각을 남에게 설명할 목적으로 이야기를 풀어내는 건 참으로 어렵습니다. 말로 하면 금방인데, 글로 전달을 하려니 더 어렵게 느껴집니다. 내 생각을 표현한다는 데 있어서 어려운 점이 한두 가지가 아니지만 그래도 열심히 글 쓰고 그림을 그려서 요구사항을 전부 담아서 문서를 작성합니다. 자, 그러면 요구사항은 문서로 작성하고 나면 끝일까요? 이 문서가 일관성 있게, 적절한 설명과 함께 모두 이해할 수 있는 수준으로 작성된 것인지 확인을 해야 합니다.

 

 이 문서는 한 사람만이 보는 문서가 아닙니다. 소프트웨어 개발자뿐만 아니라 영업, QA , 디자인, PM, 사장님 등등 프로젝트 전반에 참여하는 이해관계자들이 함께 보는 문서입니다. 모든 사람들이 한 번에 이해하고 바로 프로젝트 진행할 만한 문서였다면 좋겠지만 세상 일이 그렇게 쉽지 않다는 것은 누구나 다 알 것입니다. 각자의 관점이 다르고, 실무에서 활용하는 용어가 다르고, 이해관계가 다르다 보니 해석을 다르게 할 수도 있고, 수정을 요청할 수도 있고, 이해관계가 충돌해서 진행을 하느니 마느니 하는 논쟁이 생길 수 있습니다. 그 모든 의견을 반영해서 다듬고 수정하는 "관리"라는 것을 해야 합니다. 이 작업이 바로 「요구사항 관리」이며, 이를 위해 수행하는 활동 중 하나가  「리뷰」 활동입니다.

 

 "기초가 중요하다"라는 말은 지겹지만 자주 듣게 되고, 또 강조되는 말입니다. 그만큼 현실에서는 잘 되지 않기 때문입니다. 기초를 대충 만들고 집을 짓다 보면 부실공사가 될 가능성이 큰 것처럼, 요구사항이 잘 정의되어 있지 않으면 만들 소프트웨어도 부실공사처럼 문제가 많이 생길 수 있을 가능성이 커집니다. 초반부터 리뷰를 꼼꼼히 하지 않고 진행하다가 개발 막바지에 문제가 터진 것을 확인하게 되면, 호미로 막을 수 있었던 일을 포크레인을 써도 막기 어려운 상황까지 가게 될 수 있습니다. 어렵지만 우리는 아주 가벼운 호미로도 모든 이슈 처리가 가능하도록 하기 위해 요구사항 관리와 테스팅을 위한 리뷰 활동을 진행해야 합니다.

 

📣 필자 주1 「요구사항 관리」라는 건 하기가 참 어렵지만, 이에 더해 더 심각한 문제는 요구사항 관리를 제대로 하는 사람 혹은 경험해 본 사람을 구하기가 정말 어렵습니다. 또, 요구사항 관리는 Safety Critical 영역에서는 반드시 필요하지만, 대한민국처럼 즉각적인 소비자의 반응이 더 중요한 서비스 수준의 프론트엔드에서는 사용자의 의견을 즉각 반영할 수 있는 시스템 설계가 더 중요하게 부각됩니다. 그래서 이런 시스템들은 대부분 서버단의 영역만 요구사항 관리를 하는 경우가 많습니다. 이런 시스템이 Cloud에 올라가 있는 경우, DB와 API 단의 설계들을 중심으로 서버의 확장성에 따른 비용이 발생하기 때문에 SRS(Software Requirement Specification) 보다는 SDS(Software Design Specification)에 무게를 두게 됩니다. 한국의 IT 시장이 발전하면서 한국 특유의 「빨리 빨리 문화」와 「애자일 문화」가 겹쳐지며 '요구사항 전문가 부재'라는 문제점을 낳은 건 어쩌면 피할 수 없는 필연이 아닐까 싶습니다.

 

 

일반적인 실무에서의 리뷰

 이런저런 이유들로 우리는 일반적으로 실무를 진행할 때는 요구사항 관리를 거의 하지 않습니다. 실무를 진행할 때는 요구사항을 관리를 해야 하는지, 아닌지에 대해 큰 관심도 없고, 필요성도 잘 느끼지 못하고, 어렵고, 애자일 철학과 뭔가 맞지 않는 느낌이 드니까요. 그래서 '기획 리뷰 정도로 충분하지 않나...' 하고 일상적으로 치부하고 넘어가게 됩니다. 그리고 이렇게 진행하면 "매번", 그리고 "항상" 거의 모든 상황에서 프로젝트의 기획 담당자에게 꽤나 많은 부하를 발생시키게 됩니다. 이는 바로 요구사항 리뷰 활동을 하지 않아서 발생하는 현상입니다. (조직 내에 기획만 하는 담당자가 있으면 그나마 다행이겠지만요...)

 

 요구사항 리뷰를 명확하게 하지 않고 기획 단계의 산출물을 기준으로 업무를 진행하겠다 함은 사실 무척이나 현실적인 가정 사항을 기반으로 작동하게 됩니다.

  ① 요구사항을 낸 담당자들은 대부분 임원급 사람들의 의견을 기반으로 진행하기 때문에 그들이 틀렸을 리 없다

  ② 그들이 틀렸어도 내 책임이 아니다

  ③ 힘없는 일개 노동자인 내가 요구사항 관련해서 의견을 개진해서 책임을 지기 싫고, 기획으로 만들어 오면 거기서부터 보겠다.

...정도의 방어적이고 보수적인 태도에서 개발에 참여하게 됩니다. 우리는 모두 힘없는 월급쟁이 엔지니어일 뿐이니까요.

 

 그런데, 그래서 생기는 실무의 문제들이 있습니다. 요구사항에 대한 리뷰를 하지 않으면 기획을 세부적으로 만들어가면서 발생하는 문제들에 대해 도움을 받기 힘들기 때문에 기획 담당자들에게 너무 큰 부하와 부담이 생기는 점, 그리고 앞단의 잘못된 부분에 대해 누구도 리뷰를 해 주지 않고 진행하면서 발생하는 기획/개발 업무의 부하입니다. "뭐든 앞단에서 바로 잡아야 제대로 잡힌다"라는 부분은 사실 소프트웨어를 개발해 본 사람이라면 누구나 알고 있는 만고의 진리입니다. 그런데 앞에서 리뷰를 제대로 하지 못해서 나중에야 문제가 있음을 발견하게 되고, 이를 수정하려고 했을 때는 이미 구조적인 설계상 더 이상 개선할 수 있는 한계로 인해 덕지덕지 땜빵을 하게 되거나 눈덩이처럼 불어나 버린 이슈에 대한 근본적인 해결이 불가능한 상태로 발전한 무서운 괴물이 될 가능성이 높습니다.

 

 이와 관련해서 이해를 해보고 싶으신 분들은 본 블로그의 다른 글인 "소프트웨어 테스팅의 7가지 원리 - 3. 조기 테스팅" 포스팅과 "개발 초기에 테스팅하라" 포스팅을 참고하시면, 소프트웨어 테스팅과 관련된 원론적인 추가 내용들을 보실 수 있습니다.

 

 단순한 모바일 앱을 하나 만드는 경우에도 UI를 어떻게 어느 정보를 가지고 배치할 것인지, 백엔드(backend)를 어떻게 구성해야 좋을지, 단순해 보이는 기능 뒤에 숨겨진 개발의 난이도는 어떻게 해결을 해야 할지, 성능은 어느 정도 수준을 맞춰야 하는 것인지, 호스팅과 서버는 어떻게 얼마나 구성하고, 유지 비용은 얼마나 청구가 될 것인지 등등  셀 수 없는 고려해야 할 사항들이 가득한데 이런 고민들은 미리 하지 않고 막상 닥쳐야 그때부터 고민하기 시작하는 게 일반적인 실무 환경에서 일어나는 일입니다. 그래서 다들 관련 일을 해본 경력자의 누군가가 해결해 주기를 바라고 있습니다. 

 

📣 필자 주3 - 이 글을 읽으시는 분들의 회사에 어느 정도 경력이 제대로 쌓인 「테스트 전문가」와 함께 하고 계시다면, 그들은 이상할 정도로 개발 프로세스의 앞단으로 진출하려고 노력을 하는 모습을 관찰하게 되실겁니다. 누군가의 입장에서는 "왜 테스터들과 QA들은 뽑아 놓으면 자꾸 정치를 하려고 하지?" 하고 생각하실 수도 있겠습니다만, 사실 그들의 이런 행동(개발 프로세스의 앞단으로 나아가 참여하려는 행동)은 소프트웨어 테스팅을 업으로 삼은 사람이라면 누구나 해야만 하는 당연한 전문성을 발휘한 행동입니다. 마치 프로그래머들이 더 쉽고 강력한 라이브러리를 찾고, 제품에 더 알맞는 좋은 패턴을 찾으려고 노력함과 같이 Testing 분야의 전문가들은 「요구사항과 그 요구의 본질을 향해 테스팅의 칼날을 세워야 품질이 좋아짐을 본능적으로/이성적으로 깨달아 하는 행동」일 뿐 「사내 정치」와 전혀... 0.1그램도 관련이 없습니다. (그러니 "요구사항까지 테스트 범위에 넣어야 한다"라 주장하고 실제로 할 수 있는 사람을 만나거든 모셔서 채용하십시오. 정말 흔하지 않습니다.)

 

 

요구사항 리뷰는 어려운 거 맞죠? 그럼, 어떻게 시작하면 좋을까요?

 예, 맞습니다. 요구사항 리뷰는 어렵습니다. 요구사항 리뷰를 실제로 진행해 보면 시간이 오래 걸리는 작업이고 결과물이 번듯하게 나오는 것이 아니다 보니 요구사항 리뷰를 프로세스로 넣어 진행 하자는 당위성을 현실에서 찾기도 어렵습니다. 리뷰 자체에 대한 필요성을 느끼지도 못하고 한다고 해서 무언가 눈에 띄게 나아지는 것이 보이지는 않으니까요. 언젠가 소프트웨어 업계 전반의 이해가 발전하기를 바랍니다만, 현재로서는 그렇습니다. 그러니 프로세스가 조금이라도 갖춰져 있다면 그걸 활용하면 되겠지만 그마저도 없다면 매번 프로젝트마다 삽질하는 것을 반복하기를 싫으니 그 현실적인 상태에서 본인이 하실 수 있는 게 무엇인지 찾아야 합니다. 

 

 먼저 무언가 화려해 보이는 리뷰 활동보다는 테스팅 업무를 하면서 하나씩 찾아가야 합니다. 하나씩 찾아가면서 이를 해결할 방법들을 찾다 보면, 자연스럽게 테스트 전문가들이 요구사항 관리 단계 내로 들어가게 됩니다. 앞으로, 앞으로 나아가 테스트를 시작하기 전에 테스트 케이스를 만들기 시작할 때부터 기획과 구현 사항을 리뷰해야 합니다. 테스트를 수행하면서도 리뷰를 할 수 있겠지만, 그 시점은 이미 기획과 구현이 많이 완료된 상태이므로, 기획이든 구현이든 시작 단계에서부터 리뷰 할수록 효과는 좋아집니다. 그렇기 때문에  어떤 단계이든 가능한 한 빨리 시작을 해야 합니다. 요구사항을 만들 때 같이 참여하면 더 좋겠지만 보통 대부분의 회사에서는 테스터들에게 그런 기회가 주어지지는 않습니다. 

 

이와 관련한 예들은 본 글의 1편 "테스팅을 하면서 요구사항 리뷰도 할 수 있나요?" 포스팅을 참고하시면 테스트를 하면서 어떻게 진행해야 할 것인지에 대한 감을 익히실 수 있을 것입니다. 

 

 단순히 이슈를 찾는 활동이 안정화되어 좀 더 높은 단계로 가고자 하시면 테스트를 하고, 버그를 찾고, 버그를 유형별로 정리하고, 반복되는 이슈들을 확인하여 정리하고, 분류해야 합니다. 그리고 프로젝트 종료 후 그 이슈들의 원인, 근본적 성질을 고민해야 합니다. 그리고 이를 예방하기 위한 방안과 예방 활동을 하지 않은 경우에 대한 비용, 일정, 내부 인원의 역량 등의 상관관계를 고려하여 개선해야 합니다. 그렇게 해서 설계 > 기획 > 요구사항의 순서대로 차분히 앞단으로 나아가야 합니다. 최종적으로는 요구사항들을 명확히 정의하고, 정리하여 사업/개발 관리 가능한 형태로 만드는 게 목표입니다. 

 

📣 필자 주 - 4차 산업혁명이 진행되는 사회는 필연적으로 소프트웨어와 하드웨어의 경계가 모호해지는 산업들이 발생하게 됩니다. 이런 상황에서는 빠르게 구현하고 피드백을 받아 처리하는 사업적 비용보다 예방하고 평가하는 품질관리 방식이 더 잘 통하는 사업군이 발생하게 됩니다. 그래서 결국 요구사항 리뷰를 할 줄 아는 테스터를 보유했으냐, 아니냐는 기업의 경쟁력으로 나타나게 될 걸로 예상합니다. 요구사항 리뷰까지 할 줄 아는 사람은 대략 15년(최소 10년) 이상의 경력을 가진 테스터들인데, 이런 사람들을 회사에서 연봉이 비싸다는 이유로 채용을 꺼리는 경우가 많습니다. 자동차, 금융, IoT로 가려는 회사들은 BA조직을 확보하시거나, 요구사항 리뷰를 할 줄 아는 테스트 전문가를 채용하시라고 조언드리고 싶습니다.

 

 

요구사항 리뷰를 굳이 테스트 전문가가 해야 하나요? 

요구사항 관련 이야기를 실무에서 하기 시작하면 가장 자주 듣는 이야기 중 하나가 "요구사항 리뷰를 할 거면 그냥 프로그래머가 Test Driven 하면 되지 않나? 굳이 테스트 전문가가 요구사항 리뷰 단계에 참여해야 해? 테스터들은 개발 잘 모르잖아. 테스터들이 할 수 있는 거 맞아?"

 

요구사항의 리뷰를 테스트 전문가들이 해야 하는 이유는 「테스트 전문가들의 직업병」과 연관되어 있습니다. 일반적으로 한 회사에서 꽤 오랜 근속연수를 가진 테스트 전문가들은 그 회사에서 이력(History)을 담당하는 경우가 많습니다. 왜냐하면 (제품/서비스의 품질을 다루다 보니 생기는 직업병으로) 테스트 전문가들은 제품과 서비스의 프로젝트 내/외부에서 발생하는 여러 가지 이슈들의 발생과 해결 과정까지의 일에 관여하게 됩니다. 그런 상황들이 지속되면서 결과적으로 테스트 전문가들은 그 회사의 제품/서비스 이슈들의 이력을 가장 잘 아는 존재가 되는 경우가 발생합니다. 오래된 제품/서비스일수록 그런 현상은 더욱 두드러집니다.

 

그래서 하나의 제품/서비스에서 오랫동안 제대로 일 한 테스터 전문가들은 새로운 요구사항을 접하고 그에 따른 다른 기능의 연관관계를 유추할 수 있으며 그 외 발생될 수 있는 요소를 요구사항 리뷰 단계에서 찾아 줄 수 있는 수준까지 발전하게 되며, 이렇게 다방면에서 리뷰/계획/설계/수행 역량을 가진 사람들을 우리는 (테스터가 아닌) "QA(Quality Assurance)"라고 부릅니다.  

 

📣 필자 주 - Tester가 QA인게 아닙니다. 실무에서는 흔히 대충 Test하는 사람을 QA라고 부르고, "Test 기간"을 "QA 기간"이라 부르며, "Test 환경"을 "QA 환경"이라 부릅니다. 하지만, 필자들이 누누히 주장하는 바와 같이 '요구사항'과 관련되지 않은 버그/문제점을 찾는 활동은 QA라 호칭하면 안됩니다. 그 이유는 QA라는 단어를 별도로 독립시켜야, 소프트웨어 품질에서 가장 중요한 '요구사항 관리'라는 항목을 다룰 명확한 역할을 가진 사람들을 확보할 수 있기 때문입니다.

 

 

굳이 QA를 양성해야 할까요? 우리는 애자일 하기 때문에 테스터로도 충분한데요. 

 사실 이렇게 요구사항을 리뷰하고 다룰 수 있는 전문가로 테스터를 양성하여 QA 수준으로 끌어올리는 이야기는 그 누구보다 각 기업의 CTO들에게 가장 좋은 소식입니다.

 

 프로그래머들은 경력이 쌓이면 시니어 혹은 아키텍트로 발전할 수 있고, 서버 전문가, 데이터 전문가 등으로 발전할 수 있습니다. 하지만 테스터들은 어떻게 성장시킬지 감이 잘 안 오셨죠? 테스터는 경력이 15년이 되어도 테스터인 경우가 많습니다. 그런데 현실의 경험을 기반으로 보건대 테스터들은 위에서 설명한 바와 같이 프로젝트 내부, 혹은 제품/서비스 론칭 후 외부로부터 들어오는 여러 이슈들을 다루면서 요구사항 관리에 자연스럽게 눈을 뜨게 됩니다. 그래서 이 사람들을 훈련시켜 조직 내에서 요구사항 리뷰 전문가로 발전시킬 수 있습니다. 이 요구사항 리뷰를 잘하는 사람들은 대부분 10년 이상 정도 품질에 대해 심각히 실무를 해 본 사람들인 경우가 많으며, 15년 정도 경력이 쌓여야 조직의 요구사항들을 리딩(Leading) 할 수 있다고 (필자들은) 생각합니다.

 

 사실 이렇게 제품/서비스의 문제점들을 요구사항 관점에서 관리하고, 다루어 품질을 향상하는 직군을 BA(Business Analyst)라고 부릅니다. 모든 테스트 전문가들이 QA팀장이 될 필요는 없습니다. 리더로서의 성향을 가지지 못한, 엔지니어로서의 관점 역량을 가진 사람들도 많습니다. 그런 사람이라면 BA로 훈련시켜 그 역량을 향상해 사업부와 소프트웨어 기획 부서 사이에서 발생하는 요구사항의 해석, 관리, 현업과의 커뮤니케이션 등을 담당하도록 할 수도 있습니다.

 

BA를 사업 부서 하에 둘 지, 개발 부서 하에 둘 지에 대해서는 필자들의 의견을 피력하지 않겠습니다. 왜냐면 각 회사의 상황에 따라 다를 듯해서입니다.

 

 

마무리 이야기

 어떤 독자는 본 포스팅의 내용이 너무 일반론적이고 당연한 내용이라고 생각할 수도 있습니다. 네, 맞습니다. 저희도 '실무편'이라고 해 놓고 사실적인 이야기를 많이 하지 못하는 점이 아쉽습니다. 소프트웨어 테스팅과 품질 관련된 실무 이야기를 하면 실제 있었던 일들을 이야기하게 되다 보니 아무리 각색하더라도 어떤 회사인지, 어떤 프로젝트인지 정보가 글 속에서 비추어지는 경우가 많아 조심스럽습니다.

 

 이런 이야기들은 '콩으로 메주 쑤고, 쌀로 밥 짓는 소리' 같이 일반적인 내용 같이 들릴 수도 있습니다. 그런데, 그런 당연하고 일반론적인 요리의 기본 토대 위에서 누군가는 끝내주는 김밥을 만들어 우리를 천국에 온 듯 행복하게 하고, 또 누군가는 미슐랭 스타 셰프가 되기도 합니다. 과연 기본기가 없이 그런 훌륭한 음식들을 만드는 게 가능할까요? 세상 모든 일은 일반론적인 이론의 토대 위에서 현실의 문제점들을 해결하는 방식으로 진행되어야 하고, 그게 기본입니다. 기본기가 부족한 상태에서 실무만으로 그런 높은 경지에 이르기는 쉽지 않습니다. 기본적인 내용이 지켜지지 않으면 절대 좋은 품질의 결과물을 만들어낼 수 없습니다. 

 

 그래서 필자들은 계속 강조합니다. 소프트웨어도 마찬가지입니다. 요구사항 관리, 리뷰 활동에 대해서는 글의 초반에 언급한 바와 같이 '요구공학(Requirement Engineering)'이라는 분야가 따로 있을 정도로 넓고 깊은 지식이 존재합니다. 그런 이론들을 이해하고, 기본기 위에서 우리 회사에서 발생하고 있는 이슈 사항들을 조절하여 해결할 수 있는 것. 그런 활동을 테스팅 활동, 테스팅 분야에서 수행할 수 있다면 바로 여러분이 「테스트 전문가」입니다. 그래서 필자들은 이번 글에서 가능한 소프트웨어 테스팅 실무, 소프트웨어 품질관리 실무 관점에서의 현상들, 이슈 사항들을 나열하였습니다. 그리고 테스트를 하거나 준비를 하면서 만날 법한 상황을 가정하거나 겪은 일들을 중심으로 이야기를 풀어보았습니다.

 

 어쩌면 어떤 독자분에겐 '굳이 이렇게 까지 해야 하나' 싶을 수도 있고, '내 업무를 벗어난 것이 아닌가' 하는 생각이 들 수 있습니다. 그런 생각이 들어도 이상하지 않은 게 현실입니다. 현실의 야생(실무)에서는 아직 소프트웨어 테스팅 전문가를 제대로 활용하지 못하는 회사들이 많습니다. QA와 Testing을 구분하지 못하거나, 구분하는 행위에 대해 못마땅해하는 실무자들도 많습니다. 그래서, 본 글에 언급한 내용들까지 하지 않아도 월급 받는데 지장이 없습니다. 그렇기에 필자들은 현실에 만족하고 사시는 분들에게까지 변화를 강요할 생각이 없습니다.

 

다만, 이런 글을 찾아 읽을 정도의 당신이라면(우연히 들어왔다고 하더라도), 현재 자신이 처한 답답한 현실이나 한계에 대한 해답의 실마리를 찾는 당신이라면, 오늘보다 더 나아진 것을 바라는 당신이라면, 더 나은 품질을 달성하기 위해 소프트웨어 테스팅을 위한 요구사항 리뷰를 실천해 보시기를 바라는 마음으로 글을 써보았습니다.

 오늘도 당신의 성공적인 테스터 생활을 응원합니다. 

 

 

참여자 정보

글쓴이 : Bykj, 천년나무 

• 검토한이 : 아이티마니 

 

 

STEEG 개인 의견

※ STEEG 개인 의견은 각 전문가 개인이 경험한 경력에 따른 의견이므로, 주관적 견해가 개제될 수 있습니다. 개인 의견에 대한 내용은 본 블로그와 관련이 없습니다.

 

 

관련 참고자료

※ 아래는 필자들이 선정한 관련 외부 자료입니다. 
아래 자료들은 필자들이 작성한 본문 의견과 다를 수 있으며, 필자들과 관련되지 않았을 수 있습니다.
 

Learning from history: The case of Software Requirements Engineering – Requirements Engineering Magazine

1 Introduction In this paper, we identify politics and power as crucial components of requirements engineering (RE) and argue that the role it plays, especially…

re-magazine.ireb.org

 

A history of the international requirements engineering conference (RE)RE@21

This paper traces the history of the International Requirements Engineering Conference from its beginnings as the International Symposium on Requirements Engineering and the International Conference on Requirements Engineering. The history is tracked to th

ieeexplore.ieee.org

 

Safety-critical system - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search System whose failure or malfunction may result in death, injury or damage to equipment or the environment A safety-critical system (SCS)[2] or life-critical system is a system whose fa

en.wikipedia.org

 

Requirements Review – Why is It Important? | Solbeg

Our Business Analyst, Victoria Aleshko, would like to share her experience in setting up a clear and effective Requirements Review process on the project. The idea of the project came to mind to our clients not so long after the global pandemic hit the wor

solbeg.com

 

 

이 글을 공유합니다.

facebook twitter kakaoTalk kakaostory naver band