What I’m looking for is a role as an agile software tester in a team that really strives to improve on agile techniques in both, testing and programming. I’m interested in learning more about DevOps, continuous delivery and automation, including but not limited to test automation.
Travelling in Northern Germany or Denmark is fine and a possibility to work (partially) remote would be lovely.
Technically, a project using Ruby and/or Rails would be fantastic. In case the team is working on steps to also use Elixir, that would be a bonus.
In Alistair Cockburn’s description the order is reversed (see Agile Software Development, 2nd edition p. 37 ff), but in my opinion the order isn’t always that important: I am worried that testing doesn’t consider one of the two values of software.
To my experience, essentially all projects focus on current or near-future behaviour of software, but rarely actively work to keep the software ready to deal with future requirements. I understand that YAGNI (You ain’t gonna need it) may play a role here. But mind you: YAGNI mostly applies to actually implemented features that are not needed. It may also be valid in order to prevent going overboard with too much abstraction and flexibility. In the end, you always need to find a balance between following and ignoring the SOLID principles (a good part of the Clean Coders videos covers this in detail).
Concerning the 1st value of software (according to Uncle Bob Martin), I’m convinced that testing needs to answer questions like this:
Is “the ability of software to tolerate and facilitate such ongoing change” a job purely for programmers?
Can software testers contribute to the primary value? Should they?
If yes, is this part of the job or should we keep out of this business?
I personally think testers should get involved: A tester is somebody who knows that things can be different, as Jerry Weinberg says.
Also, I definitely want my clients, as well as their clients, to be happy with the software I help to develop, not only today, but also in the future, even when most original developers of a software system have left the team or company.
When your project (or product life cycle) comes to an end it should stay in your memory not like the smoking remainders of a fire, but with the bright colours of a great sunset.