Fix us Quick. The process of transforming an organisation to be Agile is a one that is ladden with continous learning and not a quick fix as some might make it seem. Organisations would often employ an Agile Coach for 3months to 1 year hoping that at the end of this period, the organisation would have completed their transformation journey. A great Agile Coach will always inform you that even after the engagement ends, the journey of Agile Transformation has not ended.
Usually when I join an organisation or team to help identify challenges with current processes and help the teams fix their processes, I would usually look for bottlenecks within the organisation. Once identified, bottlenecks are usually not difficult to eliminate compared to the effort that is required to ensure that behaviours that have introduced the bottlenecks are unlearnt.
A bottleneck can be described as a process within a chain of processes that reduces the overall capacity of the entire system due to the limitation of that single process.
Download actual conference slides here: pptx pdf
Introduction: Agile has been around for a while and whilst there has been a lot of successes recorded for some aspects of the software development process such as analysis and development, it seems that testing is that “area” that is being pushed to the right and sometimes made optional. In my years of working in Agile, there are certainly a lot of moments that I had thought “everything else but testing is Agile”.
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 was recently contacted to write an article for a devops online which has been published here but i wanted to post same article on my blog. This is by no means a detailed tutorial but i hope it gives a very quick overview on Continuous Integration and Continous Delivery.
Software development is usually undertaken by one software development team or a number of software development teams. Each software development team would usually consist of developers, testers and business analysts.
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.
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.
In this post, I would like to consider how to write automated tests for negative scenarios for a system built using an asynchronous / event driven architecture. In my previous post, i have mentioned, that these systems are peculiar because the effect of the “write” actions are not immediately stored in the persistence layer of the application under test.
As an example, in the current system which i have been testing on the write side of the application, the write commands traverses though the Command API layer, the command controller layer and the command Handler layer before it ends up in the Event Store.
In recent months i have been testing a system built using the CQRS pattern. CQRS stands for Command Query Responsibility Segregation and you can read more about it here.
As a tester, one of the key takeaway for me is that there is a Read side and a Write side to the application. This is very different to the other applications that i have tested in the past where a write operation would NOT be successfully until the data being sent to the application is successfully persisted.
