Software Testing Career Development
http://watirmelon.wordpress.com/2008/03/13/software-testing-career-development/

對於在軟體測試上的職涯規劃, 作者非常主動地鞭策自己一直往前進. 他認為不管公司有沒有提供這樣的協助或是規劃, 自己都有責任對自己專業生涯發展做些事情.

他發現Ian Clatworthy 提出了一個 professional development framework, M.E.T.A. - Management, Engineering, Technology and Applications.

他根據這個framework加以改良, 變成Leadership, Concepts, Business-focus & Tools. 在這裡面提出在生涯發展規劃中, QA應該要具備哪些能力.

A. Leadership (Ian’s Management)
作者認為不管你是不是manger, supervisor, 或者甚至你都不需要管人, 你都會需要leadership的能力. 因此他將Ian的mangement做了些調整, 變成是leadership. 以下是作者認為要有的leadership
1. Using the right side of my brain
- being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
2. Having a project management focus
- following sound project management techniques and conducting each bit of work as a small project.
3. Writing Well
- following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
4. Communicating Well
- Documenting every bit of work. Communicating progress and issues in the right format at the right time.
5. Team Building
- establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
6. Finding Informal Career Guiders
- always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
7. Being ethical
- Making sure I provide value and I am honest in everything I do.
8. Sticking up for others you work with
- Making sure that your fellow team mates are well supported.


B. Concepts (Ian’s Engineering)
對於software engineering, 作者比較重視software 部分. 也就是包含software design, development and testing相關的理論和觀念.
如果你能有正確的觀念, 那表示你對事情將會有正確的認知和認識
這些觀念通常你在大學中, 就已經學習過, 那些知識通常都歷久不衰.
1. Understanding Software Development Methodologies:
- how IT software design and development works as a whole.
2. Understanding Software Projects:
- how IT software projects work.
3. Understanding Programming:
- knowing programming concepts and techniques.
4. Understanding Testing:
- understanding testing best practices, test driven development, test automation, acceptance testing.
5. Understanding User Centred Design:
- focusing on usability and designing for users. Paper prototyping and iterative design.
6. Understanding Design:
- understanding general design principles.


C. Tools (Ian’s Technology)
作者曾經打算延用Ian的technology這個term, 但是最後他還是覺得tools比較合適. Tools和concepts的差別是, tools是用來支持 Concepts的實踐, 並且tools可能換一直更新, 但是concept通常是保持不變的.
作者目前比較著重在用open source 的tools, 因為他不用錢, 品質也不錯.
1. Programming Languages:
- such as Ruby, Python, Jython.
2. Testing Tools:
- such as Watir, OpenQA.org and homebrew test automation tools.
3. Collaboration Tools:
- such as wiki’s, defect management, blogs.
4. Versioning Tools:
- such as SVN, Bazaar VCS.

此外還一些技術(不算是tools), 作者認為也值得了解
* Ajax (Rich Internet Applications)
* Web 2.0
* Social Networking
* Tag-based Folksonomies
* RSS


D. Business-focus (Ian’s Applications)
作者認為了解目前工作上的business是如何運作, 也是非常重要的一件事情. 通常IT人員不了解, 也不太尊重他們所工作的business.
1. Understanding business goals:
- why I am employed in the first place.
2. Understanding business applications:
- what they do and how they fit into the business processes.
3. Understanding business processes:
- how business is conducted, with or without IT.
4. Understanding how business and IT collaborate and partnership:
- Hoping that the tail doesn’t wag the dog!
5. Providing value to the business:
- continuing to be employed.
6. Keeping up to date with the business:
- knowing what the business industry/competition is doing and about the other happenings in the business domain.
7. Understanding how executive management operates:
- because they usually pay you and maybe you would like to be there someday.

不知道各位看官, 你自己是如何規劃你的職涯發展? 或許和作者相去甚遠, 但是這也無所謂, 指要不要完全都沒有想過就好. 重點是要自己對自己負責, 千萬不要等公司幫你規劃, 那是會拖很久的!!

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

Iteration Demo失敗的原因

It's a Trap!
http://jamesshore.com/Blog/Its-a-Trap.html

在Adopt Agile時, 作者認為最常見的一個問題, 就是要達到iteration commiment會有問題. 換言之, team通常在iteration在結束時, stories大部分只完工一半. 因此在iteration demo時通常都是很令人失望.

你可能會覺得, 造成這個結果的原因, 可能很複雜並且不大相同. 等等!! 事實上... 這是一派胡言, 我必須老實承認, 而不是很鄉愿地欺騙你. 當你選擇了只挑容易做的practices, 這件事都註定要發生了. 也就是說 這條道路看起來容易和簡單,但是它充滿了陷阱.


Trap #1: 日益增加的QA負擔 (The Ever-Increasing QA Burden)
就作者所知, 許多agile team大多是adopt iteration, dailystand-up meeting和planning game, 但是他們並沒採用其他agile 的 engineering (像是refacotring, TDD, pair programming等等), 所以他們的iteration看起來只像是mini版的waterfalls. 也就是RD做design 和coding, 之後的結果由QA去做測試.

在日益增加的測試負擔中, QA最終只會走向死亡. 即使QA有建立automated的測試, 但是這些測試往往是整合式的測試,執行的過程很緩慢的, 很容易break的, 並且會有很大的maintenance的cost. 除此之外, 這些事情都是手動維護, 這是另一個更大的負擔。

更糟的是, 這個負擔是和軟體的size成比例的, 並且在每次的iteration中, 這些負擔會一直重複發生.
不久之後, QA及使用完所有時間去測試, Bug還是會蔓延到下一個iteration, 並且影響到team規劃的可靠度, 使得整個team逐漸掉到無底深淵去

最後結果: buggy iteration demos.

改善方法: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.


Trap #2: 一廂情願的想法 (Wishful Thinking)
另外一個對iteratiom demo失望的原因, 就是team答應超過他們能力所能做的事情. 他們通常歸咎於estimation不夠準確, 但是這不是真正的原因. 真正的原因是team不知為何緣故, 可能是想要取悅RD, customer或manager, 因此膨脹自己能處理的速度

你不管stories是否真正的被做完(有可能只是code complete, 或是來沒被測完, 或是還沒被customer所接受), 但是你都視為他已經完成, 把它算到你的volocity. 你要知道所謂的做完, 是指這個story已經可以被出貨了才叫做完.

所以做完的定義是很嚴苛的, 會使你的velocity數字會很難看的, 所以人們才會捏造它. 常見的手法是自己在自己的capcity數字上乘一個莫名的比例, 讓你的結果看起來比較好看, 比較"積極", "正面".

但是不管你怎樣假造你的數字, 你有能力作多快這件事還是維持不變.

最後結果:
當iteration的demo開始時, team還沒完成任何事. 事實上, 他們甚至做不完他們有能力完成的部份, 因為大部分的工作都是做到一半, 而不是有一半的工作已經做完. 當然, 這將會導致鱉腳的速度, 因而會讓人增加想要去假造較樂觀數字的念頭.

改善方法:
它是最簡單也是最難的方法, 那就是停止去假造你的速度. 根據已經做完的事情來計算, 並秉持謹慎的態度去增加它. 它可會無法產生你喜歡的數字, 但是您會花更少的時間滅火. 您終於可以開始處理您潛在的生產力問題,而不是玩數字的遊戲; 並且在iteration demo, 不會不安的一直低著頭.




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

A Low-Tech Testing Dashboard
- from James Bach, Principal Consultant

通常在測試的過程中, manager常常對於QA在做什麼不是很了解, 總覺得我們好像是黑箱作業, 讓他們無法幫助或是評量我們.

尤其, 他們常常會問
* How does the build look?
* How much testing is left?
* What are the major problems?

這些問題其實還蠻難回答, 你很難以簡單, 又不會太打擾team members的方式, 讓上面的人知道你目前大概的狀況是什麼.

在Agile的世界中,  這樣的狀況又更嚴重. 因為iteration/sprint的時間不長, 因此相對的時間更寶貴, engineer更沒太多時間來update report. 加上大家對agile的誤解是不用寫documentation. 所以manager或是其他非QA的人, 更不知道我們在幹什麼.

直到我遇到James, 我才知道原來已有人, 對這些問題試著提出一些解答.
http://www.satisfice.com/presentations/dashboard.pdf

在這個dashboard中, 它企圖做到下列事情
Report test cycle progress in a simple, structured way...
- that shows progress toward a goal...
- manages expectations...
- and inspires support...
- for an effective test process.



在這份dashboard中, 它會呈現以下五種資訊: (當然我想你可以自行客制化, 重點是他的精神)
1.Product Area
- 15-30 areas (keep it simple)
- Avoid sub-areas: they’re confusing.
- Areas should have roughly equal value.
- Areas together should be inclusive of everything reasonably testable.
- “Product areas” can include tasks or risks- but put them at the end.
- Minimize overlap between areas.
- Areas must "make sense" to your clients, or they won’t use the board

2. Test Effort
(1) 分類
None: Not testing; not planning to test.
Start: No testing yet, but expect to start soon.
Low: Regression or spot testing only; maintaining coverage.
High: Focused testing effort; increasing coverage.
Pause: Temporarily ceased testing, though area is testable.
Blocked: Can’t effectively test, due to blocking problem.
Ship: Going through final tests and signoff procedure.
(2) 規則
- Use red to denote significant problems or stoppages, as in blocked, none, or pause.
- Color ship green once the final tests are complete and everything else on that row is green.
- Use neutral color (such as black or blue, but pick only one) for others, as in start, low, or high.

3. Test Coverage
(1) 分類
0: We have no good information about this area.
1: Sanity Check: major functions & simple data.
1+: More than sanity, but many functions not tested.
2: Common Cases: all functions touched; common & critical tests executed.
2+: Some data, state, or error coverage beyond level 2.
3: Corner Cases: strong data, state, error, or stress testing.
(2) 規則
- Color green if coverage level is acceptable for ship, otherwise color black.
- Level 1 and 2 focus on functional requirements and capabilities: can this product work at all?
- Level 2 may span 50%-90% code coverage.
- Level 2+ and 3 focus on information to judge performance, reliability, compatibility, and other “ilities”: will this product work under realistic usage?
- Level 3 or 3+ implies “if there were a bad bug in this area, we would probably know about it.”

4. Quality Assessment
“We know of no problems in this area that threaten to stop ship or interrupt testing, nor do we have any definite suspicions about any.”
“We know of problems that are possible showstoppers, or we suspect that there are important problems not yet discovered.”
“We know of problems in this area that definitely stop ship or interrupt testing.”

5. Comments
(1) Definition
- Use the comment field to explain anything colored red, or any non-green quality indicator.
(2) Example:
- Problem ID numbers.
- Reasons for pausing, or delayed start.
- Nature of blocking problems.
- Why area is unstaffed.

那你要如何來使用這個dashboard
- 更新的頻率: 2-5/week, or at each build, or prior to each project meeting.
- 如何進行: Set expectation about the duration of the “Testing Clock” and how new builds reset it.
- 如何解釋內容: Be ready to justify the contents of any cell in the dashboard. The authority of the board depends upon meaningful, actionable content.
- 要不要用較High Tech的方式記錄: Sure, you can put this on the web, but will anyone actually look at it???


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

The Documentation Myth

The Documentation Myth
http://jamesshore.com/Blog/The-Documentation-Myth.html

很多人, 包括我自己, 都認為文件是必要的. 即使抱怨要寫文件的人,在他們需要文件的時候, 也是希望別人也要寫文件給他們. 所以就很容易會有這樣的迷思出現:

Myth: Documentation is good.

但是作者提醒我們一件事, 那就是要文件背後真正的問題是什麼? 他到底認為有什麼問題? 是程式碼寫的不夠清楚? 還是整個程式架構不夠organized? 還是到底是什麼?

因為有時麼你拿到一堆文件, 你也不見得會看, 有時候還會因為文件寫的不夠系統化, 導致你不易了解. 或者是你要找尋一些東西時, 無法很快從這些眾多的文件中找到答案.

所以大家可能真正要的是什麼? 作者認為大家要的應該是解答. 你之所以需要文件, 通常是你有地方不清楚, 想要知道答案是什麼. 有些人想要知道系統架構是如何運作; 有些人想要知道return code有哪些, 各代表什麼意思. 因此最終大家想要的是解答.  所以作者認為換個角度想, 真正的狀況是什麼:

Reality: Answers are good.

如果我們能越快得到答案, 那將會更好更滿足.

但是大家應該也知道可以回答問題的方式有很多種, 文件只是其中一種. 如果有別的方式也可以知道答案, 那是否每個東西都要文件化, 或是立即要文件化, 那就不一定了.

作者這裡提出四種方法, 可以幫助你盡快找到答案. 越前面越是Agile team所想追求的. 但如果做不到, 那就是回歸到原先要寫文件的地步.

1. Best of all is not having to ask the question
- Code that is so well-named and structured that it needs no comments; software whose use is intuitively obvious; libraries that scream their purpose and method of use from every API call.
- XP advocates this as an ideal to strive for.
- It's hard to achieve, sure. We don't always get there, no. But try, and when you think you need documentation, try again.
    
2. Next best is being able to ask someone the question and get an answer right away.
- Phone calls and email are okay at this, if the other person responds quickly, but the absolute best in speed and communication quality is having the person right next to you, ready to answer the question.
- It's not a pipe dream(白日夢): that kind of instant response is why agile methods emphasize cross-functional and colocated teams. The productivity gains are amazing.

3. Not as good, but still pretty good, is being able to Google the answer easily.

4. And way, way down at the bottom of the list is "reading through documentation to find the answer."
- Sure, sometimes documentation is beautifully organized, wonderfully written, and a pleasure to read.
- Yeah. The rest of the time, it's, um, not. And the more documentation you have to read before you get the answer, the worse off you are.
- More documentation isn't good; just the opposite.
- The only thing great about sheer weight of information--The Almighty Thud--is the sound it makes.


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

XP 和 Scrum 差別

Differences Between Scrum and Extreme Programming
http://blog.mountaingoatsoftware.com/?p=8

Scrum and Extreme Programming (XP) 都是agile家族中的成員, 常常有人無法分辨他們的差別是什麼. 作者列出了他們的差別, 雖然這些差別不大, 但是很關鍵:

1. Iteration的長度
(1) Scrum
- typically from two weeks to one month long.
(2) XP
- typically one or two weeks long.

2. 在一個iteration內遇到change的處理狀況
(1) Scrum
- Do not allow changes into their sprints.
- Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint.
(2) XP
- Much more amenable to change within their iterations.
- As long as the team hasn't started work on a particular feature, a new feature of equivalent size can be swapped into the XP team's iteration in exchange for the unstarted feature.

3. Feature的處理順序
(1) XP
- Work in a strict priority order.
- Features to be developed are prioritized by the customer (Scrum's Product Owner) and the team is required to work on them in that order.
(2) Scrum
- Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.
- A Scrum team will very likely choose to work on the second most important.
   
4. 是否要遵守一些Enineering Practices
(1) Scrum
- Doesn't prescribe any engineering practices;
(2) XP
- XP does.
- For example: TDD, pair programming, simple design, refacotring...

作者認為要adopt agile, Scrum是一個的好的開始, 因為他已經有iteration, timeboxed的基礎. 但是若是能搭配XP會更好. 因為XP會告訴你要如何做的practices (如TDD, refacotring, pair programming...), 會讓你的能夠開發出品質更好的軟體.

嗯.... XP 確實難度是比較高, 但是應該是比較有用吧?!.....不過剛開始, 還是柿子先挑軟的吃吧, 先站穩腳步吧

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

Close

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

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

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

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

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼