Agile Testing Days is oodles of fun, as you know (and if not, why?) Apart from a tutorial, a lightning talk and a workshop, and a game I ran, I also read a poem at Cabaret Night. I’m a renaisance man, yeah (and so is my daughter who drew the ATD Horror Story Unicorn). Here
Wonderful time. Again. The Agile Testing Days guys are doing a wonderful job, creating a magical, friendly, family-like conference. Awesome job. I’ve done a tutorial, a workshop, a lightning talk, ran a story telling game, joined a powerpoint karaoke and, oh yes, wrote a poem. Here are the slides from the very funny, killer pony
So we’ve shipped our software. IT’S ALIVE! But DevOps work is never done. In fact, the old Ops part started here, and if there’s any point of having live software in the hands of the customer, this is where we need help. For example, we need to think of are the first seconds, minutes, hours
The 2nd post in the new series on Everyday Unit Testing on rolling out unit testing implementation as a process in an organization. Check it out.
So we now have tested software, yippee! Which means nothing if we don’t get it to actual customers, so let’s talk about shipping to production. Like everything we discussed until now, automation lowers the risk of manual errors, and saves time. But even deploying to production has to have some kind of method to it.
I’ve started a new series on Everyday Unit Testing, this time it’s on the strategic plan of rolling out unit testing implementation as a process in an organization. The first post is about defining the goals right. Check it out.
Last time, we’ve looked at how “regular” development practices have made sure that things worked at the development team level. It’s time to move on. Because, as we know, it’s not working software unless it’s tested. Let me tell you a story, sonny. When I was young, we built the software on my machine. Compiling, testing
Had great fun in Athens this year, and I really want to come back. You can check the slides and video on the “Everyday Unit Testing” site. and if you want to see it live I’m doing it in the QualiTech meetup next week.
For the record: I still don’t like the technical debt metaphor – I feel that it encourages taking on the debt. We don’t know what will happen, so it makes sense to do things now, even badly, and forget the price we’ll need to pay. Metaphors aside, the price we pay is real. It cannot be quantified
The agile manifesto says we value working software. What is working software anyway? We can talk about software working in different contexts. First are the non-tangible parts (more working than software): Idea – The ideas for the product we’re going to build need to make sense and solve the our customer problem Design – We