지금 참여하는 프로젝트는 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 해야할 구체적인 사항들을 얘기할 수 있습니다.

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

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

IBM Worklight Foundation

Develop, test, secure and manage mobile apps

IBM® Worklight® Foundation 은 여러분의 비지니스를 mobile device들로 확장하는데 도움을 드립니다. 이 제품은 개방적이고 여러 platform에서 빌드 하고 테스트하고 실행할 수 있고 native, hybrid, mobile web app 등을 관리할 수 있도록 해 줍니다. IBM Worklight Foundation 은 앱 개발과 유지 보수 비용을 절감하고 time-to-market 을 개선하고 모바일 앱에 대한 운영과 보안 부분을 개선하는데 도움을 드립니다.

IBM Worklight Foundation 은 아래 다섯가지로 구성돼 있습니다.

IBM Worklight Studio는 코드 재사용을 극대화하고 신속한 개발을 도와주는 native와 hybrid 개발에 대한 leading tool들을 제공합니다.

IBM Worklight Server는 mobile-optimized middleware로 어플리케이션과 back-end system 그리고 cloud-based service들 사이의 gateway 역할을 합니다.

IBM Worklight Device Runtime Components는 runtime client API (application program interfaces)로 보안과 운용 그리고 유용성(사용성) 개선을 위해 디자인 되었습니다.

IBM Worklight Application Center는 완성된 (production-ready) 모바일 앱을 배포하는 것을 관리하는 enterprise app store 를 셋업할 수 었도록 도와 줍니다.

IBM Worklight Console 은 administrative GUI 로 서버, adapters, 어플리케이션 그리고 push servies에 대한 실시간 운영 통게 분석을 제공함 으로서 모바일 앱의 관리와 모니터 그리고 instrument에 도움을 주기 위해 디자인 되었습니다.

IBM Worklight로 다음과 같은 일을 할 수 있습니다. :

   - 하나로 통일되고 공유되는 code base로 다양한 모바일 운영환경과 다양한 device들을 지원합니다.
   - Worklight 개발자들을 위해 command line interpreter로 선호하는 개발 툴을 활용할 수 있도록 합니다.
   - IBM BlueMix 모바일 서비스를 포함해 enterprise data, applications 그리고 cloud service들과 함께 연결되고 동기화 됩니다.
   - device, application, data 그리고 network 단에서 mobile 보안을 강화시켜 줍니다.

   - 하나의 central interface로부터 모바일 앱 포트폴리오를 관리합니다.

Download: IBM Worklight Developer Edition

IBM Worklight Developer Edition은 Eclipse IDE를 위한 self-contained, easy-to-install plugin 입니다. IBM Worklight Enterprise and Consumer Editions 은 각각의 개발 환경과 서버 콤포넌트들로 구성돼 있고 Developer Edition 은 그것들을 묶어서 데이터베이스나 어플리케이선 서버를 따로 인스톨하지 않고 한번에 Eclips용으로 다운로드 할 수 있도록 해 줍니다.

일단 인스톨이 되면 쉽고 빠르게 mobile web, hybrid 그리고 native 앱들을 iOS, 안드로이드, 블랙베리, Windows® Phone 등을 포함한 여러 모바일 플랫폼에서 동작하도록 할 수 있습니다. 이러한 앱 개발을 위해 HTML5, CSS3, JavaScript, Apache Cordova 그리고 jQuery, Sencha Touch, Dojo Mobile 같은 많이 사용되는 자바스크립트 프레임워크들을 사용할 수 있습니다.

Install Worklight Studio - 링크 클릭 후 worklight Studio 탭 선택

Worklight Studio 는 Eclipse plugin으로 신속하게 빌드하고 실행시키고 mobile web, hybrid, native 앱들을 관리할 수 있도록 해 줍니다.

    1. Java EE Developer를 위한 Eclipse IDE를 준비하세요.
    Juno SR2 (4.2.2), Kepler SR1 (4.3.1), Kepler SR2 (4.3.2), or Luna R (4.4).
    이전 버전의 이클립스를 가지고 있다면 Juno, Kepler, Luna 로 업데이트 한 후 아래 과정을 실행하시기 바랍니다.
    
    2.V6.1 이전의 Worklight Developer Edition을 가지고 있다면 그 프로그램을 Uninstall 하세요.
    이전 버전의 Worklight Developer Edition에서 Worklight Studio V6.2 로 업그레이드 할 수 없습니다.
    
    3. 이클립스를 실행후 Help > Eclipse Marketplace를 선택하세요.
      
    4.Find field에 Worklight을 입력한 후 Go를 클릭하세요.
    
    5.IBM Worklight Studio Install 버튼을 클릭하세요.
    
    6.IBM Worklight Studio와 다른 모든 기능들이 이미 선택돼 있을 겁니다. 확인 후 Next를 클릭하세요.
        항상 IBM Worklight Studio를 선택해야 합니다.
        IBM Dojo Mobile Tools 와 IBM jQuery Mobile Tools 들은 선택사항입니다. 필요하시면 선택하세요.
        
    7. license term들을 확인 후 accept 하세요. 그리고 installation을 시작하려면 Finish를 클릭하시면 됩니다.
    
    8. installation을 완료하기 위해 prompt들을 따라 진행하시기 바랍니다.
    
    9. 만약 여러분의 Eclipse workbench 에 IBM Rational Team Concert™ V4.0 Eclipse Client 가 이미 인스톨 되어 있다면, Worklight Studio를 시작하기 전에 이클립스 environment를 clean 하셔야 합니다.
    
    10. 이제 Worklignt 를 시작하세요. 

Get Start 링크 : http://www.ibm.com/developerworks/mobile/worklight/getting-started.html

====================================================================

이번에 join 한 프로젝트에서 하이브리드 모바일 앱을 만드는데 거기서 이 IBM Worklight를 사용합니다.

이 프로젝트에 제 업무의 25%만 사용해서 매뉴얼 테스팅만 하기 때문에 이 툴을 알아야 될 필요는 없지만..

관심있는 Cross-Platform Mobile App Development 툴이라 한번 공부해 보려구요.

다음 글서 부터는 Get Start 링크에 있는 사용법을 따라 해 본 후 정리해서 올릴 계획입니다.

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

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

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

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

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

Project estimating

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


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

테스트 케이스를 만들 때 사용되는 Page Object Design Pattern에 대해 알아 보겠습니다.

우선 개념 파악부터 하고 넘어가죠.

이제 예제를 보겠습니다.

public class Login {

        public void testLogin() {
                selenium.type("inputBox", "testUser");
                selenium.type("password", "my supersecret password");
                selenium.click("sign-in");
                selenium.waitForPageToLoad("PageWaitPeriod");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}

이 코드의 두가지 문제점

1. 테스트 메소드와 AUTs locators (이 예제에서는 ID 들) 들 간의 어떤 구분이 없다. 두개가 하나의 메소드에 그냥 얽혀 있다. 만약에 AUT의 UI가 그 identifiers, layout을 바꾸거나 로그인 방법을 바꾼다면 이 테스트 소스코드도 반드시 바뀌어야 한다.
2. id-locator들은 여러 다른 테스트에서도 사용될 것이다. 로그인을 해야 하는 모든 테스에서 사용될 것이다.

이 예제 대신에 Page Object technique을 사용하면 아래와 같이 고칠 수 있다.

public class SignInPage {

        private Selenium selenium;

        public SignInPage(Selenium selenium) {
                this.selenium = selenium;
                if(!selenium.getTitle().equals("Sign in page")) {
                        throw new IllegalStateException("This is not sign in page, current page is: "
                                        +selenium.getLocation());
                }
        }

        public HomePage loginValidUser(String userName, String password) {
                selenium.type("usernamefield", userName);
                selenium.type("passwordfield", password);
                selenium.click("sign-in");
                selenium.waitForPageToLoad("waitPeriod");

                return new HomePage(selenium);
        }
}

그리고 홈페이지에 대한 page object는 아래와 같을 것이다.

public class HomePage {

        private Selenium selenium;

        public HomePage(Selenium selenium) {
                if (!selenium.getTitle().equals("Home Page of logged in user")) {
                        throw new IllegalStateException("This is not Home Page of logged in user, current page" +
                                        "is: " +selenium.getLocation());
                }
        }

        public HomePage manageProfile() {
                // Page encapsulation to manage profile functionality
                return new HomePage(selenium);
        }

        /*More methods offering the services represented by Home Page
        of Logged User. These methods in turn might return more Page Objects
        for example click on Compose mail button could return ComposeMail class object*/

}

이제 로그인 테스트에서는 이 두 page object들을 아래와 같이 사용하면 된다.

public class TestLogin {

        public void testLogin() {
                SignInPage signInPage = new SignInPage(selenium);
                HomePage homePage = signInPage.loginValidUser("userName", "password");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}

이 page object를 디자인 하는 방법은 여러가지가 있을 수 있다. 하지만 지켜야할 기본적인 룰은 지켜야 한다.
page object에는 어떤 verification이나 assertion을 만들면 안된다. 이 부분은 테스트의 한 부분이다. 그러므로 테스트 코드 내에 그런 기능이 있어야 한다. 절대 page object 내에 그것을 만들면 안된다. page object에는 페이지의 representation이 포함될 것이다.

page object에 들어갈 verification이 하나 있는데 그것은 해당 페이지를 verify 하는 부분이다. 혹은 해당 페이지의 아주 중요한 element도 될 수 있는데 그것은 해당 페이지가 제대로 load 됐는지를 확인하기 위한 부분이다. 이 verification은 해당 page object가 초기화 될 때 수행되어야 한다. 위 예제에서는 SignInPage와 HomePage 생성자가 그 기능을 수행한다.

page object는 전체 페이지를 represent할 필요는 없다. Page Object Design Pattern은 페이지안의 components를 represent하기 위해 사용된다. 만약 AUT안의 페이지가 여러 component들을 가지고 있다면 각 component별로 별도의 page object를 가지고 있게 되면 좀 더 유지관리하기 편할 것이다.

테스팅에 사용되는 다른 Design Pattern들도 있다. 어떤 경우에는 page object들을 instant화 하기 위해 Page Factory 패턴을 사용하기도 한다.

Selenium Wiki 에서 정의된 Page Object를 보려면 여기로 가시면 됩니다.

https://code.google.com/p/selenium/wiki/PageObjects