十件你所不知道有關Automation的事情

10 Things You Might Not Know About Automation
By Linda Hayes, Better Software, Jan/Feb 2009

1. 測試資料是最困難的部份
- Automation is all about repeatability, and if your data is unstable or unpredictable, then your tests can't be repeated.
- Consider using your automation tool to load data so you always know the state of your test environment.

2. Record and play 只是商業噱頭, 不應該完全是你實作的策略
- Designed to make it look easy long enough for your check to clear, recorded scripts are nothing more than bad, fragile code.
- The mere mention of this term by a vendor should be grounds for expulsion from serious consideration, as it has been proven responsible for untold failed automation efforts. Don't be fooled.

3. Don't write programs to test programs
- Don't try to replicate application logic in your tests or you will end up with more code than the application itself has.
- Write your automated test to expect the expected and use logic only to recover from the unexpected
(我真的不是很了解作者想強調什麼, 知道的人分享一下吧)

4. 量多不一定有用
- Just because automation can run more tests than you can perform manually does not mean more is better.
- Every test takes time to design, develop, execute, and analyze.
- Worry about coverage, not quantity.

5. 維護性是重要的考量
- We test software because it changes.
- If it takes too long to update your tests, you can't keep up and you will have to revert to manual testing to meet schedules.
- If a vendor tells you it is easier to re-create the test than to maintain it, run for your life.
- Be sure that maintainability is a key quality of any test library design.

6. 不要認為Automation是在最後才能做的
- Anyone who says you can't automate until the application is complete and stable does not know how to design a proper test.
- Modern techniques allow tests to be automated before the code is even allowing automation to play a part in even the most agile of environments

7. 不要認為做了automation,就不需要領域專家
- If an automation tool is so technical it cannot be used by the people who know your application best, keep looking.
- Programming prowess is not a substitute for domain expertize.
- Testing is only as good as the tester.

8. 規劃好內部開發規則
- Establish and enforce naming conventions, design standards, and change control procedures.
- Whitout them, you will lost track of your test assets, resulting in duplication and omission.
- If you cannot find a test, you cannot use it, and if you cannot make sense of it, you cannot maintain it.

9. 要記錄下你的設計原理
- The most elegant of all architectures has no value if you cannot understand it.
many a genius has labored over an approach only to leave confusion behind when he leaves.
- Insist on diagrams and documentation that describe the overall structure and the purpose of components.

10. 要請開發人員也加入
- Unless the developers cooperate by deliveing testable code in the form of persistent object names, exposed methods and properties, and enough heads-up on changes for you to react, all of your efforts will be in vain.
- Make programmers your partners, educating them about what it takes to automate and supporting them with automated build tests and other time savers.

kojenchieh 發表在 痞客邦 留言(3) 人氣()

實施Scrum的經驗談

When is Scrum not Scrum?
http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/

February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts

作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.

1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.

2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.

3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
    *Ease and accuracy of burndown
        burndown on tasks rather than hours
        making the whole process binary: a task is done or it is not done
    *It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.

5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.

6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.

7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.

8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.




kojenchieh 發表在 痞客邦 留言(0) 人氣()

如何利用Daily Burndown Chart來追蹤進度

How To Implement Scrum In 10 Easy Steps - Step #8: Track Progress With A Daily Burndown Chart
http://www.agile-software-development.com/2007/11/how-to-implement-scrum-in-10-easy-steps.html

Posted by Kelly Water
Published in All About Agile

通常傳統的的開發專案, 在一開始的時候, 開啟來一切都很順利, 幾乎有80%的完成率. 可是隨著時間的演進, 事情越來越糟, 越來越多事情無法on schedule.直到最後的關頭, 你終於承認你無法達到原先的目標, 可是那時候已經為時已晚, 已經無法做什麼事情可以幫助它來改善.

在Agile的開發專案中, 有些好的principle可以早點指出這樣的問題. 雖然一開始令人看起來很不安, 但是仍然有時間可以做些事情來改善它.

像是testing, 在傳統開發流程中, 他總是在最後關頭才做, 因此在面對龐大的系統要做測試, 其品質即時程程很難控制的. 可是在Agile開發流程中, 測試的活動是伴隨著整個流程, 因此一旦某個feature完成, 通常也代表他已經經過適當的測試. 不會到最後才來確認他的品質.

因為Product Owner或是customer加入, 在整個流程的當中, 隨時可以review 產品, 以確認產品有照著需求來做.

除了這些principles外, 每天的stand-up meeting, 可以幫助你清楚知道整個專案的進度如何, 每個人會提供他自己的的處理狀況給所有team members知道

但是, 除了這樣之外, 作者認為Daily Burndown Char也是一個好的工具, 它很簡單, 但是很有用. 要怎樣來使用這個工具呢? 以下是作者覺得要注意的地方:
1. 'Estimate To Complete'
- Take all the tasks to be delivered in a particular Sprint in Scrum, i.e. your Sprint Backlog you created in step 4.
- On your Sprint Backlog, enter the estimated time to complete, which of course at the beginning of the Sprint is the same as the original estimate.
- Update the estimated time to complete (ETC) each task on a daily basis.

2. Team members需要對自己負責
- Each team member can be responsible for updating their own ETC's on a daily basis before the Scrum.
- Updating it daily - and sharing the effort amongst the team - means typically there should only be 2 or 3 items to update for each person each day.
- Therefore it should not be onerous and means team members take responsibility for their own tasks
- Be honest about what effort you believe is required to complete each task (and that's the effort needed to really complete each task), regardless of how long has been spent to date and regardless of what was estimated in the first place.

3. 清楚標示出團隊的目標
- The team's goal, quite simply, is for the team to reach zero hours to go, by the end of the Sprint duration.

4. 以視覺化圖形方式來呈現你的進度
- The beauty of this approach is that it's a numeric view of progress and can therefore be plotted visually on a graph.
- Plot the original estimates for the Sprint on one line, and the current estimates to complete on another line.
- When the actual line tracks below the original estimate line, you're on track.
- When it tracks higher, you're running behind. It really is as simple as that.
- Highly visual, instant feedback for the whole team.

5. 紀錄關鍵事件
- I've also found it useful to annotate the graph with 'speech bubbles' describing key events along the way.
- This is a useful way to record significant events so they're not forgotten by the time of the Sprint review.
-  It's also useful to communicate important things to management and stakeholders instead of producing a separate status report.

6. Scrum 會指出你的問題, 但是不會解決它
- Using a burndown chart, when you spend one day on a task and discover
    * a whole load of problems or
    * effort you hadn't anticipated or
    * estimated for, the estimate to complete jumps up,
    * creating an all-too-visual indicator of the problem for all to see.
- When this happens early in a project, and/or on a large scale, believe me it's pretty scary!
- Suddenly you're not so sure about all this new-found visibility!
- It seemed like such a good idea at the time, but can you really stick *that* burndown chart on the wall?!

7. 呈現真實的狀態反應
- But you do gain one big advantage. One enormous advantage.
- You get to see where the project really is, every day, in all its techni-colour glory!
- And when you hit problems in a project, you actually see them.
- And see them when you might just have time to do something about it.




kojenchieh 發表在 痞客邦 留言(0) 人氣()

在Scrum中如何進行測試?

Scrum - Two Levels of Test?

http://insidesqa.blogspot.com/2008/11/scrum-two-levels-of-test.html

23 November 2008
Posted by Peter Marshall
Published in Inside QA

kojenchieh 發表在 痞客邦 留言(0) 人氣()

十大Agile Development網站

Top 10 Agile Development Websites
http://www.agile-software-development.com/2007/05/top-10-agile-development-websites.html

根據 Alexa的資料顯示(Web Information Company, http://www.alexa.com/), 目前大家最常去十個Agile Development 網站是:

1. Martin Fowler
Papers and articles from one of the giants in the field.
www.martinfowler.com

2. ThoughtWorks, Inc.
A commercial site for Martin Fowler's company.
www.thoughtworks.com

3. Agile Modeling
Practice-based methodology for effectively modeling and documenting software-based systems.
www.agilemodeling.com

4. Extreme Programming
A gentle introduction to eXtreme Programming (XP).
www.extremeprogramming.org

5. XProgramming
Articles, FAQs and other information on the XP methodology.
www.xprogramming.com

6. Rally Software Development
Agile development tools and consulting.
www.rallydev.com

7. JUnit
A unit testing framework for Java.
www.junit.org

8. Agile Software Development [Wikipedia]
Wikipedia's definition of agile software development.
http://en.wikipedia.org/wiki/Agile_software_development

9. Alistair Cockburn
One of the parents of the agile movement, and creator of Crystal family of lightweight methodologies.
www.alistair.cockburn.us

10. Advanced Development Methods, Inc.
Home of Scrum agile development methodology.
www.controlchaos.com

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼