Leaving a memo

customerNameList()      {return element.all(by.css("#items")).
all(by.css(".list-item-title"));} 

This customerNameList() fetches customer name list data.

 step.Then(/^Check sorting$/,  (done: Callback)=> {
   let sorted = [] , unSorted = [];
   let cName = customerViewPage.customerNameList();

   cName.map(function(eachName){
     return eachName.getText().then(function(unSorted){
       return unSorted;
     });
   }).then(function(unSorted){
     let sorted = unSorted.slice();
     sorted = sorted.sort(); //sort the array
     for(let i = 0; i < sorted.length; i++){
       console.log(' Array1  : ' + sorted[i] + 
'  is equals to Array2 : ' + unSorted[i]);
       expect(sorted[i]).is.equal(unSorted[i]);
     }
     done();
   });
 });

Check sorting results.
unSorted[] array will have current customer name list.
sorted[] array is sorting the current customer name list.

compare sorted[] and unSorted[]
if pass then the customer list is sorted properly.

step.Then(/^Check sorting$/,  (done: Callback)=> {
  let sorted = [] , unSorted = [];
  let cName = customerViewPage.customerNameList();
  let i = 0;
  cName.each(function(eachName){
    eachName.getText().then(function(name){
      // unSorted[i] = name.toLowerCase();
      unSorted[i] = name;
      i++;
    });
  }).then(function(){
    sorted = unSorted.slice();
    sorted.sort();
    for(let i = 0; i < sorted.length; i++){
      console.log(' Array1  : ' + sorted[i] + 
'  is equals to Array2 : ' + unSorted[i]);
      expect(sorted[i]).is.equal(unSorted[i]);
    }
    done();
  });
});

This step has the same functionality as above.

let statelist:any;
 let sortedStatelist:any;
 addCustomerPage.state().click().then(()=>{
   addCustomerPage.stateDropDownOptions().then(function (actualListOfStates) {
     statelist=actualListOfStates.slice();
     sortedStatelist=statelist.sort();
     // expect(statelist).to.contains(sortedStatelist);
     for(let i=0;i<sortedStatelist.length;i++){
       expect(statelist[i]).is.equal(sortedStatelist[i]);
     }
     done();
   })
 })

Fetch items from dropdown menu and check sorting status.

JavaScript Array slice() Method

var fruits = ["Banana", "Orange", "Lemon", "Apple", "Mango"];
var citrus = fruits.slice(1, 3);

Orange,Lemon

Definition and Usage

The slice() method returns the selected elements in an array, as a new array object.

The slice() method selects the elements starting at the given start argument, and ends at, but does not include, the given end argument.

Note: The original array will not be changed.

Protractor For Beginners Part 1

6^th Nov 2015 · 5 min read

0

When I started writing automated tests in Protractor, I had never programmed anything before (unless you count learning enough html/css on codecademy to create an incredibly basic, 90’s style webpage). Some of the problems I encountered whilst learning Protractor were very hard to find on Google, which did make my learning a lot slower than I would have liked. Luckily I work with amazing people who are more than happy to share their knowledge which has saved me countless times, but unfortunately there are many people out there who do not have access to such resources. So, I have decided to create a tutorial which documents as many issues as possible that I encountered whilst learning.

Protractor로 automated tests를 쓰기 시작했을 때, 나는 전혀 프로그래밍 경험이 없었다. (codecademy에서 html / css를 충분히 배우지 않아서 90년대 스타일의 아주 기초적인 html 지식만 있는 상태였다). Protractor를 배우는 동안 내가 접했던 여러 어려운 점들은 Google에서 해결책을 찾기가 어려웠다. 그래서 나의 배움은 내가 바라는 것보다 훨씬 더뎠다. 다행히도 나는 자신들의 지식을 공유하는 것을 행복하게 생각하는 많은 사람들의 도움으로 많은 정보를 얻을 수 있었다. 하지만 불행히도 그런 자료들에 접근하지 못하는 사람들도 많이 있다. 그래서, 나는 학습하면서 가능한 많은 것들을 문서화 한 tutorial을 작성하기로 결심했다.

This tutorial will be broken down into bite sized chunks, with each new blog post as a new task, and it is aimed at people with little to no experience of programming. You will be writing the tests for the AngularJs site itself, since this is a good site for practising writing Protractor tests for as it is written in AngularJs; the JavaScript framework that Protractor runs tests against.

이 튜토리얼은 각 단위별로 구분될 것이다. 그래서 각각의 새로운 블로그는 새로운 task가 될 것이다. 그럼으로서 프로그래밍에 거의 경험이 없는 사람들을 대상으로 살 것이다.  여러분들은 AngularJs 를 사용해 대한 테스트를 할 것이다. 왜냐하면 이것은 AngularJs로 작성되었기 때문에 테스트 작성을 연습하기에 아주 안성맞춤이기 때문이다. 

Note: if you get stuck at any point, the entire code can be found in https://github.com/hannimator/angularjs.org_protractor for use as reference. Snippets of the code will be shown as examples throughout.

참고 : 문제가 발생하면 https://github.com/hannimator/angularjs.org_protractor에서 전체 코드를 참조 할 수 있다. 코드의 Snippets에는 예제들이 있다.

Introduction:

To begin with, follow this tutorial https://github.com/angular/protractor/blob/master/docs/tutorial.md. It will run through how to setup Protractor and Jasmine, and the basics of running some simple tests. Another good read, but not necessary for this tutorial is https://github.com/angular/protractor/blob/master/docs/toc.md, which has some more in depth information about Protractor and Jasmine. Once you have completed the above tutorials, follow the steps below.

처음 시작할 때는 https://github.com/angular/protractor/blob/master/docs/tutorial.md)를 참조하세요. Protractor와 재스민을 설치하는 방법과 몇 가지 간단한 테스트를 실행하는 기본 사항을 설명합니다. 다른 유용한 정보들은 https://github.com/angular/protractor/blob/master/docs/toc.md 를 참조하세요.  프로트랙터와 자스민에 대해 좀 더 깊은 내용을 접할 수 있습니다. 이 튜토리얼들을 살펴보시고 난 후 아래 스텝들을 따라해 보세요.

Page Objects, Developer Tools and the DOM

Page objects model the UI objects that your test interacts with inside your tests code. Using page objects keeps the tests easier to maintain (since if anything changes, you only have to change the page objects rather than change every single test). To find these UI objects, open up the browser developer tools by pressing f12 and select the 'elements' tab, or find the element (e.g. a button), right click and select 'Inspect element' from the dropdown list. For this example, use the AngularJs site. Right click on the 'View on Github' button and select 'Inspect element'. Observe the line

   <a class="btn btn-large" href="https://github.com/angular/angular.js">
      <i class="icon-github-sign"></i>
         "View on GitHub"
   </a>

Is highlighted.

Page objects model의 UI objects는 여러분이 작성한 테스트 코드 내부와 상호작용하게 됩니다. 페이지 객체를 사용하면 테스트들을 더 쉽게 관리 할 수 있습니다 (변경 사항이 있으면 모든 단일 테스트를 변경하는 대신 페이지 객체 만 변경하면됩니다). 이러한 UI 개체를 찾으려면 f12 키를 눌러 browser developer tools을 열고  'elements' tab을 선택합니다. 혹은 element (예 : 버튼)를 찾아 마우스 오른쪽 버튼으로 클릭 한 다음 드롭 다운 목록에서 'Inspect element'를 선택합니다제. 이 예에서는 AngularJs 사이트를 사용합니다. 'View on Github' button을 마우스 오른쪽 버튼으로 클릭하고 'Inspect element'를 선택하십시오. 선이 강조 표시되어 있는지 확인하십시오.

For this element (or page object) you can see the classname is “btn btn-large”, so when you write the page object, write it like this:

이 element (또는 page object체)의 경우 클래스 이름이 "btn btn-large"라는 것을 알 수 있으므로 page object를 작성할 때 다음과 같이 작성하십시오.

       
    var pageObjectName = element(by.css(“.btn.btn-large”));
       

The reason it is written as ".btn.btn-large" rather than "btn btn-large" is down to locators, which are what tell Protractor where to find certain elements. A CSS selector would look like this: ".someCSS", whereas an ID selector would look like this: "#someID". Some more information on this can be found in the Protractor documentation

"btn btn-large"가 아닌 ".btn.btn-large"라고 쓰여진 이유는 Locator에 있습입니다. 이것은 Protractor에게 특정 elements를 어디에서 찾을지 알려주는 것입니다. CSS selector는 다음과 같이 보일 것입니다 : ".someCSS" 반면 IDselector는 "#someID"와 같이 보일 겁니다. 이것에 관한 더 많은 정보는 Protractor documentation 에서 찾을 수 있습니다.

If you want to learn a little bit more about the DOM which is mentioned throughout this tutorial, I have found https://css-tricks.com/dom/ to be a very useful and concise explanation.

이 튜토리얼에서 언급 된 DOM에 대해 조금 더 배우고 싶다면 https://css-tricks.com/dom/ 를 참조하세요. 매우 유용하고 간결한 설명이 있습니다.

Disabling Suites and Specs

To disable and enable suites and specs, simply place an x in front of the describe or the it (depending which level you want to disable the tests at, placing an x in front of the describe will disable all tests within that describe) so that it looks like this: xdescribe or xit.

suites와 specs을 disable 하게 하려면 단순히 설명 앞에 x를 표시하세요. (테스트를 사용 disable하게 할 레벨에 따라 설명 앞에 x를 붙이면 해당 설명 내의 모든 테스트가 사용 불가능하게됩니다). 다음과 같이 하시면 됩니다. : xdescribe 또는 xit.

Getting Started: Home Page

Open up https://angularjs.org/. Create a new folder where you want to keep your project. Open up your preferred text editor (I personally use Brackets), and open up the folder that you have just created. Create a new .js file called 'HomePageSpec.js' and create a config file called 'protractorConf.js'. Paste in this code in to the 'protractorConf.js' file:

https://angularjs.org/를 엽니다. 프로젝트를 keep 할 새 폴더를 만듭니다. 원하는 텍스트 편집기를 열고 방금 생성 한 폴더를 엽니다. 'HomePageSpec.js'라는 새 .js 파일을 만들고 'protractorConf.js'라는 config 파일을 만듭니다. 이 코드를 'protractorConf.js'파일에 붙여 넣습니다.

       
   exports.config = {
      seleniumAddress: 'http://localhost:4444/wd/hub',
      specs: ['HomePageObjectSpec.js'],
      onPrepare: function () {	
         browser.driver.manage().window().setSize(1680, 1050);
      },
   }
       

Task 1.1: Describe “angularjs.org should have three Center Stage buttons”

What will you learn from this task?

• How to set up a describe suite and it spec.
• How to create page objects.
• How to check that something is displayed on the screen or present in the DOM using isDisplayed

여기에서 무엇을 배울 것입니까?

     describe suite와 spec을 설정하는 방법.
     페이지 객체를 만드는 방법.
     isDisplayed를 사용하여 화면에 표시되거나 DOM에 표시되는지 확인하는 방법 

In this task you will test that elements are present and visible on the page using the three center stage buttons on the home page of AngularJs.org and the Jasmine matcher .isDisplayed (read more about Jasmine matchers here. isDisplayed checks to see if the element is actually present on the page: if the element is not in the DOM whilst using isDisplayed, it will throw an exception error. See how to use isDisplayed below.

이 task에서는 AngularJs.org와 Jasmine matcher .isDisplayed의 홈 페이지에있는 3 개의 중앙 스테이지 버튼을 이용해서 해당 엘리먼트들이 페이지에 존재하고 볼수 있는지에 대해 테스트 할 것입니다.  (여기에서 Jasmine matchers에 대해 자세히 알아보십시오.) .isDisplayed는 엘리먼트가 실제로 페이지에 존재하고 보이는지를 체크합니다. : isDisplayed를 사용하는 동안 요소가 DOM에 없으면 exception error가 발생합니다. 아래의 isDisplayed 사용 방법을 참조하십시오.

1. Open up angularjs.org
2. Right click on the “View on GitHub” button, and select ‘Inspect element’ to bring up the html in the developer console.
3. Find the code that relates to the “View on GitHub” button (if you hover over

      
               <a class="btn btn-large" href="https://github.com/angular/angular.js">
           

   you will be able to see the button highlight).
   
        1. angularjs.org를 엽니 다.
        2. "View on GitHub"버튼을 마우스 오른쪽 버튼으로 클릭하고 'Inspect element'를 선택하여 개발자 콘솔에서 html을 가져옵니다.
        3. "View on GitHub"버튼과 관련된 코드를 찾습니다 (마우스를 올려 놓으면 버튼 강조 표시를 볼 수 있습니다).
   
   
4. If you navigate up through the divs, you will be able to find the html code that contains all three elements. The class for this is center stage-buttons.
5. In your text editor, open up your “HomePageSpec.js” file, and create a variable called HomePage like this:
   
       4. div를 통해 위로 이동하면 세 요소를 모두 포함하는 html 코드를 찾을 수 있습니다. 이를 위한 클래스는 중앙 스테이지 버튼입니다.
       5. 텍스트 편집기에서 "HomePageSpec.js"파일을 열고 다음과 같이 HomePage라는 변수를 만듭니다.
   
   

          
      var HomePage = function() {
    
      };
          

   This HomePage variable contains page objects, which are the elements on the page. Different page objects will be used for different sections that are tested on.
   
       이 HomePage 변수는 페이지의 elements인 page objects를 포함합니다. 테스트를 거친 다른 섹션에 대해 서로 다른 페이지 객체가 사용됩니다.
   
   
6. Create page objects for the center stage buttons with the HomePage variable, like so:
   
       6. 다음과 같이 HomePage 변수를 사용하여 가운데 스테이지 버튼에 대한 페이지 객체를 만듭니다.
   
   

          
      var HomePage = function() { 
         this.centerStageButtons = element(by.css(".center.stage-buttons"));
   
         this.viewOnGitHubButton = this.centerStageButtons.all(by.css(".btn.btn-large")).get(0);
         this.downloadButton = this.centerStageButtons.element(by.css(".btn-primary"));
         this.designDocsButton = this.centerStageButtons.element(by.css(".btn-warning"));
      };
          

   
   You can see that there has been a page object created for centerStageButtons. It is good practice to write the elements as they match the code in DOM as quite often there will be multiple elements with the same name. Chaining the page objects (as above) creates more readable code as it (most of the time) eliminates the need for using .get(index). I say most of the time, since sometimes having to use .get(index) is inevitable: so if you enter in to the browser console $(".btn.btn-large") you will be able to see multiple results are returned, which is why we use .get(0) for the viewOnGitHubButton example above.
   
       centerStageButton에 대해 생성 된 페이지 객체가 있다는 것을 알 수 있습니다. DOM 에서 매치되면 같은 이름으로 elements들이 여러번 사용되기 쉽기 때문에 이 엘리먼트들을 사용하는 것은 좋은 방법입니다. 위와 같이 page objects를 묶는 것은 (대부분의 경우) .get (index)를 사용할 필요가 없으므로 더 읽기 쉬운 코드를 생성합니다. 대부분의 경우, 때로는 .get (색인)을 사용해야하는 것이 불가피합니다. 브라우저 콘솔 $ ( ".btn.btn-large")에 입력하면 여러 결과가 반환되는 것을 볼 수 있습니다. , 위의 viewOnGitHubButton 예제에서 .get (0)을 사용하는 이유입니다.
   
   
   
   
7. Underneath the HomePage variable, create the test suite and spec like this:
   
   7. HomePage 변수 아래에 다음과 같이 테스트 suite와 spec을 작성하십시오.
   
   

   
      describe('angularjs.org', function() {
   
         beforeEach(function() {
            browser.get('https://angularjs.org/');
         });
     
         it('should have a three buttons', function() {
     
         });
      });
          

8. In the describe, create a new HomePage object and in the it spec write the expected result of the test as below:
   
   8. describe에 새 HomePage 객체를 만들고 이 객체의 spec에 다음과 같이 예상되는 테스트 결과를 작성합니다.

   
      describe('angularjs.org', function() {
         var homePage = new HomePage();
   
         beforeEach(function() {
            browser.get('https://angularjs.org/');
         });
     
         it('should have a three buttons', function() {
            expect(homePage.viewOnGitHubButton.isDisplayed()).toBe(true);
         });
      });
          

9. Run the test by opening up the command line, navigating to the folder where the config file is located. Type in protractor protractorConf.js and press Enter for the code to start running (make sure you have started the selenium webdriver by typing in webdriver-manager start and pressing enter in the command line).
   
   9. command line을 열고 config 파일이있는 폴더로 이동하여 테스트를 실행하십시오. 코드를 실행하려면 protractor protractorConf.js를 입력하고 Enter 키를 누릅니다 (webdriver-manager start를 입력하고 명령 행에서 Enter 키를 눌러 selenium webdriver를 시작했는지 확인하십시오).
   
   
10. Did it pass? Yes? Great! No? Double check you have the code written correctly by looking at the code inside the Spec folder here: https://github.com/hannimator/angularjs.org_protractor .
    
    10. 통과 했습니까? 예? 좋습니다! 아니요? Spec 폴더의 코드 (https://github.com/hannimator/angularjs.org_protractor)를보고 코드가 올바르게 작성되었는지 다시 확인하십시오.
    
    
11. Now that this test has passed, it is always best to check that it fails if set to false, so underneath the first expect, create another one set to false like this:
    
    11. 이제 이 테스트가 통과되었으므로 false로 설정하면 실패하는지 확인하는 것이 가장 좋습니다. 따라서 첫 번째 기대치 아래에서 다음과 같이 false로 설정된 또 다른 하나를 만듭니다.

           
       expect(homePage.viewOnGitHubButton.isDisplayed()).toBe(false);
           

12. Run the test. Observe the expect set to false fails. This ensures that it isn’t a false positive, and is always a good practice to ensure that you haven't missed anything in your code.
    
    12. 테스트를 실행하십시오. expect가 false로 설정된 것을 확인하십시오. 이렇게하면 false positive가 아니라는 것을 알 수 있습니다. 그리고 코드에서 아무 것도 놓치지 않았는지 확인할 수 있는 좋은 방법입니다.
    
    

In the next tutorial we will use what we learnt in this tutorial and start to learn how to interact with elements on the webpage, as well as the difference between using the matchers isPresent and isDisplayed.

다음 튜토리얼에서는이 튜토리얼에서 배운 것을 사용하고 웹 페이지에서 요소와 상호 작용하는 방법을 배우기 시작할 것이고, isPresent와 isDisplayed라는 matcher를 사용하는 것의 차이점도 알게 될 것이다.

Create and Customize Fields

CA Agile Central (Rally) 에 Field 를 추가하거나 수정하려면 subscription 이나 workspace administrator permission을 가지고 있어야 한다.

field들은 Visible 혹은 hidden 으로 세팅할 수 있다.

Manage Field

Field Summary page에는 해당 work item 과 연관 된 모든 필드들에 대한 정보를 제공한다. workspace나 project perspective에서 이 Fields summary를 볼 수 있다.
이 페이지에 가면 특정 프로젝트, 프로젝트 그룹 혹은 전체 workspace의 필드들의 상태를 볼 수 있다.

이 Field Summary page는
- single work item type의 모든 필드들을 보여준다.
- name, type, custom 대 standard, required 그리고 visibility 등으로 정렬해 볼 수 있다.
- Custom field들을 생성할 수 있다.
- standard와 custom field들을 수정할 수 있다.

 이 Field summary page로 가려면 Workspaces & Projects summary page에서 workspace hyperlink 나 프로젝트 이름을 클릭한다. 그리고나서 페이지 왼쪽에 있는 sidebar에서 Fields 링크를 선택한다.

Workspace Field Page

Project Field page

View Fields

Field들은 defect, user story, task 등과 같은 work item type에 의해 나눠져 있다. 특정 work item type의 필드들을 보려면 Work Item 드롭다운 메뉴를 사용한다. 그러면 해당 work item 에 속해 있는 모든 필드들이 표시된다.

링크

Fields summary page는 아래 필드들을 보여줄 것이다.

Column	Meaning
Name	The name of the field, as it appears in summary pages, editors, and other locations. Fields have both a system name and display name.
Attribute Type	The type of field. For example, text, string, or boolean.
Custom	A check mark will display if the field is not a CA Agile Central standard field, and has been created by an administrator.
Required	If checked, the field must have a value entered to create or save changes to the work item. Required fields cannot be hidden from specific projects, and are seen by the entire workspace. Note that work items created before a requirement is saved may have other fields edited inline from grid summary pages and apps without entering a value for the required field.
Visible	Displays a check mark if the field is visible in the project that the Fields summary page is being accessed from.
Visible on Child Projects	Present if viewing the Fields summary page of a project that has open child projects. Displays a check mark if the field is visible in all child projects, and displays Mixed if some children can use the field but others cannot.
Shared Across Work Items	Some standard fields, such as Schedule State, are shared across multiple work item types. Changing the settings of a shared field will affect any work item types that use the field.

CA Agile Central 시스템 (Rally)에 의해 내부적으로 사용되는 필드들은 여기에 표시되지 않는다.

필드 변경 이력은 revision history. 특정 프로젝트의 필드의 visibility 변경 이력은 project의 revision history. global changes 는 workspace revision history 등을 보면 알 수 있다.

Delete Fields

필드를 삭제할 수는 없다. 대신에 Visible 드롭다운에서 No를 선택하면 해당 필드가 안 보이도록 하면 된다.

링크

동시에 같은 타입의 또 다른 커스텀 필드가 필요하면 필드를 수정한 후 이름을 바꾸면 새로운 것을 만들 수 있다.

Types of Fields

CA Agile Central 은 여러 용도의 다양한 필드 타입을 제공한다.

Type	Description
Boolean	A checkbox representing a True or False option.
Date	A calendar icon displays in work item editors. When a date is chosen, it displays in text format next to the calendar.
Decimal	A number with a maximum of six digits before and three digits after the decimal point.
Drop Down List	A list of options that contains a series of strings or textual information.
Drop Down (Multi-Value) Open Beta	A list that contains one or more pre-defined fields from which a user can choose multiple items. The valid selections for the list are customizable.
Integer	A number field with a maximum of nine digits.
String	A field that accepts alphanumeric and special characters. Limited to 256 characters.
Text	Provides a field with rich-text formatting options. Text fields may hold up to 32Kb of data.
Web Link	Use this field to embed a web link or reference to an object in an external system.

특정 HTML 태그를 표시하기 위해 String 필드를 사용할 수 있다. 더 자세한 용도는 HTML Whitelist Policy를 보라.

일단 필드가 생성되었다면 해당 필드의 type을 바꿀 수는 없다.

Supported Items

아래 work item들과 objects들에서 custom fields 를 지원한다.


    Defects
    Defect Suites
    Iterations
    Milestones
    Portfolio Items
    Projects
    Releases
    Tasks
    Test Cases
    Test Case Results
    User Stories
    Workspaces


Create Custom Fields

필요한 필드가 있으면 생성할 수 있다. 이 Custom Fields는 subscription이나 workspace administrator에 의해 추가될 수 있고 전체 workspace나 특정 project 혹은 project hierarchy의 section에서 보여지게 할 수도 있다. Custom fields는 editor pages, custom views, Web Services API queries 등에서 사용 가능하고 detail and summary page에서 볼 수 있다.

Note
- 새로운 portfolio item type을 추가할 때 여러분이 추가하는 type이 같은 workspace에 globally scoped 된다는 것을 유념하라. 그렇지 않으면 validation error가 표시 될 것이다.
- project나 workspace administrative page들에서 custom field를 생성하게 될 텐데. 그 custom field는 workspace level의 데이터베이스에 존재하게 될 것이다. 그리고 visibility는 workspace나 project level에서 control 된다.
- custom field를 생성한 곳에서 visibility도 constol 할 수 있다. 만약 새 필드를 몇개의 프로젝트에서만 적용시키려면 특정 프로젝트에서 생성하거나 사용하고자 하는 project hierarchy 의 top 에서 생성한다. 특정 프로젝트들에서만 custom field를 숨기고 싶다면 workspace level에서 생성해서 그 프로젝트들에서 hidden 으로 해당 필드를 세팅하면 된다.
- 같은 field 가 같은 workspace에 복수개 존재할 수 없다. 여러 project들은 한개의 field를 공유할 수 있다. 이 경우 같은 values 와 settings를 사용해야 한다. 다른 프로젝트와 독립적인 field를 생성하려면 반드시 다르게 이름을 지어야 한다.
- custom field의 required value는 workspace level에서 세팅한다. 만약 새로운 custom field를 생성한다면 그것은 required이다. 이것은 모든 open project들에 visible 할 것이고 required 하게 될 것이다.
- CA Agile Central standard field들은 visible/hidden 될 수 있다. 이것은 workspace 레벨에서만 적용된다.
- Custom fields는 defect suites 에는 적용되지 않는다.

새로운 Custom field를 생성하려면

1. Workspace나 Project의 Fields summary page로 간다. (링크)
2. Work Item dropdown을 클릭하고 필드를 생성하고 싶은 work item의 type을 선택한다.
3. New Field 버튼을 클릭한다.
4. name, Display Name, Type 필드에 값을 입력한다. Name과 Display Name에는 unique한 값을 넣어야 한다.
5. 이 필드를 Mandatory로 하려면 Required option을 체크한다.
6. 프로젝트나 workspace 의 필요성에 따라서 필드의 visibility를 세팅한다.
7. Save & Close를 클릭한다.

링크

Edit Fields

1. Workspace나 Project의 Fields summary page로 간다.
2. Work Item dromdown 을 클릭하고 type을 선택한다.
3. field 왼쪽의 gear icon을 클릭하고 Edit을 선택한다.
4. Field value를 업데이트 한다.
5. Save & Close 를 클릭해 수정을 마친다.

링크

Note
- 여러 work items 에 걸쳐 사용되는 Shared field 가 있다. 이 필드를 수정하게 되면 다른 work item들도 영향을 받게 된다. 또한 해당 필드에 notification 룰이나 custom views를 생성한 사용자들도 영향을 받게 된다.
- Type 같은 어떤 standard CA Agile Central fields들은 수정이 불가능 한 것도 있다.
- CA Agile Central system에 의해 사용되는 어떤 필드들은 required 이다. 만약 그렇다면 해당 필드는 수정 할 수 없다.

Editor window fields

Field	Description
Name	This name is used by the CA Agile Central application. For CA Agile Central fields, this name is already populated. This name is not displayed in the Fields summary page, but does display in Create and Edit screens for administering work item fields.
Display Name	This is a textual field allowing you to enter the name that will be displayed to users of the workspace.
Type	The type of field. Cannot be changed after a field is created.
Occurrences	A calculated number that indicates how often a field is being used by work items in the workspace.
Required	Require that the field be populated upon creation or edit. Note: Marking a field Required has implications for inline editing, multi-editing, and importing data. The Add button on some board and grid apps will force a full editor window to display, so the required field may be filled in when creating a new work item. Work items created before the requirement is enforced may have other fields edited inline from grid summary pages and apps without entering a required value. In addition, existing integrations may fail if a field is marked Required after the integration is in place.
Visible	When accessed from the workspace, displays a single drop-down that controls the fields visibility for all projects. If only some projects are set to view the field, it will be set as Mixed. Choosing the Yes or No options will show or hide the field in all open projects after saving. When accessed from a project with child projects, two drop-downs display. The top drop-down controls visibility for the project the editor was accessed from, while the lower drop-down controls visibility to all child projects.

Manage Project Visibility

전체 workspace에 visible 하게 custom field를 세팅할 수 있다. 그리고 특정 프로젝트나 특정 프로젝트 그룹에만 보이도록 할 수도 있다. 프로젝트에 대한 Fields visible을 설정하는 것은 아래에서 가능하다.


    Work item detail pages
    Editor windows
    Summary pages
    Apps
    Custom views
    Notification rules
    Web Services API

Note
- page나 app 안에서 project scoping을 변경하면 visibility setting 에 따라 custom field들의 availability 가 영향을 받는다.
- When viewing the Backlog page scoped to a hierarchy of projects, fields that are visible in some child projects but not others will display.
- Queries from the Web Services API will respect project visibility. Unless specified, queries will use the default project and scoping set in your profile.
- When using a connector with a supported version of the WSAPI, any fields fetched for will be returned, regardless of visibility settings.

해당 필드를 사용할 프로젝트를 설정하려면 field editor 의 Visible 섹션을 사용한다.

특정 프로젝트에 visible 한가 여부를 보려면 Field summary page로 가면 도움이 될 것이다.

- From the workspace, fields available to all projects will display a check mark in the Visible column. Fields available to some projects but not others will display Mixed in the column.
- From a specific project, the Visible column will display a check mark if the field can be used in that project.
- If viewing a project that has children, the Visible on Child Projects column will display. A check mark will be present if the field can be used in all open child projects. Mixed will display if the field can only be used in some of the child projects.

어떻게 필드를 생성하고 visibility 를 조정할 것인가에 댛 아래 추천 방법을 참고하세요.

Set a field to be used by the entire workspace

    Access the Fields summary page from the workspace level.
    Create or edit the field.
    In the field editor window, set the Visible drop-down to Yes.
    All open projects will have access to the field.

Set a field to be used by a single project

    Access the Fields summary page from the project you want to use the field in.
    Create or edit the field.
    In the field editor window, set the Visible In This Project drop-down to Yes.
    Repeat for each unrelated project you want to use the field in.

Set a field to be used by a group of projects in a hierarchy

    Access the Fields summary page from the top-most level of the project hierarchy that you want to use the field in.
    Create or edit the field.
    In the field editor window, set both Visible drop-down menus to Yes.
    The project you accessed the Fields summary page from, and all open child projects will have access to the field.

Drop Down List (Multi-Value) Open Beta

Subscription and workspace administrators 는 이제 multi-value custom fields를 생성할 수 있게 됐다.
Custom fields allows CA Agile Central users to tailor our product to meet their unique needs. Multi-value custom fields extends the value of single-value custom fields and are available across all of the artifact types that support custom fields. These fields are configured in the Field editor pop-up window after you select Drop Down List (Multi Value) as the type of field.

일단 admin에 의해 설정 되면 그 multi-value drop-down 리스트는 이 custom field가 적용되는 모든 곳에 동일하게 고쳐진다.

- New editable detail pages

- Legacy detail pages

- New-stype grids

- Legacy grids

- Boards

- The new advanced search component on the Iteration Status page

Use Web Link Fields

Web Link field type은 external system의 object를 embed reference로 사용할 수 있도록 해 준다. 예를 들어 별도의 web-based case management tool이나 defect tracker를 사용한다면 web link field를 생성해서 CA Agile Central의 해당 story나 defect에 link할 수 있다. 이렇게 되면 external item을 CA Agile Central에서 사용할 수 있게 된다.

새로운 web link field를 생성하려면

1. New Field button을 클릭한다.
2. Name과 Display Name field에 값을 입력한다. 이 값들은 unique 해야 한다.
3. Type drop-down에서 Web Link를 선택한다.
4. 아래 필드들을 complete 한다.
- URL : 외부 시스템의 URL을 넣는다. ${id}는 insert 되어야할 external system의 Object ID를 가리키는데 사용된다. 예를 들어 Salesforce.com을 링크해야 하면 URL: https://na3.salesforce.com/$\{id} 이렇게 한다. CA Agile Central generates a link to your object by combining the URL with the ID you provide in the detail page to produce the full URL to the Salesforce.com case: _https://na3.salesforce.com/a0A30000000xK8D_ .
Display Preference: Click the appropriate radio button to indicate how the external Web Link field will be displayed in CA Agile Central:

    * Display in new window. This option will open a new pop-up window to display the external Web Link object.
    * Display in existing window. This option displays the external Web Link object directly in the CA Agile Central window.
5. Save를 클릭한다.

이 단계까지 완료 되면 Web Link 필드는 work item을 수정하거나 work item detail page를 볼 때 사용할 수 있게 된다.
1. Link Label 같은 것을 사용하기 위해 external object의 Name 을 제공한다.
2. ID field에 링크하기 위해 external object의 ID를 입력하고 entry를 save 한다.

work item의 detail을 보려면 external object의 hyperlinked Name을 클릭한다. 그러면 해당 external page로 가게 된다.

Link Label과 ID 필드를 populate 하기 위한 방법으로 CA Agile Central Web Services API interface 의 사용을 고려해 볼 수 있다. 예를 들어 여러분의 case management tool은 Web Service를 사용해서 defect를 insert 할 수도 있기 때문에 이런 경우 해당 웹 서비스 API를 사용할 수 있다.

그동안 우리 팀에서 Agile 프로젝트 관리를 위해 Rally를 써 왔고 매뉴얼 테스트 케이스와 Defect 관리를 위해서는 HP ALM 을 써 왔습니다.

그런데 조금 변화가 생겨서 ALM을 사용하지 않게 되었어요.

그래서 Rally에 있는 Test에 관련된 Module 에 대해 Research 해 봤습니다.

그동안 Rally가 다른 회사로 넘어가서 공식적으로는 CA Technology 라고 이름이 바뀌었나 봅니다.

CA Agile Central Quality Manager Overview

Agile development는 테스터의 작업 방식을 획기적으로 변화시켰다. Agile 팀 내에서 아주 긴밀한 협력을 기반으로 테스트를 진행하게 된 것이다. 요구조건과 어플리케이션의 코드가 끊임없이 변화하기 때문에 테스터는 이에 맞게 팀 내에서 그 역할을 해야 한다. CA Agile Central은 소프트웨어 테스트 엔지니어에게 테스트 결과를 개발 lifecycle이 단계에 맞게 제공할 수 있는 tracking tool을 선사한다. 또한 다양한 automated software 테스팅 툴들과 같이 사용할 수 있도록 하는 기능도 제공한다.

CA Agile Central의 기본적인 테스트 기능들은 아래와 같다.

* User Story와 Defect 에 곧바로 테스트 케이스를 생성할 수 있도록 한다.
* 코딩 진행 단계에 맞춰 동시에 테스트가 진행 될 수 있도록 한다.
* View status dashboards that automatically group test case results by user stories to assess quality and readiness
* failing test case에 대한 좀 더 개선된 communication과 쉬운 defect re-creation 기능을 제공하고 이를 관리하는데 들어가는 burden들을 줄여준다.

그 외에 CA Agile Central Quality Manager 모듈의 추가적인 기능들은 Test Sets, Test Plan, Test Case Summary Page 등이 있다. 이 기능들은 아래와 같은 편의성을 제공한다.

* 시스템의 life 기간동안 여러번 반복되서 실행될 Regression test에 대한 관리
* 특정 criteria에 대한 custom test plan list를 생성
* Test Case summary page에서 iteration과 release 이외의 조건으로 쉽게 filtering 할 수 있음   

Quality management concepts

Basic Concepts :
Test Case : 테스트 케이스는 work item (US/Defect)를 기반으로 생성해서 그 work item 의 기능에 대해 검증할 수 있도록 한다. 테스트 케이스는 테스트 결과들을 만들어 낸다.
Test Folder : 테스트 폴더는 테스트 케이스를 organizing 하는 기본적인 메카니즘이다. 기본적으로 비슷한 기능들끼리 구성한다. 하나의 테스트 케이스는 하나의 테스트 폴더에 속할 수 있다.
Test Set : 테스트 세트는 테스트 케이스들의 모음이다. (테스트 폴더에 보관할 수도 있다.) 테스트 세트는 iteration이나 release 진행시 regression test 를 그룹화하고 일정을 정하는데 사용할 수 있다. 테스트 세트는 Iteration 과 Release Status 에서만 생성하고 사용될 수 있다. 테스트 세트를 복사해서 다른 iteration이나 release에 옮길 수 있다.

Life of a Test Case

1. 유저스토리나 defect 에 연계된 새로운 테스트 케이스를 생성한다. 테스트 케이스는 stand alone이 될 수도 있지만 권장하는 것은 아니다.
2. 테스터는 테스트를 진행하고 acceptable한지 여부를 결정한다. 이 테스트 케이스가 regression testing 에도 사용되어야 하면 다음 단계를 진행한다.
3. Optional : 테스트 케이스를 테스트 폴더에 넣는다. 테스트 폴더에는 관련된 테스트 케이스들이 있게 된다. 테스트 폴더는 테스트 케이스들을 organize 하도록 해 준다.
4. 이제 테스트 케이스는 많은 Regression test들 중의 하나이다. 이것은 test set 로 같이 schedule 되서 진행할 수 있다. 테스트 세트는 iteration 이나 release 와 연계돼 있다.

Related CA Agile Central Pages

Test Plan Page

이 페이지는 폴더 안에서 테스트 케이스들을 organize 하고 관리할 수 있도록 해 준다. 테스트 계획을 세울 때 폴더 안에 hierarchy 구조로 테스트 케이스들을 구성하고 싶다면 이 Test Plan 을 이용하면 된다. 테스트 폴더 안에서 테스트 케이스들을 Rank 하고 그룹 내의 테스트들을 run 하고 test resuts 와 Defect 들을 등록할 수 있다. 그리고 summarized result도 확인 할 수 있다.

Test Plan 페이지에 새로운 테스트 폴더가 생성되면 테스트 폴더는 현재의 scope (project)에 등록된다. 위 예제를 보면 이 테스트 폴더들은 Shopping Team 에 속하게 된다. 만약 테스트 폴더들을 다른 팀의 테스터들과 같이 공유하고 싶다면 좀 더 higher node 에 테스트 폴더를 associate 하면 된다.

Iteration Status Page

테스트 세트는 테스트 케이스들이 들어가는 공간이다. 이 테스트 세트는 특정 iteration 이나 release 에 처리할 테스트 케이스들을 포함하게 된다. Track -> Iteration Status 페이지에서 Add New 버튼을 누르고 드롭다운 메뉴에서 Test Set를 선택한다.

아래 내용을 참조할 것

* CA Agile Central Quality Manager 모듈은 테스트 세트, 테스트 플랜 페이지 그리고 Test Case summary page 가 구성돼 있어야 한다.
* passing, failing 혹은 pending 상태인 테스트 케이스들의 숫자등을 볼 수 있을 것이다. 그리고 test coverage의 상태를 표시하는 report와 dashboard들도 표시된다.
* CA Agile Central App SDK Toolkit을 사용해서 custom App 이나 custom report를 생성할 수 있다. 이것은 3rd-party testing system에서 CA Agile Central 에 integrate 되서 작동한다.

이 외에 관련된 글은 아래와 같다.

Test Plan
https://help.rallydev.com/managing-test-plans

Test Cases
https://help.rallydev.com/manage-test-cases

Test Set
https://help.rallydev.com/content/test-set

Test Case Results
https://help.rallydev.com/test-case-results

Test Runs
https://help.rallydev.com/test-runs

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 들을 중요한 분야별로 나누어 우선순위를 정하라
        이것이 얼마나 많은 버그를 찾을 것인가?
        발견된 버그가 얼마나 중대한(큰) 것인지(자잘한 버그를 수천개 찾는 것보다 크고(중요하고) 시급한 버그를 찾는 것이 더 의미 있다)

원문

Technical overview

 Selenium / Webdriver는 웹 브라우저에를 위한 아주 좋은 자동화 툴이다. 여기엔 사용자가 브라우저와 상호작용할 수 있도록 해주는 아주 깔끔한 API 가 있다. 이 API를 ios automation 에서도 사용할 수 있다. 여러분이 어떤 테스트를 하든지 GUI 와 상호작용하는 기능을 테스트 하려면 기본적으로 아래와 같은 일을 해야 한다.

    - element 찾기
    - 그 element 와 상호 작용하기

Using that API for ios automation has two main advantages:
ios automation을 위해 이 API를 사용하면 이런 장점들이 있다.

    - 이미 증명된 안정적인 API 이고 앞으로 W3C 표준으로 될 것이다.
    - local client 로부터 분리해서 원격으로 적용할 수 있다.

셀레니엄은 이미 Java, C#, Python, Ruby client 를 사용하고 있다. 여러분이 편한 언어를 사용하면 된다. 이 API를 배우기 위해 시간을 보내는 대신 business logic 에 더 신경을 쓸 수 있다.

System requirements for OSX

ios-driver 는 Apple 의 두가지 다른 framework에 설치 될 수 있다.

Native 앱에 대해서는 애플의 UIAutomation 프레임워크를 사용한다. (more here). iOS SDK 5.0 이상과 xcode가 필요하다.

이것을 확인하려면 아래와 같이 하면 된다.

    $ xcodebuild -showsdks

이 명령어를 실행하면 아래와 같은 내용을 볼 수 있을 것이다.




   
서버는 자바로 돼 있다. 그래서 Java 7 이 필요하다.
설치된 자바 버전을 확인하려면 아래와 같이 한다.


    $ java -version


이렇게 하면 현재 설치돼 있는 자바 버전이 나올 것이다. 

Getting a test application

테스트를 위해 애플에서 제공하는 샘플 앱을 사용할 것이다. : InternationalMountains.
다른 앱이 있으면 그것을 사용해도 된다.
InternationalMountains 을 사용하려면 여기서 다운 받고 압축을 풀으면 된다.

UICatalog를 사용해도 된다. iOS에서 UI element 가 가능한 샘플 앱니다.


Launching ios-driver

 ios-server-0.6.6-SNAPSHOT.jar 를 다운 받는다.

 ios-server  최신 버전을 다운 받는다.

다운 받은 폴더로 가서 아래 명령어를 실행한다.

$ java -jar ios-server-0.6.6-SNAPSHOT-standalone.jar -aut
    path/to/aut.app -port 4444

그러면 터미널에 아래와 같은 내용의 로그 기록을 볼 것이다.





이 앱이 제대로 인식 되었는지 보려면 브라우저로 가서 아래 URL로 이동해 본다.

 http://localhost:4444/wd/hub/status

그러면 이 앱에 대한 정보를 json 객체 형태로 볼 수 있을 것이다.


 

Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps - part 2 -

Process to develop a good test strategy document:


여러분의 프로젝트에 어떤 것이 가장 잘 맞을지에 대해 고민해 보지 않고 무조건 template을 따르는 것은 자제하자. 고객들은 그들만의 요구 조건들이 있고 여러분은 그런 고객들의 특성을 잘 파악해서 이 문서가 여러분의 일에 제대로 적용될 수 있도록 만들어야 한다. 그냥 무조건 다른 문서를 복사해서 붙여넣기 하지 말자. 여러분이 만든 문서가 여러분의 프로젝트에 진정 도움이 되어야 하고 여러 프로세스를 만드는데 좋은 기초가 되어야 한다.

아래는 strategy template 샘플이다. 여기에는 어떤 내용들이 이 문서에서 커버되어야 하는지를 보여준다. 그리고 각 컴포넌트들을 커버하기 위해 어떻게 해야 하는지 감을 잡을 수 있도록 예제를 제공할 것이다.


Test Strategy in STLC:

Common sections of test strategy document:

Step #1 – Scope and Overview:


이 문서를 누가 사용할 것인지에 대한 정보와 함께 프로젝트 개요가 들어간다. 좀 더 자세하게 누가 이 문서를 검토하고 승인할 지에 대해서도 언급한다. testing activity들과 testing phases 등을 정의해서 test plan에 정의된 전체 프로젝트 타임라인에 맞춘 각 activity들과 phase 들의 타임라인을 정의한다.

Step #2 – Test Approach:


testing process와 level 을 정의하고 각 팀 멤버들의 역할 및 책임을 기술한다. 모든 test type에 대해서는 test plan에서 정의 돼 있다. (예: unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) 이러한 test type들은 언제 테스트를 시작하고 test owner가 누구이고 누가 책임을 지고 있고 testing approach는 어떻고 automation stragegy에 대한 자세한 내용 그리고 가능하면 tool들까지 자세한 내용들이 Tesst Stragegy 문서에 담기게 된다. 그리고 왜 이런 테스트 들을 해야 되는지도 언급하게 된다.

test execution에는 여러 activity들이 있는데, 예를 들어 defect 등록, defect 분류, defect assignments, re-testing, regression testing 그리고 최종 test sign-off 같은 것들이다. 각 activity 들에 대해 정확한 step들을 정의해 두어야 한다. 여러분이 이전에 사용했던 프로세스를 다시 사용해도 된다. 테스터 인원수와 누가 어떤 activity를 진행해야 하는지 등등 각 팀 멤버들의 role과 responsibility를 명시해 놓아야 한다.

예) defect management cycle - 새로운 defect를 등록하는 프로세스 명시. 어디에 등록하고 어떻게 등록하고 defect status는 어떠해야 하고 누가 defect triage (defect 등급 분류)를 해야 하고 이 등급 분류 후에 누구에게 이 defect를 할당해야 하는 지 등등에 대해 명시되어야 한다.

또한 management process 변화도 정의한다. 여기에는 change request submission과 사용될 template 그리고 해당 request를 다룰 프로세스들이 정의된다.

Step #3 – Test Environment:


테스트 환경 셋업에 대해 정의한다. environment 갯수와 각 environment 를 셋업하는 방법등을 설명한다.

예) functional test team을 위한 test environment 한개 그리고 UAT 팀을 위한 다른 한개.
각 environmet 에 허용되는 user 수와 각 유저에 요구되는 access role들 그리고 운영체제나 메모리, free disk space, 시스템 수 등등의 필요한 하드웨어에 대해서 설명한다.

test data requirement에 대해 정의하는 것도 아주 중요하다. 어떻게 test data를 생성하는지에 대해 분명한 방법을 제시한다. (either generate data or use production data by masking fields for privacy)

test data 백업과 restore strategy 에 대해 정의한다. 아마도 프로그래밍 code에서 제대로 처리하지 않는 문제 때문에 Test environment database 운영에 어떤 문제가 발생할 수도 있을 것이다. 어떤 프로젝트에서 내가 경험했던 문제는 database backup strategy 가 정의 되지 않아서 일어났다. 언제 백업을 하고 그 백업에는 어떠한 것들이 있어야 하고 언제 이 데이터베이스를 restore 하고 누가 restore 하고 데이타베이스가 restore 된 후 따라야 할 data masking step 등등이 명시되어 있어야 한다.

Step #4 – Testing Tools:


test execution에 필요한 test management와 automation tool들에 대해 정의한다. 퍼포먼스를 위해 load와 security 테스팅에서 test approach와 필요한 tool들을 명시한다. 그것이 오픈소스인지 유료 툴인지도 언급하고 얼마나 많은 user 가 사용할 수 있는지를 알아보고 이에 맞게 계획을 세운다.

Step #5 – Release Control:


이전 UAT article에서 언급했듯이, release cycle에 대한 계획이 없으면 test와 UAT 환경에서 서로 다른 software version에 대한 result를 얻게 된다. release management 계획은 확실한 version history 를 확보할 수 있는 상태에서 수립하게 된다. 그렇게 되면 해당 release 의 모든 modification들에 대한 test execution을 보장할 수 있게 된다.

예) build management 프로세스를 수립하면 - 현재 release가 가능한 build를 파악할 수 있고 그 build들이 어디에 deploy 되는지를 명확하게 공유할 수 있다. 즉 production build 들을 어디에서 구하고 누가 해당 production release 에 대해 go or no-go를 할 것인지도 명시하게 된다.


Step #6 – Risk Analysis:


가능한 모든 risk들을 정리한다. 이런 리스크들을 완화하기 위한 clear 한 계획을 제공한다. 그리고 실제 이러한 risk가 발생했을 때를 대비한 contingency plan을 명시한다.


Step #7 – Review and Approvals:

이러한 모든 activity들이 test strategy plan에 정의 되면 이 문서는 sign-off를 위해 검토 되어야 한다. 검토할 당사자들은 project management, business team, development team 그리고 system administration (혹은 environment management) team 등이 해당 될 것이다. review change 에 대한 이력은 approver 의 이름과 날짜 그리고 comment들을 문서 시작 부분에 명시할 수 있도록 작성돼 있어야 한다.
그리고 이 문서는 현재 진행형의 문서이다. 즉 이 문서는 testing process enhancement를 위해 지속적으로 review 되고 update 되어야 한다.

마무리:


Test Strategy는 그냥 종이조각이 아니다. 이 문서는 소프트웨어 테스팅 life cycle의 전체 QA activity에 대해 설명한 문서이다. 이 문서를 test execution process 마다 수시로 참고하고 software release 까지 해당 내용들을 따라야 한다. 프로젝트가 release date에 가까와 오면 올 수록 이 test strategy 문서에 정의된 내용들을 간과함으로서 초래되는 부정적인 결과들이 점점 더 많이 발생하게 될 것이다.

agile 팀에서 일을 간소화 하려고 하는 부분은 strategy 문서 작성이 아니라 test execution 부분이어야 한다. 이러한 기본적인 strategy plan을 가지고 있으면 프로젝트에 내재해 있는 리스크 피해를 줄이거나 이에 대해 분명한 계획을 세울 수 있다. Agile 팀은 모든 high level activity들을 파악하고 이를 문서화 해서 어떠한 문제도 없이 test execution이 제 때에 완료 될 수 있도록 해야 한다.

좋은 test strategy plan을 만들고 이를 제대로 따르면 분명히 testing process 가 충분히 개선되고 소프트웨어의 품질이 향상될 것이라고 확신한다. 이 글이 당신이 당신의 프로젝트에 대한 test strategy plan을 작성할 필요를 느끼게 해 주었다면 그 자체로서 나는 보람을 느낄 수 있을 것이다.

Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps - part 1-

What is Test Strategy?

Testing을 통해 무엇을 얻고 그것을 어떻게 달성할 것인지에 대한 접근법을 정의하는 것이 strategy plan이다.

이 문서는 테스트의 목적을 달성하기 위한 분명한 접근법을 취하기 위해 모든 불확실하고 애매한 부분을 다 제거한다. Test Strategy는 QA 팀에가 가장 중요한 문서 중 하나이다. 이 문서를 효율적으로 작성하는 것은 모든 테스터들이 그들의 경력 속에서 취득해야할 기술이다.

이 문서는 간과할 수 있는 요구조건들이 정리됨으로로서 작업의 완결성을 높여줄 것이다. 그리고 각 테스트 계획의 activity들은 팀에게 테스트 범위나 테스트 영역을 정의하는데 도움을 줄 것이다. 또한 테스트 매니저에게는 어느때 이든지 현재 프로젝트의 상태를 파악할 수 있도록 도움을 줄 수 있다. 그리고 제대로 된 strategy 가 마련돼 있으면 test activity들을 missing 할 수 있는 위험성을 줄여준다.

아무 계획없이 테스트를 하는 것은 거의 성공확률이 없다. 그리고 strategy document를 작성은 했지만 이후 테스트 할 때 한번도 참조하지 않는 경우도 있다. Testing strategy plan은 반드시 모든 팀 멤버들과 같이 공유되고 논의 되어야 한다. 그렇게 함으로서 팀이 지속적으로 관련 업무에 이를 활용하고 거기에 대한 책임도 인지하고 있어야 한다. 시간이 촉박하다고 해서 그 strategy document에 있는 testing activity들을 보류하거나 건너 뛰어서는 안된다. 여기에 언급된 프로세스는 반드시 실행되어야 한다.

Test Strategy vs. Test Plan:


몇년 간 두 문서 사이에 많은 혼동이 있었다. 아주 기본적인 정의부터 하자. 일반적으로 어느 문서부터 오는지는 중요하지 않다. Test Planning 문서는 전체 프로젝트 계획과 strategy가 같이 있는 문서이다. IEEE Standard 829-2008에 따르면 strategy plan은 test plan의 하위 문서이다.


모든 조직은 그들만의 표준과 프로세스를 가지고 이러한 문서들을 관리한다. 어떤 조직들은 test plan 에 strategy details를 포함하기도 한다. (여기에 그 예가 있다) 어떤 조직들은 strategy를 testing plan의 subsection으로 두고 자세한 내용들을 별도의 strategy 문서로 만들기도 한다.

test plan에는 프로젝트의 범위와 test focus가 정의 돼 있다. 기본적으로 test coverage, 테스트해야 할 features 그리고 테스트 하지 말아야할 features, estimation, schedule 그리고 resource management 등이 있다.

test strategy에는 test objectives를 달성하기 위해 따라야 할 test approach에 대한 guideline들과 testing plan에 정의 된 test type들의 실행 등이 들어 있다. 여기에는 test objective, approach, test environment, automation strategy 그리고 tool 들과 contingency plan 등과 같은 risk analysis 등이 있다.

요약하면 test plan은 여러분이 달성하고자 하는 비젼이고 test strategy는 그 비젼을 달성하기 위해 마련된 action plan 이다.

이렇게 정의함으로서 혼동스러운 개념이 깨끗하게 정리되길 바란다. James Bach는 여기에서 이와 관련해 좀 더 자세하게 논했다.

지금 참여하는 프로젝트는 Agile 방법론을 사용합니다.

그래서 각 스크럼 팀 별로 일을 진행하고 각각의 일들은 Sprint로 나눠서 진행합니다.

각 Sprint 가 끝날 때 Sprint Restrospective 라는 시간을 갖게 되는데요.

이 시간에 하는 일을 설명한 글이 있어서 살펴 봤습니다.

Sprint Retrospective

스크럼 팀이 암만 훌륭해도 개선해야 할 사항은 항상 있게 마련입니다. 훌륭한 스크럼 팀은 지속적으로 개선할 사항을 찾을 기회를 갖습니다. 팀은 이를 위해 따로 간단한 시간을 갖는데요. 스프린트 끝나는 시점에 어떠한 일들을 했고 어떻게 개선할 점을 찾았는지에 대해 정리할 시간을 갖습니다. 이러한 일들은 sprint retrospective에 진행합니다.

sprint retrospective는 대개 스프린트의 가장 마지막에 하게 됩니다. 많은 팀들은 주로 스프린트 review를 하고 난후 이러한 시간을 갖습니다. 그리고 전체 팀에 대한 것은 스크럼마스터와 Product Owner 가 참여한 가운데 진행되게 됩니다. 이 scrum retrospective 는 대개 1시간 가량 진행하면 충분합니다. 때때로 주요한 사항이 발생하거나 팀간의 conflict가 발생하면 이 retrospective 는 충분히 논의 할 수 있도록 시간을 연장할 수 있습니다.

agile sprint retrospective를 진행하는 방법은 여러가지가 있지만 저희가 추천하는 것은 start-stop-continue meeting 같이 진행하라는 겁니다.
이것이 가장 간단하게 일을 진행하는 방법일 겁니다. 그리고 가장 효율적인 방법일 수도 있습니다. 이 접근법을 사용해서 각각의 팀 멤버들은 팀이 start-stop-continue 해야할 구체적인 사항들을 얘기할 수 있습니다.

- Start doing
- Stop doing
- Continue doing

(start-stop-continue : goal을 위해 새롭게 실행할 것, 그만 두어야 할 것, 계속 진행해야 할 것)

이 간단한 format에는 많은 variations들이 있습니다. 스크럼 마스터는 스크럼 진행 동안 들었던 구성원들의 의견들을 sprint retrospective meeting에서 물어 볼 수 있습니다. 구성원들에게 각각 start, stop, continue 할 사항들을 하나씩 물어볼 수도 있지요. 예를 들어 구성원이 최근의 retrospectives 동안 별로 주목을 받지 못했던 어떤 일들을 이번에는 하지 말자고 의견을 낼 수도 있습니다.

이 brainstormed idear의 리스트를 작성한 후에 팀은 특정 아이템들에 대해 투표를 해서 다음 스프린트에서 주목해야 할 특정 사항을 선택할 수 있습니다. 다음 스프린트의 말에는 이 리스트를 리뷰하고 이전 sprint retrospective 에서 주목하자고 선택했던 부분을 다시 review 해 볼 수도 있습니다.

Project Proposal을 하려면 우선 고객들의 요구 조건에 맞는 결과물을 만들기 위해 어떤 일들을 해야 하는지 쭉 리스트 업을 해야 합니다.

이 리스트 업 된 것을 WBS (Work Breakdown Structure) 라고 합니다.

이 WBS가 완성이 되면 이제 사람은 어떤 사람들이 얼마나 필요하고 비용은 얼마가 들 것이며 그 기간은 언제까지가 될지 계산을 할 수가 있습니다.

거기에다가 프로젝트 진행 중에 발생할 수 있는 리스크들을 정리하고 그에 대한 대비책을 정리하면 훌륭한 프로젝트 제안서를 만들 수 있습니다.

Estimation을 공부하려고 구글링을 하다 보니까 어떤 업체에서 올린 아래 글이 눈에 띄어서 정리해 봤습니다.

Project estimating

한정된 예산과 주어진 시간 내에 양질의 제품을 고객에게 전달하는 것은 프로젝트 가시성을 높여주고 effort의 관리토록 하고, 고객의 기대에 부응 혹은 기대를 넘어설 수 있도록 하는 estimating 접근법을 사용함으로서 가능하게 만들 수 있습니다.


내부적으로든 아니면 주문을 받았든 새로운 제품을 개발하는데 있어서 가장 어려운 부분 중 하나는 effort에 대한 시간과 비용을 정확하게 추정 산출하는 것입니다. estimation은 중요한 프로그램을 지원하고 회사차원의 결정을 만들어내고 장래의 비효율성을 피하기 위해 현실성 있고 정확해야 합니다. Syncroness는 양질의 제품을 정해진 시간과 예산에 맞춰 제공하는 경쟁력있는 성과를 보인 것이 시장에 널리 알려져 있습니다.

Estimating accurately (정확한 추정 산출)

저희들만의 estimating approch를 사용해서 프로젝트의 가시성과 effort를 적절하게 관리 감독 하고 고객의 요구에 부응하거나 그 이상의 서비스를 제공하고 있습니다. 저희들만의 approch는 명확하지 않은 요구조건이나 명확하지 않은 프로젝트 리스크 혹은 예전 방식의 막연한 전망만 가지고 있어도 정확한 프로젝트 estimate를 산출하는 것으로 정평이 나 있습니다.


Focusing responsibility

기회가 주어지면 Syncroness 는 프로젝트 리드나 프로젝트 매니저에게 해당 일을 할당 합니다. 담당자는 estimating effort 뿐만아니라 프로젝트 자체를 성공적으로 마무리하는 책임을 지게 됩니다. 고객들과 함께 일을 하면서 discovery meeting 과 기타 meeting 을 주최해 해당 제품에 대한 요구 사항들을 모두 정리하게 됩니다. 이것을 통해 어떤 특정 기술이 사용되어야 하는지 색상에 대한 마케팅 차원의 필요한 점은 무엇인지 등등을 아주 자세하게 정리합니다. 이 요구사항 리스트는 estimation과 corresponding assumption의 basis가 되며 그것을 기반으로 프로젝트를 운영하게 됩니다.

Breaking down the work

그 다음 저희는 SOW (Statement of Work)을 만듭니다. 이 statement를 통해 우리가 하려고 하는 것들이 정확하게 무엇인지에 대한 대략적인 개요를 제공합니다. 이것은 내부 팀원들에게 Tool로 사용되게 되며 Syncroness와 고객사이에 관련 내용을 명확하게 합니다. 문서에 들어가는 내용은 estimating process 동안 사용될 기본 assumption들 입니다. 그런 과정을 거쳐서 저희들은 WBS (Work Breakdown Structure)를 만듭니다. 혹은 task들의 리스트와 해당 프로젝트를 완료하기 위해 필요한 팀 내의 역할 들을 작성합니다.



Identifying tasks (task 정의하기)

이제 SOW와 assumption들이 있는 WBS를 가지게 됐으니 group estimating 세션을 주최할 수 있습니다. 이 세션들은 통상적으로 프로젝트에 참여할 멤버나 그렇지 않을 멤버 모두가 참가 대상이 됩니다. 이 그룹은 WBS의 task 별로 살펴보고 각각의 task에 대한 estimation들을 제공합니다. 프로젝트 타입에 따라 resource들은 Estimation과 함께 프로젝트를 리드해 나갈 수 있도록 시간별 estimate나 관련된 score estimate (Fibonacci)를 사용할 수 있습니다.

Assessing risk (리스크 평가)

전체 estimation에 대한 윤곽이 잡히면 이 estimation 작업을 완료하기 전에 반드시 리스크를 생각해야 합니다. 이 리스크를 identifying, evaluation, normalizing 혹은 계량화 하기 위한 여러 technique들을 저희는 가지고 있습니다. (Monte Carlo analysis, Fibonacci Analysis and contingency-based risk assessments). 이 분석은 프로젝트에 있는 'unknown unknows'에 대해 account하며 적확하고 실제적인 estimate를 제공함으로서 리스크에 대한 고객들의 의문들을 불러 일으기키는 것을 방지합니다. 이 estimation이 완료되면 effort에 대한 work과 scope을 쌍으로 기술하고 고객의 review와 approval을 위해 공식 proposal 문서로 제공됩니다.