In this 3rd & final post on hexagonal architecture I’m going to try & wrap up my opinion on how we as Testers can be confident that a reduction in integration tests will not impact the quality of the code.
This post is WIP & under iterative development!
This is part 2 of my mini series of posts on the hexagonal architecture pattern, its testing strategy & the impact on Testers.
The first post was an attempt to explain hexagonal architecture in a language I understand.
This post is focussed on the testing strategy associated with hexagonal architecture.
This post started life in my series on hexagonal architecture, but it got too unwieldy & not directly related to the topic so here it is in all its own glory.
This post is now a brief introduction to my understanding of test automation, the test automation pyramid & testing quadrants and is used as a reference for the hexagonal architecture series.
This post is WIP & under iterative development!
At my current client, we’re being coached in the Hexagonal Architecture pattern.
Admittedly, the primary focus is towards the Programmers, but the change in the development strategy has an impact on us Testers so we get a seat a table.
What is this change in the development strategy which will impact us Testers? The pattern considers integration tests as brittle & unneccessarily linking the business logic to the implementation. As such, with this pattern, you want as few integration tests as possible. So the question is:
As a Tester, how confident am I that the removal of (automated) integration tests have not decreased the stability of the code?
In this 3 part series, I hope to learn more about hexagonal architecture, what it does for the teams test strategy & what the impact is for Testers.
Fresh out of his keynote, Michael stepped into his session on “Critical Thinking For Testers” This session aimed to give Testers some tools to help them think their way out of a tight spot.
Alan uses his 20+ years experience of hypnosis to influence his approach to testing. In his session, Alan aimed to give us a taste of how hypnosis can be used to help with our testing. Slides for the Testing Hypnotically Session can be found here
Scott’s keynote was about understanding what is asked of us (Testers) & how those requests fit into the bigger picture of what the business / organisation actually wants to achieve.
This session with Leo was around ensuring how we get what we expect from a dialogue / conversation by keeping it relevant & constructive.
Anne-Marie has been working with James Bach in order to write a book on coaching Testers & research for this book has involved the (Skype) coaching of many Testers. This session was a quick glimpse into how online coaching works.
Michael Bolton had the priviledge of the opening keynote of the conference & unsurprisingly he chose to talk about context-driven testing. Turns out his tongue-in-cheek title was taken as such by everyone, so he had to take some time explaining the irony in it! Slides for the “If It’s Not Context-Driven, You Can’t Do It Here” session are available here
With the sun shining (& the wind blowing!) we headed outside to see how changing context impacts our testing of some crazy remote controlled robots!
Unfortunately Anne couldn’t attend so Rob did the keynote on bug triage by himself. It was a slight deviation from the planned keynote, but Rob chose to talk about his Elevator Parable instead of testing lessons from the delivery room labour triage.
The session was aimed at helping us to understand how test charters can be used to drive exploratory testing, instead of long winded test scripts. In this post I refer to test charters as charters to save ink.
Continue reading “Lets Test Session: Markus Gartner – Charter My Tests”
So, Let’s Test has taken my conference cherry & unlike losing various other cherries, this experience was really rather excellent.
I’ve just got the confirmation through that I’ve passed the BBST Foundations of Software Testing Course! It was a tough month, but the course was fantastic & well worth the effort.
To help me read the tweets & see their relationships with each other, I decided to see if there was anyway I could visualise them to make them a bit less dry.
This post demonstrates a few of the ideas I’ve tried. The 3rd one is my favourite (so far)
Last night at North West Tester Gathering Liverpool we played the Scrum version of the Lego Game. This is slightly different to the Lean version in that it is demonstrating collaboration & communication between members of the delivery team as opposed to demonstrating the principles of Lean development.
Rather than letting what I learned about the Lean version of the game going to waste, I decided to try it out with my team on my current client site.
Continue reading “Lean Lego Game”