25 May 2012 14:41
Re: [Cucumber] How we use Cucumber, the sequel!
Mark Maglana <mmaglana@...>
2012-05-25 12:41:42 GMT
2012-05-25 12:41:42 GMT
> However, stepdefs are the domain of the testers so it should be readable for them.
I think the traditional automated tester (post-implementation tests)
is more or less dead. I understand that I created the
Developer-in-Test role, but it was because under the cloak of "QA" we
could hire second generation Xp programmers (in fact, Andrew Premdas
wrote the original job description and "competencies" and the role is
now surprisingly becoming an industry standard). The step_defs are the
domain of the developers - however high the DSL - it is code.
I think I should've written the above as 'test scripts are the domain of testers...' but even that is probably not enough. Test scripts are the concern of the entire team: The developers so that they'll have a written documentation of how they intend to implement the feature, the testers so that they'll know whether the test script covers all possible cases, and the BAs so that they'll know if the planned implementation covers all requirements (or if she needs to add more requirements to make the feature complete).
If a tester wants to code then he becomes a developer and he also writes
production code in a test first manner. Developers write automated
tests, not testers.
Sorry, but that sounds overgeneralized to me. Unit testing, functional testing, etc is probably the domain of developers, but for Specification by Example (borrowing the term from the book of the same name), it should be written and reviewed by the entire team. Otherwise, we'll end up with silos of information between team members.
All code should be readable to those who read and write code, but the
idea of pushing automated tests so high that a tester or BA could
write automatic tests is in fact an old one. This was the promise of
the last decade in keyword or "data-driven" automated test
architecture, where testers could just enter keywords and the code
beneath would run the tests. However, the code beneath broke and a
developer had to fix it. It was wasted effort, that I feel you may be
attempting to reproduce.
I don't know a lot about data-driven automated test architectures, but it seems to be that the problem with that method was caused by team members keeping to themselves. E.g. Testers focus on just writing test scripts, developers focus on code, etc. In that case, it's a process problem that _might_ be solved if team members are able to collaborate more easily.
The weakest area of BDD is the collaborative writing or actual writing
of features - and any improvement in that is obviously commendable.
That's actually the idea behind the style I illustrated in my blog. Since BAs, testers, and developers can understand the test scripts, they can collaborate better. BAs, for example, can comment early on the planned implementation based on the english-like test script. Testers can also comment on the same test scripts if they find a loop hole. The idea is that the team can more easily get early feedback on features. I doubt that this is possible if the test script was written in Ruby.
1) Please prefix the subject with [Ruby], [JVM] or [JS]. This allows people to filter messages.
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to cukes+unsubscribe <at> googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en