by diro | 7 月 21, 2015 | 敏捷思維, 軟體開發
在 Scrum Team 中很強調 透明(transparency)，這次跟大家分享的是 Developer Resource 透明化帶來的好處。傳統團隊在傳統的開發方法上，常常都是以”月”、”季”為時間單位，因此常會聽到 PM 說：可不可以再加這個 X 功能、這個 Y 功能，還有那個 Z 也順便加進來好了，這一季完成這些，應該沒問題吧？身為 developer 能拒絕他嗎？有點難，因為感覺一季的時間應該可以做蠻多事情的，就算你覺得不可以，PM也很容易這樣感覺：一季耶，三個月你竟然沒辦法幫我多做 X+Y+Z?在 Developer...
by diro | 6 月 9, 2015 | 軟體開發
https://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/這一系列 QML engine 的文章(其實目前也只有一篇….)深入探討了 QML engine 的內部運作機制。Lars Knoll 指出了目前 QML engine 比較大的問題包括：Several object models也就是一個 QML item 必需有3個object models，分別存在於 V8 engine, QML engine, Native Qt...
by diro | 5 月 6, 2015 | 敏捷思維, 軟體開發
「不要試圖覆蓋所有使用案例。Spec.不是用來替代組合回歸測試的。」 － Spec by Example 中文版 p.151但我們明明覺得現在用 Robot Framework 實現自動化 UAT 來替代組合回歸測試是很正確的做法，為什麼作者覺得這樣不對?我認為是因為作者在討論的是 Spec by Example ，或著說想用 ATDD 的方式來開發軟體，而一旦變成回歸測試，就失去了最初的目標了。但是..「Since your examples might serve as regression tests, you are...
by diro | 3 月 11, 2015 | 軟體開發
在做自動化 UAT 時，最常做的事便是拿 HANDLE，這在以前傳統的 GUI Framework 只要用 Spy++ 或其它開發工具都很容易做到。但現在 QML 不一樣了，QML 裡頭已經沒有所謂的 window handle，比較接近的是 objectName，你可以用 objectName 來對該元件進行操作（get property, call method…)，問題是要怎麼樣拿到 objectName 呢？最直覺的作法就是直接看 QML source code，有錢一點的可能是用 Squish 之類的工具去做。但是直接看...
by diro | 3 月 11, 2015 | 軟體開發
一直都是使用 Robot Framework 來進行自動化的 UAT，但因為完整的 UAT 還包括了手動測試的部份，因此在 UAT 中 Test Case 的管理上就比較麻煩一點，可能完整的 test case 是存在 excel 裡頭，再由開發人員手動填入 Robot Framework 的測試結果。這樣真的太低級了，這不但浪費時間、易出錯，而且很難管理啊，所以必需有一個更好的管理方式。為了解決這個問題，我們導入了 TestRail。TestRail 是一套相當好用的 Test Case / Test Plan 管理系統，而且...
