Hiccupps

This month's  Lean Coffee was hosted by us at  Linguamatics . Here's some brief, aggregated comments and questions  on topics covered by the group I was in. If we don't do testing, what do we replace it with? We move test environment and tooling into Dev. But practically, how do you ensure the customer gets the right thing? Testing vs checking: testers need to exist. Perhaps the tester just becomes an advisor? With more ability to push into production more often and roll back if there's a problem, there can be less testing. Even if testing is done elsewhere (by developers or customers) we still need someone to ask pertinent questions about the product, to evaluate risks. And where is the test manager? The test manager is taking a more strategic view, coaching, keeping people aligned, across products and projects. Testing is being pushed left (into Dev) and pushed right (into production) and up (into the business). Then what would be down ? Why do we n

CEWT #4  was about test management and test managers. One of the things that became apparent during the day was how much of a moveable feast the role associated with this title is. And that reflects my own experience. A few months ago, when discussing courses for the line managers in the Test team, a trainer outlined what his course would cover and asked whether I'd got any heuristics for management. I gave him these, none of which were included in his synopsis: Clear and present . (Say what you think and why, and what you are committed to; encourage and answer any question; be approachable, available and responsive, or say when you can be) It’s all about MOI . (Motivation: explain why we are doing what we’re doing; Organisation: set things up to facilitate work, opportunities; Innovation: be ready with ideas when they’re needed) Congruency in all decisions . (Consider the other person, the context, yourself) In advance of CEWT, one of my team asked me what I felt my r

Recently, I needed to quickly explore an aspect of the behaviour of an application that takes a couple of text file inputs and produces standard output . To get a feel for the task I set up one console with an editor open on two files (1.txt and 2.txt) and another console in which I ran the application this way: $ more 1.txt ; more 2.txt ; diff -b 1.txt 2.txt a b c d e f a b c d e f 1c1,2 < a b c d e f --- > a b c > d e f $ more 1.txt ; more 2.txt ; diff -b 1.txt 2.txt a b c d e f a b c d e f $ more 1.txt ; more 2.txt ; diff -b 1.txt 2.txt a b c d e f a b cd e f 1c1 < a b c d e f --- > a b cd e f As you can see I have a single command line that dumps both the inputs and the outputs. (And diff was not the actual application I was testing!) After each run I changed some aspect of the inputs in the first console, pressed up and enter in the second console. What am I achieving here? I have a simple runner and record of my experiments and an easy vi

In Something of Note , a post about Karo Stoltzenburg and Neil Younger's recent workshop on note-taking, I wrote: I am especially inspired to see whether I can distil any conventions from my own note-taking ...  I favour plain text for note-taking on the computer and I have established conventions that suit me for that. I wonder are any conventions present in multiple of the approaches that I use? Since then I've been collecting fieldstones  as I observe myself at work, talking to colleagues about how they see my note-taking and how it differs from theirs, and looking for patterns and lack of patterns in that data. Conventions I already knew that I'd been revising and refining how I take notes on the computer for years. Looking back I can see that I first blogged about it in The Power of Fancy Plain Text  in 2011 but I'd long since been crafting my conventions and had settled on something close to Mediawiki markup  for pretty much everything.  And Mediawiki