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.
I have written in my previous blog about how we need to distribute our tests across the testing pyramid for reasons which i have explained in the previous blog. This particular post is focussed on how we ought to design our tests across the higher levels of abstractions which includes the UI test and API tests.
For the purpose of the blog, I would be using a case study of team that writes its UI Acceptance tests in protractor (Javascript) and the API tests in Java using RestAssured library.
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.
