Testing

STANZ 2011 Day 1 Review

/ Craig Smith / Leave a comment

STANZThe STANZ (Software Testing Australia New Zealand) 2011 conference was held in Wellington and Melbourne on the last week of August (into September). I was lucky enough to be invited to speak at the Melbourne event by my good friends at Software Education, who were the promoters of the event.  I rolled up on the back of a flight from Los Angeles to Brisbane (and then Brisbane to Melbourne) a little jet lagged, but got heaps from the event.

From STANZ 2011

Here are my notes from day one of the conference.

Am I Creating Value With My Testing?

Jonathon Kohl presented this session, a copy of his video and his slides is available here.

From STANZ 2011
  • ask questions of the CEO about the vision and what the product is supposed to do, listen to customer support calls, talk to marketing, talk to the developers about what bugs they value
  • what are the top 10 things people love and hate about your software?
  • look for efficiency – use checklists instead of test cases, forget about regression testing and use the computer to be more efficient
  • testing is about creating value for the people who matter most, your customers
  • people need an emotional attachment to your product – the share market is an example of a product driven by emotion
  • we need to create value for our customers, but just as importantly for ourselves
  • we can’t just focus on business value – it’s a big stick that will erode morale
  • talk to your customers – what do they need, what do they like, dislike, what is missing?
  • talk to team – what do they like about your work, how can you be better?
  • self evaluation – what is new in the field, am I enjoying work, what do other team members focus on or find things that I miss?
  • avoid blame – excuses rather than finding and solving real problems – “we wouldn’t have this problem if we we doing agile”, “management don’t get testing”, etc… – feels good to say but is not constructive
  • don’t expect tools or processes to rescue you – look out for your own best interests, know the problem you are solving and use the tools/process to solve it and ensure you have a way to measure it
  • the key to creating value is alignment – people in different jobs or teams often have different goals
  • leaders – clearly articulate vision and goals to the testing team and how does that align to our goals for the product and company, leadership comes from everyone in the team, leaders need to manage the politics (an organisation with more than one person will have politics)
  • need to continually inject change and keep people interested
  • people have skills, they are not resources – find your talents and invest in it
  • understand your context – every team will be different
  • tangible quality can be measured by understanding if the stakeholders needs are met and if you are meeting ROI, intangible quality is important and not often taken seriously – would you be afraid if you mother used this, would you like your name on the splash screen?
  • impress the most important stakeholder – you!
  • most people don’t know what great testing is – you can be shocked and appalled by what most people think is good, strive to be better
  • tangibly getting better – learn about planning and strategy and exploit the opportunities, write good bug reports as developers really value this, be good at communicating what needs to be done and where we are going, take more responsibility and display competence in basic technical skills
  • intangibly getting better – be in demand for your testing service, have good problem solving ability
  • use external communities to develop your testing skills
  • work as though your favourite person in testing was coming to visit
  • need to be able justify your work – is your testing defensible
  • use repeatable or intermittent bugs as a clue to something bigger – don’t ignore the anomalies
  • testing is like journalism – need to do crazy things to get the story, move towards the issues, people need the news today not tomorrow
  • need to have a technical curiosity about what is going on in the community – what is coming down the pipe, what are the people that have the ability to change things doing?

Overall this was a refreshing session to see a passion in testing and improving skill, with some excellent sound bytes along the way.

What Does A CEO Want From Testing

Mark Feldman from IV&V Australia delivered this presentation.

From STANZ 2011
  • the CEO is accountable for delivery, protecting his reputation
  • the CEO is not going to check test cases unless you look like a risk (ie. front page of the newspaper)
  • governance is a CEO buzzword that covers a bunch of things
  • need to provide more than alignment – creativity and innovation
  • looking for thought leaders and competitiveness enhancement not 80/20 maintenance work
  • CEO wants creative disruption along with well run divisions
  • testing needs to be proactive rather than reactive
  • have some answers about the cloud – how it affects the team
  • CEOs like ERP because they believe there is less risk

Working With Remote & Distributed Teams

Karen Johnson delivered this session.

From STANZ 2011
  • we are not alone – through Twitter and Skype you can connect with great people
  • understand time zones and calculate meetings for each persons time zone, put the number in the meeting request
  • rotate inconvenient team calls – when people are in very inconvenient time zones such as India
  • recalculate time differences again when people are travelling
  • important to have a usable workable space – particularly when working from home
  • some people have trust issues, so ask what have you done for them to have doubts
  • you just can’t work from Starbucks, could you invite your boss to your home workspace
  • be aware on calls when people are not in the room – handing out documents or drawing on the whiteboard
  • get to know your remote people and get to meet them in person when you can
  • observe with your ears – look for clues to mood and listen for tone

From Jaded To Jubilant: Invigorating Your Test Team

Anne-Marie Charrett delivered this presentation.

From STANZ 2011
  • wanted a team that had long term motivation, so could not motivate with carrots
  • Outliers by Malcolm Gladwell – mostly people are successful because they are in the right place at the right time
  • before you can motivate a team you need to ask yourself how motivated you are – what gets you up in the morning about testing
  • know your testers – give your testers a testing challenge to understand how they test, also understand what they want to get out of testing
  • important that your test team knows that you believe in them and that they are being listened to, important that they get excited about testing again
  • testers are paid to think – test scenarios often go against that
  • think about for every test, how is it adding value to the company
  • testers need to take responsibility – make and defend decisions
  • you sometimes need to let go of your own goals – the team need to feel empowered
  • exploratory testing – the tester needs to decide when it is good enough, this is the way testing is and it is hard to estimate – session based test management (SBTM) and Rapid Reporter (enter your charter/objective – time stamps and records test sessions)

I really enjoyed this session, although it reminded me how many organisations still have large test separate teams.

Test Planning for Mobile Application Projects

Jonathon Kohl delivered this session, based on some Techwell articles (part 1 and part 2).

From STANZ 2011
  • implications – power, display size, portability, connectivity, radios, large number of devices
  • less power than a PC – multitasking can freeze memory, interactions with O/S can have a big impact, kinetic input (tapping, touching, pinching) can have strange behaviours, needed to test using physical movement to replicate locking
  • connectivity – strange things happen when moving between WiFi, 3G and 4G, driving also causes issues
  • distribution – you do not have control of distribution in app stores, read the guidelines and understand the timelines early
  • mobile project issues – time pressures due to market competition, smaller applications, constant change in environments, handsets, software, very programmer centric environments so planning, testing, etc is viewed as a bat anchor, lots of competition, high risk if your application does not work as expected
  • testers need to prove their worth as rigid approaches will leave you behind
  • key is to focus on test execution rather than planning, because everything is going to change anyway
  • need a strategy on how you are going to test, what devices you are going to buy, how are you going to manage the devices/cables because they go missing easily (had to chain cables to a hubcap!)
  • find out strategies that you are targeting so you can procure equipment
  • emulators are useful for basic testing, better to use real device of target platform, developers would have used the emulator anyway
  • supporting IOS 3 to IOS 4.1 resulted in 104 combinations between multiple devices, etc – classification trees are good to explain permutations and combinations
  • automation is still in initial infancy – not as nice as web applications at this point
  • devices are being exploited to do combined activities so need to exploit this in testing
  • we use these devices in environments where we do not use a PC – they are addictive and are part of our lives
  • testing will involve leaving the office and moving around to mimic what the users are doing – determine high value because everybody will want to do this testing!
  • tricky to get devices that you are targeting – standing in line for the iPhone!
  • may need to target different carriers and plans as technologies can be different
  • think about logistics of storage, charging, etc…
  • ergonomics are an issue whe testing mobile devices – shorter work days, can be painful on fingers, people are 25% less productive on these devices than PCs
  • health is an issue because devices are shared and illness spreads fast – hand sanitizers, wiping devices after use, washing hands frequently
  • need to factor in training as there are lots of way to use devices
  • taking screen shots is a lot more painful than web applications
  • usability testing – no standards unfortunately, look for user emotions, perceived lack of performance, one of the most important things on these devices
  • performance testing – no real tools, can jailbreak IOS, some emlators have rudimentary tools, can affect performance of device, use stopwatches, spoof the headers, emulate on a machine using small memory footprints and look for speed
  • security is often a trade-off with performance
  • can automate using emulator in a browser, tools are rudimentary, vendors are clamouring in the space, Opera has a mobile mode

Planning

  • influenced by James Bach’s Statisfice Test Plan Evaluation Model and Test Planning Guide
  • planning needs to be a parallel activity, do just enough in regulated environments, video can be good to replace test cases, need to meet their intent and needs but rather than giving them what they ask for give them something better
  • research your customers for your scenario tests – how they will use the app, are they locals or visitors, is it easy to understand outside context (eg. train schedules)
  • trick – search ” sucks” to find and exploit common problems
  • allow time to keep up-to-date with platform changes
  • remember to test technology like GPS, graphics, camera, video, sound, messaging, data
  • Smashing Magazine – good resource for usability
  • modeling state allows you to get understanding quickly
  • risk vs reward testing – focus on what is value – if you need to demo to get funding, test that the demo will work and not crash
  • quality attributes – HP’s FURPS
  • may need to set time aside for guidance documentation
  • put structure and timebox around exploratory testing so that everybody knows what mission and goal is – look at application from different perspectives
  • express completeness as how have we done and how much we have to go from different perspectives
  • Session Tester – video is good for brining new testers in, easier to digest than written down test cases
  • estimating – use uncertainty models (Software Estimation by Steve McConnell), Galton Estimation tool – like to use P90 – give a range, use S curve to give confidence matched to dates
  • regulators are worried about repeatability – they like formal session based testing
  • adapted James Bach’s testing dashboard

10th Anniversary Conference Dinner

Anders Sorman-Nilsson, author of Thinque Funky, gave a very entertaining and thought provoking dinner speech.

Agile 2011: The Speed To Cool – Agile Testing & Building Quality In

/ Craig Smith / 1 Comment

My presentation from Agile 2011 that I delivered with Adrian Smith called “The Speed To Cool: Agile Testing and Building Quality In” is available on Slideshare.

Ensuring that the approach to testing and quality is understood and appropriately valued in an agile world can be a struggle for many organisations, especially when resources are limited and our customers are expecting business value in a timely manner. In this session we will define what quality means and share a number of tools for measuring it, discuss approaches to improving the skills, empowerment and role of testing in the organisation and share why testing is the coolest role on the team and why it is everyones responsibility.

Some of the comments on Twitter included:

@BrianGress: We tend to test only what we can see. #agile2011 @adrianlsmith

@tonyrockyhorror: @smithcdau Speed to Cool was best talk I’ve seen all week. It will take a mighty effort to top it. #agile2011

Adrian also posted about the talk on the Ennova blog.

Agile 2011 Day 4 Review

/ Craig Smith / Leave a comment

Agile 2011Day 4 at Agile 2011 brought a full day sessions full day of sessions followed by the conference dinner. For the first session I used the law of two feet and landed in three different sessions.

Stages of Practice: the Agile Tech Tree

Arlo Belshee and James Shore led this hands on session to build a technical tree of agile practices. I didn’t stay for long, but I was interested in the output, which I found hanging on the walls later in the day.

From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011
From Agile 2011

Creating Customer Delight

Steve Denning (author of a large number of leadership books) delivered this presentation based around a blog post of a similar name that I sat in for about 30 minutes. His presentation is available here.

From Agile 2011
  • move from output to outcome
  • customer must be surprised and delighted
  • move from implicit goal to explicit goal
  • custom delight is the new dimension of done
  • product owner adds contingent valu
  • bottom line is whole organization, not just the team
  • customer delight is measured eg. net promoter score
  • delight is happiness, joy, customer success – everybody has a story or understands this concept
  • identify your project that you wish to delight – who is your customer?
  • what do customers say they want? – warning! they don’t always know eg. New Coke
  • what is it that core customers might not like about your product? eg .why they made the Nespresso machine because people did not like cleaning up, need to get inside their head to understand what you need to change

Agile From the Top Down: Executives Practicing Agile

Jon Stahl delivered this session, and I wish I had been there for this one all the way through as his presentations are always entertaining and informative. His slides are available here.

From Agile 2011
    • visualise your work  in progress (WIP) by putting every project in progress up on the wall, also visualise your demand
From Agile 2011
From Agile 2011
From Agile 2011
    • model your application assets – you will be surprised what you will find – link them, then order them by business value
From Agile 2011
    • create a radiator wall for each one of your assets – understand technical debt, print out each of your defects, be ambarrased!
From Agile 2011
From Agile 2011
    • visualise your org chart – particularly where your skills are, then rank them by apprentice, journeyman, master – then you can score your aptitude
From Agile 2011
  • get HR to create their own room to map the organisation and look for patterns – finding the truth isn’t simple but putting stuff on walls creates conversation
  • create a tool wall – who cares what tool you use, as long as you are adding value
  • get the practice vocabulary up on the wall – matched with a booklet with more detail
  • when tracking practices move away from traffic lights and use smiley faces to track how people are feeling – don’t care about if they are doing stand ups but how are they working for them – good way to figure out where to send coaches, where the frowns are
From Agile 2011
    • transparent leadership – post and show your people what roadblocks you are working on
    • everybody wakes up everyday thinking they are doing the best thing they can – as a business the executives need to check each other to make sure they are working on the most important thing and allow each other to question
From Agile 2011
  • make roadblocks visible – you will get more respect from you people – put one up for every person who has the title manager in your organization
  • leadership team to do retrospectives every two weeks – take people out of their element, makes them more likely to talk
  • continuous improvement – force it by shutting down email, block out meeting rooms
  • you would save money on coaches if you got people to read books, free ice cream by reading a chapter in a room and talking about it in an hour
  • pair management – pair on everything to get better, pair in public which will show developers pairing is ok
  • change name of PMO to MSO (manifesto support office), make them in charge of ensuring the visual radiators are up to date
  • dashboards are costly and evil – they are not the truth, data is mostly inaccurate
  • speak in story cards – create a wall to get answers to things you want to know

Acceptance testing in the land of the startup

Joseph Wilk presented this session, his slides are available here.

From Agile 2011
  • Relish – the only way the customer will read Cucumber tests
  • two way mirrors – ensure the users are integrated into development and they can use the software, outside the building
  • good coders find stuff hard – easy to Cucumber test the full stack but the build time blows, unit tests are hard but are fast, so limit the amount of cucumber tests and isolate them
  • features rot if the Customer does not read them or not exposed via tools like Relish
  • manual testers duplicate automated tests – expose features, pair, give Cucumber ownership to QA
  • how to test lots of permutations – pairwise testing is OK, or just automate the happy path and one scenario and manual test the rest
  • Crazy Egg – monitor what users are actually using
  • use WIP to keep testing under control
  • metrics – JUnit Max to predict probability of failure
  • Limited Red – calculates the probability of Cucumber failure to improve the way we work – found features that never fail – just keep them in nightly build – means a long build usually fails very quickly
  • use JMeter to check everything is up like a tracer bullet – eg. a row has appeared in a table
  • got 8 hour build down to 20 minutes by distributing over 24 EC2 nodes – but think we were solving the wrong problem
  • slice up the architecture and have thin tests to test them
  • Spork – helps to speed up the start up time of an application – hard to know whether to reload and it adds a lot of overload at the protocol layer, so almost as efficient to run the tests
  • people have core responsibilities but we all meld in our roles to be one team and deliver

I enjoyed this session, particularly as I read about Joseph’s company in Specification By Example. I am excited about the prospect of a tool such as Limited Red as well.

Telling Better Stories with User Story Mapping

Jeff Patton led this session to a packed room that included a live appearance from his children! His slides are available here.

From Agile 2011
  • user stories are the simplest idea in the world, but like any simple idea they all get screwed up
  • it’s easy to lose the plot when you have a lot of stories
  • story mapping – tells the whole story of your product and still gets down to the iteration level
  • you already know this stuff!
  • “sharpie markers smell like ideas!”
So…
    • dump ideas onto stickies, on your own – they should almost always start with verbs – we need verbs to do things
    • verbs are a user task – they are a small task
From Agile 2011
  • now we want a flow of what we do from left to right – stack the duplicates and group the similarities – create a user workflow
From Agile 2011
  • mark where the natural breaks are – this is called a user activity – a grouping of things that a user does
  • next, identify where the pain points are
  • because it is a map you can find stuff in it
From Agile 2011
  • how to change the world – start with an idea which is product > feature > specification > requirement
  • learnt that requirement means “shutup just build it”
  • outcomes result in impact – agile is to maximize outcome and impact we get
  • stories are a conversation about the future
  • stories are 5c’s – card –> conversation –> confirmation –> construction –> consequences (when we realise our ability to predict the future sucked!)
  • Kent Beck called them stories because they were meant to be heard
  • need to figure out the who, what, why – this is the richness behind the story
  • add a short title, add a description (story template), add notes, specifications and sketches and write acceptance criteria before writing software
  • stories shrink in size and grow in detail as they travel through a pipeline
  • start with capabilities or features (understand value) –> break to release size stories– > upcoming iteration stories (priority, UI design, business rules) –> break to iteration size stories (details user acceptance tests, small enough to fit in iteration) –> completed bits of software
  • user story mapping – based on story mapping in films
  • ultimately we have big things that break down to little things

Build story maps by:

  1. talking to real users
  2. brainstorm user tasks to help them organize
  3. research and build from a narrative
  • discussions with users in front of a map drive out conversations
  • plan incremental releases as a team event – developers will actually read the plan
  • start talking about adding stickies and notes, finally get a fist of five for confidence
  • don’t prioritise user stories by ROI – target a user segment
  • like ripping a $5 note, the small stories are not valuable (Jeff actually ripped a $5 note to illustrate the point)
  • map at MVP (minimal valuable product) and MMF
From Agile 2011
From Agile 2011

Finally, Jeff has a User Story Mapping book in the pipeline which looks really interesting. I have had the pleasure of meeting Jeff a few times and always enjoy his presentation and learnings, and I am keen to give these learnings a go in my next storycard workshop.

Flirting With Your Customers

Jenni Jepsen delivered this presentation, the slides are available here.

From Agile 2011

We started with an exercise – 3 things that make a great project – trust, hard work, common goals, transparency, clear direction, grown ups, togetherness, support, communication, budget, right skills, creativity, quality, teamwork, fun, support

We then discussed 3 things that make a great romantic relationship – trust, communication, clear expectations, respect, common goals, honesty, integrity, similar values, enjoy spending time together, depth, support, compromise, patience, back rubs, teamwork, equality, chemistry, humour, passion, sacrifice

  • there is a lot of commonality between projects and a relationship
  • flirting is about making people feel valued
  • need human touch to thrive, keeps immune systems strong
  • people who are happy and feel valued at work results in increased profit
  • introverts need to take care of themselves, take energy from within – they can flirt but it takes energy
  • extroverts thrive in social situations – if your customer is an introvert they may not share your energy

The 8 steps are:

  1. radar – makes you aware of the people around you, takes confidence
  2. target – figuring out who you want to connect with in an organization, who has the real power
  3. move in – show interest, practice your opening line – make eye contact, making the person feel like they have knowledge, makes them feel valuable, interactions become richer because of this
  4. back off a little – the other person may not be ready for the interaction, give the other person space
  5. open up – being honest and laying it out, you have now created a comfort zone, you are also making yourself vulnerable, there might be some back and forward bargaining here
  6. dance – have a little fun, create conversation – lunch, cook together, virtual coffee over Skype, celebration to mark a milestone, dinner club
  7. get real – go through a crisis together, if you have flirted and built a relationship
  8. enjoy – enjoy the relationship
  • have a list of questions to get over the anxiety
  • all good steps for people you manage
  • body language is 93% of communication

Conference Party

The conference party was entertaining as always. Here is me hanging out with Alan Bustamante (who I worked with on the reviews) and the gang from Seapine Software

From Agile 2011

The acrobatic team doing their trampoling indoors was certainly a highlight:

From Agile 2011

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 4 of the conference.

Agile 2011 Day 2 Review

/ Craig Smith / Leave a comment

Agile 2011Day 2 at Agile 2011 in Salt Lake City kicked off with Todd Little advising that the conference this year had 1604 attendees from 43 countries and from 968 submissions we ended up with 268 sessions. Here are my notes.

Keynote – Why Care About Positive Emotions

Barbara Frederickson led with a keynote, but unfortunately I didn’t get to stick around for much of it as I needed to prepare for my session following. Two brief notes I picked up were:

  • positive psychology is about resilience, the closest concept in psychology to agile
  • positive emotions open us – we are more creative and can see more in the periphery, we have more resilience to bounce back, better performance on exams
From Agile 2011

The Speed To Cool: Agile Testing And Building Quality In

The session that I presented with Adrian Smith from Ennova was close to a full audience and was also one of a handful of sessions that was chosen to be recorded. We received lots of great feedback. The slides are available in a separate post. The following pictures were Adrian and I outside the room prior to the session:

From Agile 2011
From Agile 2011

Agile Coaching Self-Assessment – Where Do You Stand on the Competencies?

This session was limited to 32 participants, so it was with good luck and planning that I was able to sit in workshop facilitated by Lyssa Adkins and Michael Spayd.

Coaches are energy shifters and are tuned into the atmosphere of the room. We were invited to walk around the circle and reflect on the following areas:

  • agile-lean practitioner – people who know the tools and practices
  • business mastery – know what the business needs
  • coaching -professional coaching
  • mentoring – help people access what they already know
  • technical mastery – help people create great software
  • transformation mastery – help people change
  • teaching – teach people what we know
  • facilitating – neutral assistance to a group
From Agile 2011

We were then invited to walk around the circle and land at:

  • the area of strength where I am drawn to
  • area of nervousness
  • area that would make the most difference in your role

and we discussed and shared out thoughts with others standing in the same quadrant as well as the rest of the group.

We then reflected on where we stand right now and where we want to stand, before pairing up with another participant for a short one on one session.

Finally we reflected that the coaching stance and catalyst leader are the heart of the wheel.

This was an awesome session and something I look forward to running with some of my colleagues as well as reflecting on my strengths myself.

Refactor Your Wetware

Andy Hunt (of Pragmatic Programmer fame as well as Agile Manifesto signatory) delivered this session based on his latest book Pragmatic Thinking and Learning: Refactor Your Wetware. Here are my notes from the session:

From Agile 2011

Software is written in our heads, that is where the problem starts!

Context patterns neuroplasticity:

  • context – need to not look at a whole object but how it fits into the whole system
  • patterns – in pair programming, the navigator can see patterns because they are not concerned with the symbols and syntax, pattern matching is the key to expertise
  • neuroplasticity – humans can grow new neurons, but not sitting in a cage or a cubicle, work with enlightened people or in a sensory rich environment you will grow new neurons, but if you don’t use parts of your brain it will get rewired

If you study in an artificial environment you will get artificial results.

Skills – the Dreyfus model – rules –> intuition, consider everything –> relevant focus –> detached observer –> part of system

  • novice – no experience, accomplish a goal, want to get it done, don’t know how respond to mistakes, only way to be effective is to have contact-free rules (ie working in a call centre, following a script), need recipes to follow, can’t get much productivity from this level
  • advanced beginner – start trying tasks on your own, don’t want the big picture
  • competent – build conceptual models, troubleshoot on your own
  • proficient – want to understand the big picture, want to understand why, frustrated by oversimplified information, self correct previous poor task performance (retrospectives are a good example of why they need an experienced coach), learn from previous experience, can understand and apply maxims
  • expert – primary source in their field, continually look for better methods, work from intuition, world does not really work on rules it works on experience
  • second order of incompetence – know what you don’t know and admit to it
  • nursing practice shares a lot of similarity to software development – you need to solve problems then and there – need to become outcomes-based, importance of the individual, keep experts in practice, pay based on value added to the company
  • South American monkey trap is like the tool trap – confuse model with reality, de-value traits that cannot be formalised, legislating behaviour that kills autonomy, alienated experienced practitioners, demand for conformity of tools, insensitivity to contextual nuances
  • brain is not a computer – made up of L mode and R mode and we switch between them – spinning girl exercise – creativity and intuition works better in R mode
  • image streaming – pose a problem to yourself, close your eyes for 10 minutes and then for each image that crosses your mind describe it out loud, image it with all five senses and describe it in the present tense
  • free form journalling – first thing in the morning, write three pages long hand, uncensored, don’t skip a day – way to get it out
  • Thomas Edison used to take a nap with a cup of ball bearings and when it dropped he would wake up and write down what he was thinking about
  • whack on the head – look at problems from a different point of view or the opposite – a good tool is the Creative Whack Pack iPhone app
  • ten mental locks – the right answer, that’s not logical, follow the rules, be practical, avoid ambiguity, ……
  • you need to keep track of your ideas, otherwise you will stop having them – everyone has great ideas, fewer keep track of them, even fewer act on them and very few can pull them off
  • carry something with you all the time to record notes – tools like The Pocket Mod or Evernote
  • mind maps
  • we miss things that change slowly – this happens on projects on all the time
  • 90 cognitive biases that people suffer – memory stinks – every read is a write that can create false memories, anchoring, fundamental attribution error, need for closure (agile estimation) – we will take any information even crap information for closure – in agile we want to keep things open ended, exposure effect, Hawthorne effect, relativity
  • ask yourself how you know what you know
  • your age group changes the way we view and understand things
  • some people need auditory, visual, kinetic
  • how to read – SQ3R – survey, question, read, recall, review
  • how to take notes – make a mind map, the sensory of pen and paper is better
  • use a wiki – has a category
  • use affinity mapping with post it notes – Behind Closed Doors describes this in more detail
  • get your ideas out there and blog it, tweet it, present it
Warnings:
  • multitasking – when you get interrupted your memory is blown, constantly checking email is an IQ drop of 10 points, three times as much as smoking a joint!
  • send less email and you will receive less email – pick up phone, walk down the hall
  • choose your tempo for an email conversation
  • don’t context switch – scan queue once, put things into piles, no mental lists (GTD)
  • set cues for task resumption when you get interrupted, leave a quick mote in code or on a notebook – gets back to resuming task much faster
  • set team interruption protocols – most teams say this is the happiest times they have coding
  • second monitor is a 20-30% productivity gains – ALT-TAB in windows is context switchin
Change is hard:
  • start with a plan
  • avoid inaction not errors
  • new habits take time (3-4 weeks)
  • belief is physical
  • take small next steps

This was a great session with so many techniques to look (and re-look at). As a result I think I will also add this book to my reading list (especially given that The Pragmatic Programmer in one of may favourite books). Finally, Andy reminded everybody that the Pragmatic Programmers also have a free magazine that is worth checking out.

After Dark

Tuesday night is typically the night that most of the vendor parties happen. I managed two invites – one to the Atlassian Drink-Up (which unfortunately due to talk preparation I ended up missing) and one to the Celebrate with Rally party which I was able to make for a couple of hours at the end.

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up Day 2 of the conference.

AAFTT Workshop 2011 (Salt Lake City)

/ Craig Smith / 3 Comments

Agile AllianceThe Agile Alliance Functional Testing Tools Workshop (AAFTT), held the day before the Agile 2011 conference in Salt Lake City, was once again one of the highlights of the conference. Organised by Jennita Andrea and Elisabeth Hendrickson, it was as always a wide variety of participants with a passion for testing and testing tools. Here are my notes from the day held on August 7, 2011.

From AAFTT 2011
From AAFTT 2011
From AAFTT 2011


Energy Kickoff & Networking

The session was facilitated by Ainsley Nies, and all of the official session notes are stored on the AAFTT wiki: http://aaftt.agilealliance.org:8080/display/AAFTT/agile2011.

From AAFTT 2011
From AAFTT 2011

We started the day with some networking and sharing some areas of passion. Some of these included:

The theme of the AAFTT is: “Advancing the state of the art and the practice of Acceptance Test Driven Development”.

From AAFTT 2011

Ainsley started walking the circle to explain the day and how open space works, but frankly it make me feel a little dizzy! She went on to explain that Harrison Owen invented the open space idea as he noticed the real content at conferences was the passionate conversations. The rules of open space are:

  • whoever shows up are the right people
  • do not hang on to pre-conceived ideas
  • it starts when it starts
  • discussion does not need to be over until it’s over
  • wherever it happens is the right place
From AAFTT 2011

The law of mobility and responsibility (also known as the law of two feet) is if you are not learning or contributing where you are, go some place where you will. Also, butterflies and bumblebees cross pollinate ideas.

From AAFTT 2011
From AAFTT 2011

Finally, we were warned to be prepared to be surprised.

From AAFTT 2011
From AAFTT 2011

Developers are testers and testers are developers – how do we dissolve and combine the roles 

This was the first session that I attended.

From AAFTT 2011
  • there are two mindsets – offence and defence, testers are defence
  • job is not to find defects but to prevent defects – build quality in
  • define quality and what does it mean to us
  • startups don’t often have the problem – multiple skills required
  • what is the biggest impediment – are we missing the skill
  • there is no team of quality anymore – drive quality through the organization
  • functional testers tend to exploratory test and drive from the UI, technical analysts tend to multiple-skill
  • you need to have a team focus and a product focus
  • don’t start with practices but start with a common vision (eg. zero defects)
  • fear of losing identity if you dissolve roles
  • understanding the historical roles sometimes helps understands why things are the way they are
  • need time – Lisa Crispin mentioned that in her company they were going out of business because the system was not good quality, so management were smart to support the initiative
  • helps if everybody on the team has experienced the entire value chain and needs to understand the value of everybody’s piece of the chain – tendency to optimise the piece of the chain you understand
  • developers often underestimate the precision of data and scenarios and developers underestimate the difficulty of some requests
  • personality issues often get in the way
  • mostly about having the right people – need to let some people go
  • we assign labels to roles which create barriers – break down on teams but need to break down at the HR level
  • payroll is also an issue – need to compensate for people taking on more responsibility
  • need to put queue limits on the testing queue to drive behaviours
  • pairing with developer if they do not understand the scenarios
  • some people have the questioning mindset, some have the practical focus – need both to make sure you ship a quality product
  • mini waterfall problem – long tail feedback loop, change workflow that developer needs to work with tester, avoid lean batching problem
From AAFTT 2011

ATDD Patterns

Jennitta Andrea led this session about the work so far in this space:

Last Mile Tools

Elisabeth Hendricksen led this session on tools that are attempting to solve the problem at the last mile.

From AAFTT 2011
From AAFTT 2011
  • NUnit – Liz Keogh – were using Fitnesse but added another level of complication, wrote a DSL that separates tests to make it easier read, WiPFlash is the automation tool, examples are on the website, can call the fixtures from another testing tool like Fitnesse, capture scenarios on a wiki first to get the best out of the automation tool
From AAFTT 2011
From AAFTT 2011
  • SpecFlow – Christian Hassa – similar to Cucumber, scenarios written as steps that are bound to execution, uses Gherkin parser (this is a plus as a number of tools use this)
  • SpecLog – maps of your product backlog, capture results of collaboration with the business (Jeff Patton’s story maps), data stored in a single file, stories are initially mapped to a feature file but ultimately get linked to a feature tree
  • SpecRun is under development currently, not bound to SpecFlow or test runner/execution, currently Windows only
From AAFTT 2011
  • Limited Red – Joseph Wilk – uses the probability of failure to run those tests first in Cucumber, can then get failure statistics at a feature level, working on a refactoring tool at the moment
  • Relish – publish Cucumber features to a website
From AAFTT 2011
  • The Smallest Federated Wiki – Ward Cunningham – JSON for data scrubbing, thin columns to display well on mobile, refactoring is the number one edit so allow it to drag and drop refactor, fit for any analytic or outcome-oriented endeavor, sponsored by Nike, under very early development, meant to take spreadsheet data to the next level
From AAFTT 2011
From AAFTT 2011

Business Rules

Mary Gorman led this discussion.

From AAFTT 2011
  • business rules – conference website has rules, such as group pack for 5 registrations, what happens to the sixth person, what if someone pulls out
  • need to capture these to describe what our system does
  • business rules manifesto – Mary gives a copy to everyone she work with
  • separation of concerns – a rule is separate from the action which makes the process more brittle and more difficult to test
  • rules are a form of requirements and live beyond the building
  • one process is to extract the rules of a legacy system and then the regression tests – code archaeology
  • the business does not always know the rules of the system or how they got there – rules get added to the system over time or evolve and documentation is unlikely to get updated
  • one insurance company had spent $100 million dollars to bring in a business rule engine, returned investment in two years due to being able to be able to look for conflicting rules
  • put analysis of rules in the hands of developers for way too long
  • simplest part of business rules is having a glossary
  • rules engine enables our rules in productions, and use examples to ensure the engine works correctly
  • testing could look like this – given this data when these rules are applied then I expect this output
  • you need both rules and examples to test them – you need enough examples for now, need to be different paths, decision points, infliction points rather than different values
  • examples are not as expressive as arithmetic, but they are not as understandable
  • lots of rules that we do not think of as business rules because they are baked into the process eg. security access, database schemas
  • “business logic is not” (Martin Fowler)
  • you can’t read English as if it were rules, so we need to use examples
  • the worst systems are the ones that do not have a manual override, humans are usually the best at determining this
  • lots of business rules change due to jurisdiction
  • something will always fall to the bottom – rules need to be valued on risk and value – where is the tipping rule
  • rules are the expression of intent
  • Mars issue – crashed, six week window too costly to fix
  • guts to keep it simple – reporting system (Ward Cunningham) – resisted urge to put in a formula system, wait for requests from users, got 6 requests, sold system based on simplicity of the system
From AAFTT 2011
From AAFTT 2011

Other Sessions

As with any conference, there are always sessions you would have liked to have got along to.

Richard Lawrence led a discussion on Static Analysis for Gherkin which turned into a discussion on design patterns for Cucumber.

From AAFTT 2011
From AAFTT 2011
From AAFTT 2011

George Dinwiddie led a discussion about conversations between roles:

From AAFTT 2011
From AAFTT 2011
From AAFTT 2011

My mate Jason Montague led a session on Building Conditions Conducive for ATDD Adoption.

From AAFTT 2011
From AAFTT 2011

Closing Circle

We shared some takeaways in the closing circle, he were some that stood out at me:

From AAFTT 2011
  • issues with dealing of people was a theme
  • what are good ways to express a large amount of test data
  • challenge to get corporations over the hump to release data, plus have good tests and examples around the rules
  • testing needs to be a nation, not just a community
  • it’s time we got more respect in our organisations, it’s time we show more respect to those we work with
  • teams need to dependent on the production of the build
  • federated wikis could help solve the test ownership problem

As for me, my comment was the day had renewed my energy again. ATDD is hard, and as a community we need to try harder.

Podcast

Finally, I recorded a short audio podcast for The Agile Revolution wrapping up AAFTT.

Agile Australia 2011 Day 2 Review

/ Craig Smith / Leave a comment

Agile Australia 2011Day 2 at Agile Australia 2011 and another jam packed day. Here are my notes from the sessions I attended.

Keynote – Elevating the Agile Community of Thinkers 

Jean Tabaka presented this keynote, barefoot, and her slides are available here.

From Agile Australia 2011
  • “A Community of Thinkers” – drafted by Liz Keogh, Jean Tabaka and Eric Willeke
  • need to apply energy to learning rather than frustration – need to subscribe to the art of the possible
  • it is no longer acceptable in the 21st century to administer in the business, we need to create and provide innovative communities
  • fearful that in the agile community that we are in conflict mode but rather we should seeking enquiry and insights and learning from each other, such as we do in an daily standup
  • to be the best we can be every day, we need to inspire insights from the entire team – the definition of a good daily standup
  • Patrick Lencioni’s “The Five Dysfunctions of a Team” also apply to community
  • “vulnerability can create great workplaces and innovation” (Dr. Brene Brown)
  • our greatest wisdom is every insight in the room and is only as good as the quietest voice in the room – we have to lower the bar
  • in a command and control environment we lose wisdom and lower their IQs
  • in global teams you need to invite their wisdom in anyway possible – secret to distributed teams
  • Kathy Sierra – magic for Creating Passionate Users
  • drop outs give up when they believe they suck
  • amateurs learn how to do it and then become complacent
  • experts – keep pushing themselves to find a better way
  • in agile need to believe past both the “this sucks” and the “kick ass” threshold
  • we need active participants in our communities, rather than passive participants
  • Linchpin (Seth Godin) – being a genius self, being part of community means hard work
  • Principles of Product Development Flow (Donald Reinertsen) – this and Linchpin are Jean’s most dog-eared books
  • empathy mapping (gogamestorm.com) – look at your community and what are they thinking, hearing, saying, doing, seeing
  • use a wall of appreciation as well as a wall of break up letters to improve community and move past blockers
  • writing love letters to agile – interesting…
  • to be a linchpin your message needs to be accessible (charm), need to create talent around your message and have perseverance
  • “Drive” (Dan Pink) – autonomy (able to bring your genius self to work), mastery and purpose (a big hairy goal) – you will be creative
  • need to design a life and not a plan – how can we grow and be emergent in what we do, plans stagnate and stagnation kills
  • “Preferred Futuring” (Lawrence Lippitt) – create concrete wishes on where we want to be, need to bring this more into our workplaces
  • need to move – tell -> sell -> test -> consult to co-creation
  • find your mentor, or become that person
  • think like a genius – creating models of what might be true
  • example of Rally using lino to organize an open space – awesome
  • Jean not wearing shoes in this keynote is going out of your comfort zone – onedaywithoutshoes.com

Panel – Software Engineering is a Dead Craft

I was honoured to be given the opportunity to moderate this panel, consisting of Martin Fowler, Kane Mar and Paul King. My opening comments were as follows:

Software Engineering is defined by the IEEE is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.

This led me to then get a definitive definition of engineering, which is loosely defined by a number of the leading engineering councils worldwide as being the discipline of acquiring and applying scientific knowledge, mathematics and ingenuity to design and build solutions that safely improve the lives of people.

Software engineering as a term has been around since the early 1960s, and, as Rob Thomsett pointed out in his keynote yesterday, was popularized when NATO hosted a conference to address the problems of software development. In there report, they particularly point out that the phrase software engineering was deliberately chosen to be provocative. So for the last 50 years, practitioners everywhere have been debating software engineering, from the software crisis that made developing software into a career, through to Fred Brooks coining the No Silver Bullet argument that no individual technology would make a 10 fold improvement in productivity in 10 years, through object oriented programming and the rise of XP and agile.

So what is software engineering. Is it an engineering practice that is dead? Is it a craft or an art form? Or is it both dead and a craft?

Martin Fowler is the Chief Scientist at Thoughtworks, author of many books on software development and a signatory to the agile manifesto.

Kane Mar is the President of Scrumology, and has been a developer and coach in the software industry for 20 years.

Paul King is the Director of ASERT and has been developing, training and contributing to the software development field for nearly 20 years, and is an active contributor to a number of open source projects including, most notably, Groovy.

My questions started as follows:

Martin – when you do any Google search on software engineering, every second link seems to point back to your website and any number of articles you have written on this subject over a number of years. You indicated your position is that the engineering metaphor has done our profession damage…

Kane – you listed your point of view on the topic is that the paradigm has come and gone and that perhaps software should be viewed as an ecosystem…

Paul – your viewpoint is listed as probably a little more conservative and that continuous learning is important…

The time flew by and I did not get to take anywhere near the number of questions I would have liked from the audience. The highlight was a question from the audience from Phil Abernathy who asked the panel if perhaps we should term what comes out of a number of projects as “crapmanship”.

Agile and Enterprise Architecture are not Mutually Exclusive

I had the pleasure of introducing Rebecca Parsons from ThoughtWorks, her slides (in all their Comic Sans MS glory) are available here.

From Agile Australia 2011
  • architects need to depress their ego and pair on critical stories and calm their concerns
  • some architects believe their job is to stifle any innovation in the development team, but they a disappointed that the team is not innovating
  • the IDE of enterprise architects has been PowerPoint for years
  • developers must code in a box, architects must worry about a bigger box
  • it is hard for enterprise architects to talk to every developer, so documents from high are standing operating procedure, unfortunately they get ignored because the context is hidden
  • use stories for technical requirements – architect communicates his requirements via a technical story and the development team responds with this is what it is going to take – ensures that the value is articulated
  • need architects to articulate their requirements based on acceptance tests
  • harvest components and talk in the community – ask who was the last person to integrate with this component and talk to them
  • development team should be focussed on delivery of their project, agile is the engine and architects need to use this engine

The Speed to Cool: Valuing Testing and Quality in Agile Teams

The session I presented got a good turnout, and plenty of questions afterwards as well as some follow-up emails.  The slides are available in a separate post as well as here.

From Agile Australia 2011

Rolling Out ‘Agile principles’ in a Global Organisation – A Continuous Journey

I introduced Sascha Ragtschaa from Computershare, his slides are available here.

From Agile Australia 2011

A Rogue’s Take on the 4 ‘C’s: Culture Change Costs Currency

I had the pleasure of both introducing and being a live prop (the dragon representing the (large) organisation) in this presentation by my good friend and colleague Renee Troughton from Suncorp. Her slides are available here.

From Agile Australia 2011
From Agile Australia 2011

Keynote – Software development in the 21st Century

Martin Fowler delivered his now famous 3 short keynotes.

From Agile Australia 2011

Non-Determinism and Testing

  • non-determinism – intermittent fails, we don’t know if something is going to succeed or fail – also called a useless test
  • non-deterministic tests infect the whole system – need to quarantine these tests to stop them bringing down the while suite – often caused by interference between tests
  • you can track dependencies or you can use isolation (preferred method)
  • tests should clean up after themselves and leave the world the way they found it but other tests rely on this happening (and hard to track failures when they occur) or start all tests with a clean slate (but it can take a long time)
  • asynchrony – can use a bare sleep but you never know how long to sleep for, could use a polling loop or a callback
  • remote services – don’t talk to them as part of the test, use a test double

Value of Software Design

  • this was a repeat session from last year where Martin did his famous Uncle Bob Martin rant. A highlight for me was in his example he used Nigel Dalton as good code example and me as a bad code example.

Agile Manifesto: 10 years later

  • we know the approach works and we need to use it more and find the boundaries
  • XP was the dominant strain at the time – has appeal of its values and principles as well as its practices like test driven development, etc…
  • many of the original people are unhappy – the core ideas have not moved as fast as the hype (semantic diffusion) and the rollout process is very long running
  • if you say you don’t care about agile you are saying you are happy with flipping the principles back again
  • do not treat stories as one-way traffic, the value is in conversation
  • as software developers we need to ask ourselves if we are making the world a better place
  • mundane work and the little things often make the world a better place

Conference Retrospective

I led a conference retrospective after the post-conference drinks. For those who stuck around, we had a good discussion on what was good and what we could do better next year.

What Was Great

From Agile Australia 2011
From Agile Australia 2011

How Can We Improve

From Agile Australia 2011
From Agile Australia 2011

New Ideas

From Agile Australia 2011
From Agile Australia 2011

Other Stuff

There have been some other wrap-up and retrospectives written about the conference including:

Also, a couple of mentions for some of my other friends and colleagues who presented on day 2 but due to my other commitments I could not attend their sessions.

Jonathan Coleman, Steve Jenkins and Phil Abernathy all did lightning talks which were all well received.

Nicholas Muldoon from Atlassian delivered a talk called “Be The Change You Seek”, his slides are available here.

Paul King (who I have presented with many times previously) delivered a workshop called “Leveraging Emerging Technologies in Agile Teams”, his slides are available here.

OSDC 2009 Day 2 Wrapup

/ Craig Smith / 1 Comment

Day 2 of the OSDC conference, one talk delivered today with Paul King on Using Groovy for Testing. The following are my notes from the sessions that I attended.

Keynote: Simplicity

Marty Pauley delivered the keynote, my notes are as follows:

  • good code is easy to read, beautiful (aesthetically pleasing), useful
  • evil code is difficult to read, ugly, but it is still useful (otherwise you would have no code!) because unfortunately it is still in use
  • good code should be fast, concise, advanced, maintainable
  • “Simplicity is the ultimate sophistication” – Leonardo Da Vinci
  • comments are an indicator that you’re code is crap, documentation and comments are not the same (documentation is useful), ironic that some languages put documentation in comments (eg. JavaDoc)
  • always out your scripts in a module, makes it easy to read (the comment was made in relation to Perl) and makes it easier to test (one script that calls one module, that can then call other modules)
  • Google is good example of simple (as compared to Excite and Yahoo! at the time) – search engines started complicated and became simple
  • Example of simple first is that Americans used the Space Pen in space (highly engineered pen that would work on all surfaces and work in space), but when they asked the Russians what they used, it was a pencil
  • “Java was designed for stupid people! – was designed because it was deemed to hard to write code in C”
  • look outside your current toolset, we all have problems in common

How to get Rails Web Applications Accepted in Industry

Harley Mackenzie presented this talk, my notes are as follows:

  • why Ruby? – expressive language, object oriented as everything is an object in Ruby (lends itself to good, readable, maintainable code), dynamic allows to delviver scripts quickly and maintainable
  • hard to find Ruby people? – many recruiters do not understand the roles they are recruiting for, Chuck Jones (of Warner Brothers cartoon fame) looked for artists knowing he could train them to animate, the same goes for quality developers
  • open source – lower initial cost, source will never disappear as will always be around in some way, don’t emphasise the FREE but the FREEDOM, dynamic languages you always have the source (not compiled)
  • efficient – productivity important to industry
  • elegant – write easy, maintainable code
  • reliable – “testing to oblivion approach”, everything has tests, commercial environments do not value testing, all say it is a good idea but will not pay for it
  • expressive – easy to understand what the code is doing
  • why is Rails not adopted? – management are risk averse (don’t want to go outside the Microsoft norm), corporate IT motivated by fear and uncertainity (like to do things the way they are always done), loss of control (don’t understand and don’t like when you know about things they don’t), outsourced IT providers (only in it to make a buck so resistance to change)
  • solutions and adapt (know what you can change and what you can’t)
  • demonstrate – give them a VM (“take the puppy home for the weekend), find the champion
  • cloud solutions – if you can’t deal with anorganisation and their infrastructure, bypass it (use Amazon or similar)
  • draw the line – sometimes you have to walk away than comprimise (figure out where the line is), usually can deal with server operating system, web server and database but not the language it can be written in

Open Source Web Apps in Azure

Jorke Odolphi delivered this session, my notes are as follows:

  • software as a service (SaaS) – multi-tenant, pay as you go
  • platform as a service (PaaS) – applicationn frameworks, languages
  • infrastructure as a service (IaaS) – pay as you go, scale (like Amazon EC2, GoGrid)
  • Windows Azure is an operating system in the cloud, where you run applications, designed to scale
  • lots of servers sitting in shipping containers (2,000 servers per container, 7 hours to get up and running after delivered) with VM’s running Windows (called the Fabric)
  • components – web role (front end facing, static content, ASP.NET 3.5, WCF, Fast CGI applications such as Perl, http(s) inbound), worker role (like a Windows service), storage (blobs, tables and queues)
  • running PHP in Azure – Eclipse tooling available (WindowsAzure4E)
  • MySQL in Azure – run as a worker role (configure ports and storage)
  • Tomcat running in the Azzure Cloud (http://oss.cloudapp.net/)
  • No environment yet in Australia, but Singapore coming soon, pricing

Desktop Applications for Web Developers

Ben Balbo presented this session, my notes are as follows:

  • cloud issues – network outages, working offline, server outage, application failure affects everyone, access/ownership of data, dependence on third party to fix bugs
  • Google Desktop Gadgets, Adobe Air, Windows 7 – just HTML, all the information stored in the gadget or via a web service
  • Mozilla Raindrop – Mozilla’s reaction to Google Wave, pre-alpa, a local web service
  • WordPress + Google Gears
  • iPhone applications
  • XUL – XML User Interface language from Mozilla, load any interface around Firefox (use Firefox as a framework)

Using Groovy for Testing

Presentation I gave with Paul King, and was an interesting experience on how to break down a 3 hour presentation to a 30 minute talk (which we started about 20 minutes prior to the talk commencing)!

Business, Law, Open Source

Brendan Scott presented this talk and these are my notes from the session:

  • each decision you make limits your subsequent decisions
  • Starting a business has effect on how easy it be to sell down the track (setting up within a corporate vehicle) – selling of shares make this easy as the legal person transfers. Most businesses are setup where the owner owns all the assets and personally signs up to all the contracts such as phones where their name is on the contract (makes it hard to transfer later on)
  • stay away from partnership (and the use of the word partner)
  • Pov Ray had pre-open source licencing, wanted to sue someone who was bundling it and selling it – needed copyright ownership to sue but had to go and find all of the contributors first
  • code consents in case somebody takes code and uses it in breach – keep records of who, what, when
  • IP Ownership – once you have transferred rights, it is very difficult to recover these rights, you need to get legal advice early
  • dispute resolution – usually because people not speaking to each others, lawyer can help you identify issues, send the nasty letters, courts look favourably if you have tried to sort out the issue
  • negotiations – lawyers familiar with the lines of argument
  • legal arcana – knowing the legal secrets and finding holes in contracts, etc…
  • copyright – owned by employee unless agreed otherwise
  • don’t lie about your products and services (Part V 52 Trade Practices Act)
  • Part V, Dvision 2 Trade Practices Act – don’t exclude warranties, limit recourse to repair or replace, it is illegal to exclude warranties

Lightning Talks

An extended session of lightning talks. here are the notes:

Make my PHP 66 Times Faster

  • slow code read in a really big library everytime it is run
  • idea is to make a socket call and run off the server, loading only once

Something About Cars

  • entertaining comparison of programming languages to cars

The Coming Programming Language Crisis

  • entertaining look at new programming langauges, recruiting for the Australian LOLCODE Developers network! (see http://lolcode.com/)

OSDC – Open Source Developers Club

  • parent organisation for the conference
  • like meetings (found about every third session, people attend a session that is not their usual language)

Hosting Web Sites In The Cloud

  • created Grocery Choice, wanted something that had scale initially but assumed would not need it going forward
  • Amazon EC2 – virtual machine farm, upload your VM to the cloud (takes about 3 hours)
  • using commercial, licenced server so limited to CPU’s that coule be run
  • can move your instance onto a larger virtual machine
  • pay as you go, for what you use

Geography, Databases & Government

Netrek

Phoebe’s Netbook

  • Phoebe is 4, has an original eePC
  • the distribution is very easy for children
  • TuxPaint and other programs in Linux that are good for kids

GMT (Generic Mapping Tools)

  • set of command line tools
  • pscoast – will show a map, can then map cyclones as they move down the coast

Byte code optimisation using Promise

Open Source Licencing vs Microsoft

UpStarta.biz

  • starting a business with no money
  • do something disruptive – is a potential client trying to solve a problem that your product addresses
  • low-end disruption – easier way of doing something that already exists (eg. MySQL vs Oracle)
  • new-market disruption

Handy Python Functions

  • if building libraries, pleause use doc tags!

Katoomba

  • open source SMS gateway
  • written in Ruby
  • will be released shortly

Trosnoth

  • written in Python using pygame
  • open source, GPL
  • team based, strategy game

Google Wave Bots

  • Wikifiy
  • Piratify
  • Flippy

Agile 2009 Day 3 Review

/ Craig Smith / Leave a comment

Agile 2009One of the problems of presenting a double session at Agile 2009 is that miss out on a bunch of the great talks that are going on at the conference at the same time. Added to that, the (very) last minute preparations that I was doing with Paul King meant that I only got to sit in on one session (apart from our own).

Automated Deployment with Maven & Friends – Going The Whole Nine Yards

This was a good overview by John Smart of using Maven as a build tool as well as how you might use tools such as Cargo and Liquibase and scripting languages like Groovy to automate your deployment process. I was hoping John would have the silver bullet to linking the Jira release button to a deployment script, however it appears the only way of doing this still is via a plugin for Bamboo.

How To Make Your Testing More Groovy

The session I presented with Paul King, we got a reasonable turnout for a technical double session and the session feedback forms were overwhelmingly positive. The slides are available in a separate post.

Agile 2009 Groovy Testing Paul King
Agile 2009 Groovy Testing Craig Smith

Dinner with Manning & John Hancock

I had the pleasure of having dinner with Todd Green from Manning, Greg Smith (co-author of Becoming Agile) and Paul King (co-author of Groovy In Action). As the technical proof-reader for Becoming Agile and knowing Paul King, I also got an invite for traditional deep-dish Chicago pizza.

Afterwards, Paul and I treked up the “Magnificent Mile” and up 95 floors to the Signature Room in the John Hancock Center (Chicago’s fourth tallest building but best observation deck according to the locals). The views were amazing (the pictures don’t do justice to the city lights that carry on into the distance!)

Chicago John Hancock Signature Room

AAFTT Workshop 2009 (Chicago)

/ Craig Smith / 3 Comments

Agile AllianceI had the great pleasure to attend the Agile Alliance Functional Testing Tools (AAFTT) workshop on the Sunday before the Agile 2009 conference in Chicago, and share discussion with some of the best minds in the testing community from around the world.

The location was right across the road from the Willis Tower (better known by its previous name, the Sears Tower). Some of the notable attendees amongst many others included:

There were at least 4 tracks to choose from, these are the notes from the ones I participated in.

Screencasting

Small group discussion led by Jason Huggins about a different way of thinking about test artefacts (basically producing an iPhone commercial)

Photo 3 of 4 from #agile2009 in Chicago at the pre-conference... on Twitpic

  • the Rails screencast sold Rails because it sold the idea and then the product sold itself
  • now, with YouTube, etc, we have the tools available
  • used to be RTFM, not it is WTFV
  • ideal is to produce automated tests like the iPhone commercial, instead of a test report
  • use the “dailies” concept, like in the movies
  • perhaps the movie should be at a feature level, because the video should be interesting
  • best suited for happy path testing, is a way to secure project funding and money, remember that the iPhone commercial does not show the AT&T network being down
  • there is a separation between pre-project and during testing
  • tools currently exist, including the Castanaut DSL
  • part of the offering of Sauce Labs, currently recording Selenium tests
  • from the command line utility vnc2swf, created an API called Castro
  • at the moment you need to clean up the screens that are recorded
  • the advantage, being VNC, is that you can use all sorts of hardware, including the iPhone
  • suggest that you use something like uLimit to stop runaway videos, especially when being run in an automated test, to limit the size of the directory or the length of the video
  • suggest make a rule that no test is longer than five minutes
  • given the current tools are written in Python, DocTest is good for testing

Lightning Talks on Tools

I came in mid-way through this session, but caught some of the tools being discussed at the end

  • some tools are too hard to get passed the basic level, but quick to setup
  • tests are procedural, engineers tend to over-engineer

Robot IDE (RIDE)

  • most tools have a basic vocabulary to overcome
  • IDE is worth looking at
  • Robot has a Selenium plugin, but it is easy to write your own framework

Twist

  • specify tests as requirements, looks like a document, stored as text, write whatever you want
  • refactoring support as a first level concept
  • out of the box support for Selenium and Frankenstein (Swing)
  • write acceptance test – brown shows not implemented, allows developer to know what to implement, turns blue when done
  • refactoring concept “rephrase”
  • supports business rule tables (ie. Fitnesse for data driven tests)
  • support to mark a test as manual and generate the same reports
  • commercial software, licenced in packs
  • plugins to Eclipse, but don’t need to be familiar with this unless you are developing the automation

WebDriver

  • been around for three years

UltiFit

  • Ultimate Software, internal currently, allows to select Fitnesse tests, setup and teardown, close browser windows, nice GUI, etc…
  • uses TestRunner under the covers

SWAT

  • been around for two years, more traction now that Lisa Crispin works for Ultimate Software
  • simple editor for SWAT (& somewhat Fitnesse)
  • has a database access editor
  • uses Fitnesse syntax
  • there is a recorder, only good for teaching, people get lazy and don’t refactor
  • can take screenshots, borrowed from WatiN
  • can’t run SWAT when Fitnesse is running as a server
  • SWAT is a C# library at its core
  • can run macros, tests from other tests
  • run script – write script (eg. JavaScript) to help things that are hard to test

High Performance Browser Testing / Selenium

Jason Huggins led this conversation which was more a roundtable debate than anything else. The group discussed how we can get tests running quicker and reduce feedback times considerably.

This discussion led to a couple of the quotes of the workshop from Jason Huggins:

  • “Selenium IDE is the place to start with Selenium, but it is Selenium on training wheels”
  • “Record/playback testing tools should be clearly labeled as “training wheels”
  • “What to do with the Selenium IDE, no self respecting developer will use it.” Thinking of renaming the IDE to Selenium Trainer.
  • Amazing how many people in the testing community are red, green colour blind”

When Can / Do You Automate Too Much?

This started as a discussion on testing led by Brandon Carlson…

  • get your business people to write the tests – they will understand how hard it is, have seen outcome that amount of scope reduced because they have to do the work

…but ended up as a great discussion on agile approaches and rollout, discussing a number of war stories led by Dana Wells and Jason Montague from Wells Fargo

  • still early in their agile deployment
  • wish to emulate some of the good work done by some of the early agile teams
  • estimate in NUTs (Nebulus Units of Time)

Miscellaneous and Other Links

Some other miscellaenous observations from the workshop:

  • a number of sessions were recorded
  • of those using Windows laptops, a large percentage were running Google Chrome
  • Wikispaces is good to setup a quick wiki

A number of posts about the workshop have been posted since including:

And you can view the photos that I took from the event at: http://www.flickr.com/photos/33840476@N06/sets/72157622521200928/