The product I currently work on depends on 3 different vendor APIs and, as you would expect, their non-Prod environments go down fairly regularly.
I found it very frustrating that I never knew when their services came back online. So I decided to build a healthcheck endpoint which integrated with Jenkins and Slack and notified me, via Slackbot, once their services came back up. This meant I could switch back and start testing tickets again asap. When you have tight deadlines, and service regularly go down, every minute counts!
I recently discovered the Farnham Street website and something about the podcast with Annie Duke really struck a chord with me. She’s an ex-professional poker player who now gives talks on decision making. It got me thinking about how I my own decisions and how I can make better ones.
Difficult decisions are always based on missing information. If you knew an outcome was guaranteed, there isn’t really a decision to be made. I believe we should reframe how we approach discussions about complex decisions so it’s front and centre in people’s mind; we’re dealing with imperfect knowledge.
Instead of thinking of decisions (and their outcomes) in terms of good and bad, we should talk about them in the context of being better and worse. Good/bad decisions imply certainty, which is very rarely the case. Changing the conversation, so people talk about decisions as being better or worse, helps clarify in people’s minds that we’re dealing with a lack of information which will invariably result in compromise or trade offs.
The real world is full of uncertainty and our discussions should accurately reflect this reality. Peddling in certainty is dodgy business and should be left to the professionals; priests and politicians!
There is a subtle but very important difference between naming something and explaining something.
I’m sure you’ve heard people use the phrase “technical work” in lots of different situations but have you ever stopped to question what it really means? Could you explain “technical work” to someone else in plain, simple language? Could you do it without using the words “technical” or “work”? Now how many of these familiar-sounding terms do you think could you explain to a friend in 90 seconds?
These are some simple visuals I quickly threw together. I hope they will help to improve conversations which will lead to better-informed decisions. In IT we have a habit of using lots of names for exactly the same thing, which frequently leads to longer and more confusing conversations! I hope the visual breakdown of URLs and JSON objects into their constituent parts will be of benefit to newbies and non-techies alike.
On returning to my old iOS team after a brief stint working on our services team, I wanted to implement what I had learned there and improved the stability of our Calabash scenarios. I wanted to shift away from our dependence on test data stored in config files and databases and create test data at the same time as executing our Calabash scenarios.
The whole process was surprisingly simple and straightforward. We used the “Rest-Client” gem and then called some simple data manager classes by using cucumber’s built-in hooks.
I’m lucky in my current role to the independence to test how I see fit. I don’t have somebody forcing me to use a tool that doesn’t work for me. After weeks of plaguing my boss to pay for a JIRA Capture licence, I eventually got my way!! I have used JIRA Capture Test Sessions briefly at a previous company and found it to be a simple but very effective tool for capturing testing notes.
There is a reason why first impressions are important. As soon as you start your testing, there’s no going back! You will make immediate choices and instant appraisal about the feature which is can be very difficult to change.