Last thursday, I delivered a presentation about "Behavior Driven Development with cucumber" to my team. Considering my team's agile experience, which is none, I started with the history of Agile.
The main storyline of the history is like this:
* 1956, bug concept shows up, bug hunting involves both testing and debugging
* 1979, testing is seperated from debugging. Movement pushed by Glenford J. Myers, the author of "The art of software testing". Testers start to grow in their own positions and organizations, communicate with developers through document, meetings. W-mode evovles.
* 1990, lightweight software development shows up, to reduce waste in traditional methodology
* 1995, lightweight software development methodology: scrum/XP/Lean development show up
* 2001, lightweight pioneers group together, call their process Agile, Agile manifesto shows up.
After the history, we started to discuss "the waste in traditional development process". Using W-mode as a baseline, my team came up with the following waste:
* duplication
** requirements duplicate with acceptance test cases,
** function specification duplicate with system test cases,
** design/component specification duplicate with integration test cases.
** and document itself hide bugs too
* [Alex] one team idle
** on the W's left part, developers are busy with design/coding, testers are reviewing which is almost idle.
** on the W's right part, testers are busy with all kinds of test cycle, developers are fixing bug which is almost idle.
* bad material generated
** document generated on W-left part do not benifit customers,
** most document can not be re-used
* [yueche] water-fall cause it hard to change
** requirement change or code change like late bug fix, the later they happen, the more they cost
Then we moved on to "How we reduce the waste" with BDD method. Using the outside-in methodology,
* we could replace requirements with automated acceptance test which is user-behavior,
* we could replace function specification with system test cases which is system-behavior,
* we could replace design/component speficition with integration test case which is component-behavior.
Using outside-in, after each component is done, we can test the component itself, then integrate it into system to do system testing, then deploy to do acceptance test, and all of this process is automated. It looks quite like the way how continous integration works.
After the methodology, I did a short demo with Cucumber driven one of our component.
At last, my favourite part - Q&A. I love to see how different people react to new ideas, and what makes them excited and what concerns them. Here's some interesting questions that I collected.
[brady] continous integration looks good, what if I commit 1 line of code, and it takes 2 hours to test through?
If the code committed is passed in unit testing, and component testing, which means it is proven to be good code. Then wait 2 hours to see if it can be integrated into the system is a worthy deal. Anyway it is better than to manually verify it.
[brady] how do you know Given/When/Then can cover all scenarios?
Robert. C. Martin, the author of "Clean Code" comes up with the answer to this one. All programming language we use in our team, perl/java,ruby is state transistion language, which mean it gets an entrance and an exit, between where are different states. Programs transfer from one state to another, caused by different outside/inside actions.
Given/When/Then is a state transistion language, Given as the initial state, Then the final state, and When as the action. So at least for programms in our team, it should fit well.
* [jian] outside-in method might not work for low-level interface change
In traditional water-fall team, this might not work. Because for water-fall, they usually schedule for 2 month as requirement analysis, another 2 month as design phase, then another 2 as coding phase. But in an Agile team, each of our stories last at most 2 weeks, we complete requirement, design, coding, testing in these 2 weeks, any change limit in these 2 weeks are accepted. That's why traditional team takes 1 year to upgrade from 2.1.0 to 2.2.0, while Agile team takes 1 month to release from 1.094320940239 to 5.1203143294.
[jin] how we benefit from it?
The major benefit is that we will have automation to verify the component/system/user's behavior, then we can save tester from verified testing to exploratory testing. Verified testing is that we know how the system should behave, but we do not know if it is doing so. Tasks like input 1, and 1, and press "+", the result is 2, they are better to be automated. Right? While exploratory testing is that we do not know what is out there, what is missing in our requirement or our thoughts, we could all take a moment to see.
The main storyline of the history is like this:
* 1956, bug concept shows up, bug hunting involves both testing and debugging
* 1979, testing is seperated from debugging. Movement pushed by Glenford J. Myers, the author of "The art of software testing". Testers start to grow in their own positions and organizations, communicate with developers through document, meetings. W-mode evovles.
* 1990, lightweight software development shows up, to reduce waste in traditional methodology
* 1995, lightweight software development methodology: scrum/XP/Lean development show up
* 2001, lightweight pioneers group together, call their process Agile, Agile manifesto shows up.
After the history, we started to discuss "the waste in traditional development process". Using W-mode as a baseline, my team came up with the following waste:
* duplication
** requirements duplicate with acceptance test cases,
** function specification duplicate with system test cases,
** design/component specification duplicate with integration test cases.
** and document itself hide bugs too
* [Alex] one team idle
** on the W's left part, developers are busy with design/coding, testers are reviewing which is almost idle.
** on the W's right part, testers are busy with all kinds of test cycle, developers are fixing bug which is almost idle.
* bad material generated
** document generated on W-left part do not benifit customers,
** most document can not be re-used
* [yueche] water-fall cause it hard to change
** requirement change or code change like late bug fix, the later they happen, the more they cost
Then we moved on to "How we reduce the waste" with BDD method. Using the outside-in methodology,
* we could replace requirements with automated acceptance test which is user-behavior,
* we could replace function specification with system test cases which is system-behavior,
* we could replace design/component speficition with integration test case which is component-behavior.
Using outside-in, after each component is done, we can test the component itself, then integrate it into system to do system testing, then deploy to do acceptance test, and all of this process is automated. It looks quite like the way how continous integration works.
After the methodology, I did a short demo with Cucumber driven one of our component.
At last, my favourite part - Q&A. I love to see how different people react to new ideas, and what makes them excited and what concerns them. Here's some interesting questions that I collected.
[brady] continous integration looks good, what if I commit 1 line of code, and it takes 2 hours to test through?
If the code committed is passed in unit testing, and component testing, which means it is proven to be good code. Then wait 2 hours to see if it can be integrated into the system is a worthy deal. Anyway it is better than to manually verify it.
[brady] how do you know Given/When/Then can cover all scenarios?
Robert. C. Martin, the author of "Clean Code" comes up with the answer to this one. All programming language we use in our team, perl/java,ruby is state transistion language, which mean it gets an entrance and an exit, between where are different states. Programs transfer from one state to another, caused by different outside/inside actions.
Given/When/Then is a state transistion language, Given as the initial state, Then the final state, and When as the action. So at least for programms in our team, it should fit well.
* [jian] outside-in method might not work for low-level interface change
In traditional water-fall team, this might not work. Because for water-fall, they usually schedule for 2 month as requirement analysis, another 2 month as design phase, then another 2 as coding phase. But in an Agile team, each of our stories last at most 2 weeks, we complete requirement, design, coding, testing in these 2 weeks, any change limit in these 2 weeks are accepted. That's why traditional team takes 1 year to upgrade from 2.1.0 to 2.2.0, while Agile team takes 1 month to release from 1.094320940239 to 5.1203143294.
[jin] how we benefit from it?
The major benefit is that we will have automation to verify the component/system/user's behavior, then we can save tester from verified testing to exploratory testing. Verified testing is that we know how the system should behave, but we do not know if it is doing so. Tasks like input 1, and 1, and press "+", the result is 2, they are better to be automated. Right? While exploratory testing is that we do not know what is out there, what is missing in our requirement or our thoughts, we could all take a moment to see.
没有评论:
发表评论