I need to make my post more clear – by “reuse” I mean open one TCP connection and one SSL handshake to be done for multiple transaction with https webservice. When the TCP connection is closed (or dropped), session cache can be used to speed up handshake of new TCP connection.

I`ve checked SSLSessionCache and SSLCertificateSocketFactory with HttpsUrlConnection without any benefit (compared to standard SSLContext.getSocketFactory).

Have you check connection reuse with tools like tcpdump on server side?

if you think about reuse of HttpClient, you can make multiple webservice calls through it. SSL session could be set in CustomSslSocketFactory (in example) like this (but I didn’t test it):

SSLSessionCache sslSession = new SSLSessionCache(context);
SchemeRegistry registry = new SchemeRegistry();

registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
registry.register(new Scheme("https", SSLCertificateSocketFactory.getHttpSocketFactory(10*60*1000, sslSession), 444));


Does your method supporting connection reuse as well as SSL session? The idea if to speed up multiple transactions with webservice with just one connection?

Thx in advance

All of Scrum Diagram – PDF

All of Scrum Diagram – OpenDocument Graphics

I also have a guidelines/rules-of-thumb list:

Scrum Rules of Thumb – PDF

And some pitfalls listed out:

General Scrum Pitfalls – PDF

Scrum Product Owner Pitfalls – PDF

this solution works fine for me. I tried it on phones with API level 7 and 8. You can try this: SSLContext.getInstance(TrustManagerFactory.getDefaultAlgorithm()) or try with KeyManagerFactory.getDefaultAlgorithm().

interesting discussion

First I have to object with your last statement, that user stories should be pillars to support reusability of the component. It should be the team’s concern how to support reusability of a component. It’s the team’s responsibility to create and design components, how can product backlog items support reusability of such?

I do agree though, that you can use epics as part of a bigger workflow, and stories to gradually flesh out the epic – that’s more or less what you do in story mapping.

Your post leaves me a little confused about the used terminology: partitions, subsets and set of subsets and how that maps to epics and stories. (IMHO epics and stories are the same, just of different size. so epics can contain epics or stories, stories are the leaf nodes). When I understood you correctly you propose, that partitions (business domain) should consist of epics (process), which contain stories (process steps). Right?

Also I don’t yet understand, if you would like the stories functionally dependent (you say so in the 2nd BaPaL) or with minimal interaction (5th BaPaL). In order to gain the maximum degree of freedom to order the items in the product backlog, you should always strive for independant items (I in INVEST). Is that what you mean?

Another thing that I noticed was, that the 3rd and 4th BaPaL say, that epics should be of comparable size, and contain one to two hand full of stories. If you do that for the whole backlog, you run into the problem that Marc mentioned: the product backlog is a living thing, you constantly reshape, resize, split, join and reorder items to maximise the value. Reading the 5 BaPaLs I get the impression, that this could be done as a one-time effort before development starts. A lot of that effort is than probably wasted, because you don’t need all of what you thought you need (maybe this is still coming in your second post about simplification…). On the other hand, you say that “the process of product backlog grooming is an incremental process”. How does that go together with the 3rd and 4th BaPaL?

On a final note, I agree that the product backlog should contain everything that needs to be done to a product to get it released. When Marc says that “It has the purpose to steer the developement process. It is not a tool to manage, structure or design requirements,” I think he means that the PB should not contain all ideas that are currently in your head, but only what is relevant for the current release you are working on. (right, marc?). This is also how I read your post, so I think in that respect you two are on the same page. Marc did not say, that he want’s to use the product backlog for project management – actually, I don’t know what you mean with a project management tool. Something like MS Project?

Thanks for the interesting thoughts,
Andreas

in my opinion writing tests with JBehave is a joined effort (as with most of the Test Automation Tools).

Writing the test functionality requires implementing those in Java and that is probably not possible for QA people, but must be done by developers. How much coding is required – and how complicated this might get – depends heavily on the application you are about to test.

Once there is a set of “test functionality implementations” available, it is of course very much possible – and also wanted I would say – that QA people are then writing the actual tests using this functionality. Of course it requires some good documentation (and/or close cooperation with QA people) on the developers side, so that peolple writing the tests (scenarios) know what they can use.

Using variants as described in the blog by my collegue here (http://blog.codecentric.de/en/2012/04/easier-jbehave-steps-with-variants/) could help writing the scenarios more easily.

Hope that helps to some extend .

Best Regards
- Thomas

Couple of questions:
- Is JBehave mainly a tool aimed for the developers?
- What kind of technical skills you need to successfully create automation set with JBehave? I.E how much coding is involved with Java?
- Is it suitable for non-technical QA people to use JBehave?

-JM