XP 和Scrum的比較
eXtreme Programming Versus Scrum
http://www.agile-software-development.com/2008/04/extreme-programming-versus-scrum.html
XP 和Scrum到底那一個比較好呢? 作者聽到很多人問這樣的問題. 作者認為這兩者是很難比較的, 因為他們是不同樣的東西, 因此無法比較起.
基本上來說, 他們是根據agile manifesto和agiel principles所發展出來的, 有些地方他們是有重複(如user story, iteration/sprint, accpetance test 等等), 但是他們是不同面向的東西. 以下是作者的分析
XP
(1) XP is an agile engineering methodology.
(2) If your motivation for agile is simplification of requirements management and improved product quality, XP is for you.
(3) XP is the more likely starting point when the adoption of agile is driven by developers.
Scrum
(1) Scrum is an agile management methodology.
- Scrum and XP are entirely complementary.
(2) If your motivation for agile is wanting more visibility, better business engagement, team collaboration, a clear process for prioritisation, etc - Scrum is for you.
- If you use both(Scrum and XP), you will benefit from a more incremental, iterative approach to development.
(3) Scrum is the more likely starting point when the adoption of agile is driven by management.
所以根據作者的觀點來說, 他建議你應該兩者都採用. 但是你可以先用一個, 一個能幫你先解決目前你所遇到問題, 之後在adopt另外一個.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
二十個最佳測試實務
20 Best Testing Practices
http://jaanujeeva.blogspot.com/2009/01/20-best-testing-practices.html
根據作者的經驗, 整理出一些他認為best testing practices:
1) 學習去徹底地分析你的測試結果
- Do not ignore the test result.
- The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem.
- Testers will be respected if they not only log the bugs but also provide solutions.
2) 在每次測試中, 學習去涵蓋更多受測範圍
- Though 100 percent test coverage might not be possible still you can always try to reach near it.
3) 將你的受測軟體分解成更小的部份, 並且最大化其涵蓋程度
- Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
* E.g: Let’s assume you have divided your website application in modules and ‘accepting user information’ is one of the modules.
- You can break this ‘User information’ screen into smaller parts for writing test cases:
* Parts like UI testing, security testing, functional testing of the ‘User information’ form etc.
- Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.
4) 在撰寫測試個案, 先考慮測試所想要的功能, 也就是先確認規格上的功能
- Then write test cases for invalid conditions.
- This will cover expected as well unexpected behavior of application under test.
5) 要認為你一定找得到bug
- Start testing the application by intend of finding bugs/errors.
- Don’t think beforehand that there will not be any bugs in the application.
- If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.
6) 根據需求分析和設計階段本身來開力測試個案
- This way you can ensure all the requirements are testable.
7) 確認你的測試個案能在RD撰寫程式前就能拿到
- Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs.
- Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.
8) 如果可能的話, 確認和分類哪些測試個案可供回歸測試使用
- This will ensure quick and effective manual regression testing.
9) 需要徹底測試, 受測軟體是否有能在適當的時間內反應
- Performance testing is the critical part of many applications.
- In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume.
- Find out ways to test your application for performance.
- If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.
10) RD不應該測試他們自己寫的code
- Basic unit testing of developed application should be enough for developers to release the application for testers.
- But you (testers) should not force developers to release the product for testing. Let them take their own time.
- Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly.
- This is a typical situation in agile project environment.
11) 應該不只只測試需求上面的東西而已
- Test application for what it is not supposed to do.
12) 在做回歸測試時, 需要根據bug grpah來決定測試方向
- Bug graph - number of bugs found against time for different modules
- This module-wise bug graph can be useful to predict the most probable bug part of the application.
13) 在測試的時候記錄下新的要處理項目和想法
- Keep a text file open while testing an application.
- Note down the testing progress, observations in it.
- Use these notepad observations while preparing final test release report.
- This good habit will help you to provide the complete unambiguous test report and release details.
14) 有時候你會因為特需需求而對受測軟體做修改
- This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects.
- Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.
15) 讓RD 遠離測試環境
- This is required step to detect any configuration changes missing in release or deployment document.
- Some times developers do some system or application configuration changes but forget to mention those in deployment steps.
- If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.
16) 讓QA在需求和設計階段時加入, 是非常有幫助的作法
- These way testers can get knowledge of application dependability resulting in detailed test coverage.
- If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.
17) QA team 需要和組織內其他團隊, 分享好的testing practices和experience
18) 需要多花時間和RD對話, 以去了解你的受測軟體
- Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings.
- But also when you understand the requirement or resolve any dispute - make sure to communicate the same over written communication ways like emails.
- Do not keep any thing verbal.
19) 不要用完的所有時間只做high priority testing tasks.
- Prioritize your testing work from high to low priority and plan your work accordingly.
- Analyze all associated risks to prioritize your work.
20) 要能撰寫簡潔, 描述清楚的, 讓人不會搞混的Bug Report
- Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.
不要忘記, 測試是一個非常creative 和 challenging的工作. 當你在處理這樣的挑戰時, 你的經驗和技術非常有關係的.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
Exploratory Testing
http://insidesqa.blogspot.com/2009/02/exploratory-testing.html
2009 Feb 17
Posted by Peter Marshall on LinkedIn
Pubished in Inside QA
ET(Exploratory Testing) 在agile中常常被人拿出來使用, 但是即使在非agile的狀況下, 作者也認為ET也是非常適用的. 它能幫助你找到一些你沒想到的問題.
在Agile的project中, 正常來說要執行, unit testing, 用FIT來做integration testing, 要和CI(continuous integration) 整合, 要做acceptance testing等等, 如果有正確被執行, 相信品質會有一定的水準.
但是事實上, 事情通常沒有這麼順利, 可能是那些事情沒有做, 或是即使有做, 但是那些測試項目範圍或是深度不夠. 因此tester通常需要適時執行一些ET, 來確保軟體的品質.
以下是作者列出的checking list, 來確認ET要使用的時機
1. Always use in conjunction with planned tests on high impact stories. Cover as much as you can!
2. Use when trying to reproduce system failure.
3. Use when defect clusters have been identified. This will flush out even more defects.
4. Always use when you have a good technical understanding of the system architecture. You will already be aware of what usually breaks certain systems.
當你在執行ET時, 作者建議必須要小心以下事情
1. Demonstrate a plan of action. Even a quick outline of what you aim to achieve by carrying out certain actions will give confidence in your actions.
2. Write down all tests that are performed. I use a test short hand that describes navigation/action/result in just one sentence. This enables you to create more tests further down the line.
3. Let the system risk analysis guide you to critical areas of the application. This is where exploratory testing pays off.
4. Sit near to, or with the development team to enable quick solutions to problems and questions.
5. Never rely on just doing exploratory testing.
記住: 完全沒有計畫的隨機測試, 不是exploratory Testing, 而是糟糕的測試.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
Bug Bash的執行經驗談
How to run a bug bash
http://www.scottberkun.com/blog/2008/how-to-run-a-bug-bash/
作者認為bug bash, 是軟體開發產業中不能說的秘密. 在正式的軟體工程課程上, 你從來沒有看過它.
如果有專門的QA, 或是你能夠把TDD執行的很好, 或許你會使用到bug bash的機率會比較小. 但是大部分的組織, 不會有這樣的事發生. 所以作者認為bug bash是經常被使用的技巧, 來維持產品的品質.
雖然bug bash有許多好處, 但是若是你執行方法不正確, 那並不會產生好的結果, 會變成只是一個多餘的工作. 所以作者將會告訴我們, 要如何進行才會讓bug bash的效果發揮到最好.
以下是作者在執行bug bash的致勝秘訣
1. 不要造成大家恐慌
- If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot.
- You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
2. 凍結目前的source codes
- You can not do a bug bash on a moving target: you invalidate repro cases and bug findings.
- Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash.
- This should go without saying, but you never know.
- If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
3. 告訴大家怎樣才是好的bug reports
- Remind everyone crappy bug reports create extra work.
- Provide two bug report examples: one good, one bad.
In the good example show well written description, clear repro steps, and a search for duplicate bugs.
In the bad, show incomprehensible descriptions, impossible repro steps, etc.
- If you don’t provide examples, don’t expect people to magically know what you’re looking for.
- Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
4. 告訴大家要測試哪些地方或是要找出哪類型的bug
- Saying “find bugs” is a shot in the dark.
- It shows you have no clue what’s going on in your project.
- Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash.
- Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
5. 要確認大家在這段時間能配合作bug bash
- A bug bash should be an entire team activity and a half-day is the perfect amount of time.
- Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape.
- If it’s voluntary, or only half the team is asked to do it, the bash will fail.
- People will smell you’re not serious about the effort, and will contribute accordingly.
- Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot.
- Include details (see below) on where bug bash HQ is, what the prizes are, etc.
6. 需要取得大頭們的支持
- With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (”If Fred, our best programmer is doing it, I should be doing it too”).
- Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
7. 找一個地方大家可以集中進行bug bash
- Finding bugs can be a social activity: have a bug bash headquarters.
- Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together.
- This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event.
- A case of beer and few pizzas costs $60. Well worth it.
8. 記錄執行成績並提供獎賞
- Geeks are competitive. Use this to your advantage.
- Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time.
- Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ - give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot.
- You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
9. 建立可相互競爭的小組
- If you are totally poor, use ego prizes.
- Have the designers challenge the programmers, or the marketing team challenge the management team.
- Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”.
- If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc.
- Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other.
- This rivalry will draw more people in, if only to follow along.
- Do this once and you’ll have a tradition to build on for the next bug bash.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
Agile Testing 的策略
http://insidesqa.blogspot.com/2009/02/agile-test-strategy.html
作者過去曾經設計很heavy的testing strategy, 並且試圖讓人知道為什麼要這麼做, 以及要做些什麼事
但是他也發現, 不管先前做這些事的意圖多麼正當, 可是在執行的過程中常常無法達到那樣的效果
所以他在最近一次的project中, 他改良出一版lean testing strategy. 他認為這次是比較有用, 並且比較實務
所以就讓我們來看看, 作者改良後的testing strategy為何:
Phase: Project Set Up
* Understand the project
* Collect information about the project
* Create a test knowledge repository
Phase: Planning & Analysis or Release Planning
* Assist in the definition and scope of stories
* Develop test plans based on planning session
Phase: Development Iterations
* Risk analysis during the sprint/iteration planning
* Construct acceptance tests for each story
* Develop business functionality validation plan
* Document and write tests for defects
* Automate with both unit and UI tests
* Assist in functional review/demo
* Accept User stories
Phase: Hardening Iterations
* Regression test
* Business acceptance testing
* Develop release readiness plan
* Run performance tests
Phase: Release
* Assist in release readiness
* Plan test release data and tests
* Accept the Release
作者認為根據這個strategy, 它可以deliver經得起考驗的軟體, 但是又不會有像傳統測試一樣, 需要有大量文件撰寫的負擔
不知過位看倌你覺得如何?
kojenchieh 發表在 痞客邦 留言(0) 人氣()
