QA 엔지니어가 하는 일

What a QA engineer does
QA 엔지니어가 하는 일

    Write test plans from the requirements, specifications and test strategies
    Use versioning systems to code test scripts
    Create and perform test campaign whenever it is necessary to fit in the overall planning
    Use bug tracking database to report bugs
    Analyses test results
    Reports results to the QA manager
    Raise an alert when an important issue is likely to put in jeopardy the whole project
   

    요구조건, 명세서 그리고 strategy 에 근거해 Test Plan을 만든다.
    test script를 코딩할 때 versioning (형상관리) system (CVS) 을 사용한다.
    전체 계획에 맞게 각 개발 단계마다 테스트 업무를 생성하고 진행한다.
    버그를 보고 하기 위해 버그 tracking database를 사용한다.
    테스트 결과를 분석한다.
    QA manager에게 결과를 보고한다.
    전체 프로젝트에 악영향을 끼칠만한 주요한 문제가 발견 되면 신속하게 보고하고 대처한다.

    What makes a good QA Engineer
무엇이 좋은 QA 엔지니어를 만드는가

Broad understanding of the product
제품에 대한 넓은 이해

To test efficiently a product, the QA engineer must know it well enough. This sounds obvious must unfortunately, this is often under-estimated. Knowing well the product includes also knowing how end-users expect it to work. Again this may sound obvious but remember that the biggest part in testing is black-box testing. The QA engineer must have a "customer-focus" vision.


제품을 효율적으로 테스트하기 위해서 QA엔지니어는 그 제품을 잘 알아야 한다. 당연하게 들릴 지 모르겠지만 불행히도 이 사실이 종종 과소평가된다. 제품을 잘 안다는 뜻은 최종 소비자(일반 사용자)의 기대치를 잘 이해하는 것도 포함된다. 너무나 당연한 얘기이지만 꼭 기억해야 할 것은 테스트 중에 제일 큰 부분이 블랙 박스 시험이라는 것을 기억하라. QA 엔지니어는 "고객에게 맞춘" 시선을 가져야 한다.

  But a good QA engineer must also know how the product is designed because the more you know the product, the better you're able to test it. However, the QA engineer will have to analyse the design only after his black-box testplan is completed. Indeed, knowing the design can widely influence the test strategy. It is better to first write the test plan with a high-level vision, then getting more and more information to refine the testing.


좋은 QA 엔지니어는 제품이 어떻게 디자인 되었는지 알아야 한다 왜냐하면 제품에 대해 더 잘 알수록 그것을 더 잘 테스트 할 수 있기 때문이다. QA 엔지니어는 그의 블랙박스 시험 계획이 완성된 후에 디자인을 분석해야 한다. 실제로, 디자인을 아는 것이 시험 전략에전반적인 영향을 미친다. 높은 레벨의 관점에서 test plan을 먼저 쓴 다음에, testing을 refine 하기 위한 좀 더 많은 정보들을 얻는 것이 좋은 방향이다.

Effective communication
효과적인 커뮤니케이션


Communication is an extremely important skill for a QA engineer. Of course, meetings (stand-up etc.) and status reports are part of the communication but more importantly, a QA engineer must be particularly efficient in the following tasks:

커뮤니케이션은 QA엔지니어에게 너무나도 중요한 기술이다. 당연히, 회의(stand-up 등)나 상황 보고는 커뮤니케이션의 일부인데, 더 중요한 것은 QA 엔제니어는 밑에 적힌 것들에 특히 더 능률적이어야 한다.    

    Direct communication with both Development and Product definition teams
    Capability to communicate with technical and non-technical people
    Having the diplomacy to say "no" when a bug is considered as not fixed
    Having the diplomacy to communicate about a bug without "offensing" the developer. Developers may often feel offensed when a bug is submited. This is 100% natural. This is why the QA engineer must have the ability to "criticize without offensing"
    Do not rely on "bug tracking" database for communication! there is nothing better that a bug tracking system to create "misunderstanding" between Development and QA teams


    개발, 제품 정의 팀과 직접적인 소통
    기술자들과 기술자가 아닌 사람들과 소통하는 능력
    버그(오류)가 고쳐지지 않은 것으로 간주될 때 "안된다(고쳐지지않았다)"라고 말할 수 있는 외교능력
    버그에 대해 이야기 할 때 개발자를 공격하지 않고 소통하는 외교능력.
    오류가 발견되었을 때 개발자들은 기분이 좋지 않을 수 있다. 이건 100% 자연스러운 일이다. 이것이 바로 QA 엔지니어가 (남을) 깎아내리지 않으면서 비평할 수 있는 능력을 가져야 하는 이유다.
    소통할 때 버그 추적 데이터베이스에 의지하지 마라! 버그 추적 시스템은 개발자와 QA 팀 사이에 오해를 만들기에 더 없이 좋은 시스템이다.



Creativity
창의성


Testing requires a lot of creativity. Bugs are often hidden and just performing the obvious positive tests will have only a few chances to actually find bugs. Hence, the QA engineer must use its creativity to figure out all the scenarios that are likely to detect a bug. In other words, the QA engineer must be able to "see beyond the obvious".


시험은 많은 창의성을 요구한다. 버그는 종종 숨어있을 때가 많고 positive test만을 실행하면 실제로 버그를 찾을 확률은 적어진다. 그러므로, QA 엔지니어는 그들의 창의성을 이용해 버그를 발견할만한 모든 시나리오를 알아내야 한다. 다른 말로 하면, QA 엔지니어는 "see beyond the obvious" 할 줄 알아야 한다.

Development knowledge
개발 지식


Quality Assurance requires knowledge about software development for two basic reasons:

품질 보증은 두가지 이유로 소프트웨어 개발에 대한 지식을 요구한다.    

    Development capabilities are required to eventually code automated tests
    If you know how to develop, you have better ideas on what is "dangerous" to code, so what to test more thoroughly


    automated tests를 코딩할 때 개발 능력이 필요하다.
    개발할 줄 알면, 코드화할 때 무엇이 위험한지를 좀 더 잘 이해할 수 있다. 그래서 무엇을 더 철저하게 테스트 해야하는지 알 수 있다.

Driving for results
결과를 위해 노력하기


A good QA engineer never forgets that the ultimate goal is not only to find bugs but also have them fixed. Once a bug has been found and has been "acknowledged" by the development team, the QA engineer may be required to "convince" people to fix it.


좋은 QA 엔지니어는 최후 목적이 버그를 찾는 것만이 아니라 그것을 고칠 때 까지 관리해야 하는 것이다. 버그가 발견되어 개발팀이 알려주면, QA 엔지니어는 사람들에게 그것은 고쳐야 되는 것이라는 것을 계속 고지시켜야 한다.

     Additionally, getting a nice automation framework with smart tools does not bring anything if it does not find any bug at the end.


또한, 아무리 좋은 툴이 겸비된 자동화 프레임워크이라도 그것이 버그를 찾을 수 없다면 아무 의미가 없다.

    Ask yourself if the automation is going to help to find more bugs and when
    Prioritize your testing tasks on the only important criteria
        How many bugs is this likely going to find?
        How major will be the found bugs (detecting thousands of cosmetic bugs is irrelevant/useless - and often easy - until all major/show-stopper bugs have been found)?


    자신에게 이 자동화(自動化)가 더 많은 버그를 찾는데 도움이 될것인지 물어보라. (언제발견될지도)
    당신의 testing 세부 task 들을 중요한 분야별로 나누어 우선순위를 정하라
        이것이 얼마나 많은 버그를 찾을 것인가?
        발견된 버그가 얼마나 중대한(큰) 것인지(자잘한 버그를 수천개 찾는 것보다 크고(중요하고) 시급한 버그를 찾는 것이 더 의미 있다)