Most Agile methodologies provide for the application of a Technical Spike for exploring a new technology or risky areas of a product. The Scaled Agile Framework (SAFe) methodology defines the Spike as a type of Exploration and Enabler Story.
There are a number of approaches that have been recommended for Technical Spikes. These include:
Estimating and sizing a Technical Spike Story
Timeboxing a Technical Spike .
The Technical Spike is exploratory in nature and it is conflicting to attempt to estimate the complexity for a piece of work that is not well understood; in my experience most teams would rather Timebox the efforts required to complete a Technical Spike.
So I have used quite a number of tools in my time building test automation frameworks over the years; and in the last 2years i have evaluated a number of these tools and i am becoming more and more opinionated in my choice of tools.
For someone that has used selenium/webdriver and cucumber a lot in the past, i find myself using Geb and Spock these days and it hasnt been much difficulty in switch to these tools.
In my the few years, where i have pushed for testers developers to write acceptance test before development or implementation commences, I’ve had testers come up to me say its difficult to achieve this when you dont know what the UI would look like.
This post would attempt to decribe how i have done this in the past and i still do this at the moment.
NB: Ideally i would write my test using page object pattern, if this was a new project, I would start creating page objects
Having just finished an engagement with a client where the development practices include kanban and BDD. Kanban for us meant that we give priority to work on the right side of the board. So as a tester, I would rather spend my time doing some manual testing on a story that is in the QA queue, than writing automated acceptance tests for a story in the queue for Acceptance Tests.
