Start spreading the news: CAST keynote in NYC

I’m excited to announce that I’ll be giving a keynote at CAST 2014 this August in New York City! The title of my talk is “Scaling up with Embedded Testing”.

The theme of CAST this year is “The Art and Science of testing” and the speaker lineup looks fantastic. I’m really looking forward to spending several days in the company of some amazing and inspiring people.

If you’d like to join us in for CAST in New York City this August, register here. See you there!

2 thoughts on “Start spreading the news: CAST keynote in NYC

  1. Trish,

    First, I want to say I really enjoyed your insight into the world of embedded testing at CAST. While I was aware of the concept I have to say this was the first time I heard a convincing argument for it, or a case study highlighting its success.

    A number of folks in the audience seemed to be concerned about the technical skills needed for testers to transition into more of a development or hybrid role. I thought it was interesting that nobody talked about the mindset shift.

    The way I look at it, its like an hourglass – the developer takes a user story, and from all of the possible ways a feature could be imagined and implemented, and with some logic, decides on one path forward and one way to create it.

    Then, the developer passes off the discrete unit of development work and then the tester’s job is to be imaginative and think of ALL possible ways an end user could use and experience the system.

    To me, it seems like for a developer to succeed as a tester, or a tester to succeed as a developer, one would need to be able to embrace the mindset of the other. To me, skills are relatively straightforward to transfer, but a mindset is not so cut and dried.

    I’d be interested to know you or anyone else’s thoughts, or if I am missing the point here.

    Look forward to keeping up with your blog and hopefully hearing you speak again in the future!


  2. Doug,

    I can see where you are frustrated by not being provided a golden rule of automation coverage – but a lot of those variables related to the extent or degree of automated testing coverage needed in a sprint will vary. I think some (of many more) things you would want to consider are:

    -Level of unit testing completed – how well is the application tested by the developer, and how much do you trust that developer to do testing? At the CAST show last week, Trish Khoo ( talked about agile groups she worked in at google where all of the testing was performed by the developers, and there were no dedicated testing resources

    -Maturity of the application – while we can’t assume that more mature applications will never have features break, we know that the probability is likely less.

    -Development “nimbleness” – if something breaks, how quickly can we fix it? Do we do builds frequently? For example, at my company, many of our customers are in the cloud, so we can deploy a hot fix if something goes wrong. However, if this happens with one of our On-Premise clients, the path to resolving the issue is much more difficult. Therefore, much more automated testing is needed to confirm the stability of the on-premise build.

    -Risk of Defects found in production – For someone like Facebook, a bug found in production has lesser impact – for the most part people do not rely on Facebook to perform any critical activities. However, for someone making software that controls surgical instruments, the same cannot be said.

    There are many, many more factors to contribute – I would be interested to hear what others think are import factors to weigh when making this decision! But at the end of the day, I think agile will require that you drop the dogma associated with waterfall of boilerplate test plans, test case formats, etc. and think at a higher level about what the mission of your testing truly is.


Comments are closed.