In the last 5 years or so, we have been training and mentoring Software Testers and Business Analysts and as part of the mentoring session, I ask about their experience of interviews; generally I am looking for the sort of questions the mentees are being asked and more importantly what answers were provided to the interviewers. My observations in recent years is that there is an increasing demand for manual testers with technical skills and knowledge of databases is one that sits high on the list of technical skills.
An Agile Coach helping Leaders to weave Agility into the structure of their organisation so that they can thrive within the complex business environment.
Agile Delivery
These blogposts are my opinions from reflections on topics relating to my current area of interest - Enterprise Agility, Leadership, Entreprenuership, Personal Development and Complexities of Africa.
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.
This post is spurned by taking a reflection on my journey as a tester and it’s amazing to see how much i have moved from designing large UI test suites to very small UI test suites. For emphasis, the largest test suite had taken over 8 hrs and the smallest has been 3mins of execution time. There are a lot of posts on the internet about how fragile a UI test framework could be and i would expect the next question to be how have you been able to achieve this.
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
I have been working at this client where i am opportuned to use cucumber, watir-webdriver and i came across this problem today. The application i am testing is an e-commerce site and i am writing test for a page on which i click on an item and the item appears on the shopping basket area of the site.
My code look like
[code]
def select_item(item_name) @browser.li(:text => /#{item_name}/).link(:class_name => “addOptions”).click Watir::Wait.
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.