The Skeptics Dilemma

January 27th, 2012 by Alan Page 3 comments »

For testers, being skeptical is generally a good thing. When someone says, “Our application doesn’t have any reliability errors”, I, for one, am skeptical. I’ll poke and prod and (usually) find something they haven’t thought about. There’s power in skepticism. Last year, I led a team of testers in performing code reviews of production code. My hypothesis was, that while developers perform code reviews thinking, “Does the code do what it’s supposed to do”, testers think, “In what conditions will the code not do what its supposed to do. You can insert the comment about testers being pessimistic (or overly pessimistic) here, but in general, the tester mindset is to question statements that seem…well, questionable.

But it’s easy to go overboard with skepticism. Time and time again, I hear good testers apply their skepticism broadly and liberally. Some (paraphrased) quotes I’ve heard recently include:

  • “Model-based testing is interesting, but it doesn’t work in a lot of places”
  • “I’m skeptical of static analysis tools – sometimes they have false positives”
  • “Metrics are evil, because someone may use them to measure people”

I agree whole heartedly with each of these quotes. However, I worry that folks are throwing the baby out with the bathwater. Model-based testing (just an example), is a wonderful test design technique for stateful test problems. Although occasionally someone will screw up the value of MBT by claiming that it’s the only test approach you’re ever going to need, it’s just another technique (and the perfect technique given the proper context). Static analysis tools are also awesome, but aren’t perfect It’s good to measure some things too, but sure, one can screw it up.

I’m trying to think of anything in my life that works perfectly in every situation, but I’m coming up empty. I run into situations nearly every day where someone has a good idea that will obviously work most of the time – but not always. Given these situations, we could just send them back to the drawing board telling them, “I’m skeptical of your approach, because it won’t work in situation z”, but it’s probably a better idea to have a conversation about the limitations, understand where and when the approach may fail, and discuss mitigation or workarounds. Instead of throwing out the idea of running static analysis tools because of the potential false positives, discuss the false positive problem. Find out what causes them. Tweak the configuration. Do whatever you need to do to ensure the value of the approach.

Over the years, I’ve found value in some pretty stupid approaches. It seems that we should be able to find more value from some the ideas frequently discounted.

Even if we’re skeptical.

In search of code quality

January 19th, 2012 by Alan Page 1 comment »

I’ve been thinking recently about what ‘code quality’ and what the phrase means. How does someone identify the difference between low quality code and high quality code (or medium quality code)?

In my quest for knowledge, I discovered a few interesting things.

I discovered the Spinellis book, Code Quality: The Open Source Perspective. I haven’t read this yet, but I ordered it, and looks like it will be interesting.

I found an article on coupling metrics on the IBM site. The reading here was good, as I discovered they have a series of articles on code quality.

I found a few references to analysis tools for JavaScript (some lint-like stuff)

Over in the high brow world of the linkedin groups, I saw a bunch of people referencing code coverage as an indicator of code quality.

Nothing earth shattering, but some good information, and enough to get me thinking about what *I* think code quality is – and what it is not. I think it may be impossible to define code quality in a way that everyone will agree with – but that doesn’t mean I shouldn’t try.

We have some metrics that can give us an idea about code quality. Quality code doesn’t have any compiler warnings (ideally at the highest warning level), and it’s clean from static analysis errors and warnings. Complexity metrics such as cyclomatic complexity (basically, the number of paths through a function), or dependency metrics such as fan-in and fan-out can also be indicators of code quality.

But – let’s make it clear that while I’m a (big) fan of those indicators, that’s all they are. Running clean with static analysis tools does nothing to ensure code quality – or product quality either (I ranted a bit about this a few months back). In fact, I guarantee you that I could write (or show you) a piece of software that compiles with the highest warning levels set and passes any static analysis tool with flying colors…that still sucks. 

One thing definitely unrelated to code quality is code coverage. All code coverage tells you is what percentage of your code you haven’t tested at all. If you squint and have a few drinks, you can pretend a little that high coverage rates from unit tests prove code quality…but once you sober up you’ll realize that all you have are unit tests that exercise some amount of your code.

But we can go beyond code analysis tools. Testability (can I observe and control program flow), and Maintainability (“Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” ref) are critical to code quality. Given a good reviewer, Thom Holwerda’s comic is also spot on – the only valid measurement of code quality is WTF’s per minute.

As I think about this, I find my mind wandering back to Pirsig. Quality and care are two different ways of looking at the same thing. Quality comes from care, so perhaps what I want to measure is the care put into coding. The fact that a developer wanted to compile at a higher warning level or turn on more static analysis checks, or that they cared enough to get the testers input on testability, or a peer’s advice on maintainability may be the best ways to measure code quality of all.

So now, perhaps, I’m in search of a way to discover and measure care.

My new world

January 15th, 2012 by Alan Page No comments »

Twenty-twelve has been a heck of a year so far. The day job has been keeping me swamped, but the work, the challenges, and the scope feel perfect – I’m having a great time, and I couldn’t ask for anything more in a job.

Historically, most of my blog posts come from experiences or inspiration from my day job (despite those who seem to think that every snide comment I make is about them, my snide comments are almost entirely about people I work with). While I’m sure that will continue to be the case, I’m still pretty deep in ramp up mode, and it turns out that the bulk of the work I need to do right now is solving a variety of test infrastructure and code issues. While I find this sort of work exciting to perform, I find it dreadfully boring to write about (apologies to all those who enjoy writing about these things).

But I do enjoy writing, and even as I write this trivial little blurb (a blurb that will turn into a blog post in about five minutes), I realize that I have a huge backlog of items not contrived from my day-to-day work that I can draw from in order to satisfy my need to write and share a few times a week.

Meanwhile, some chunks of my work are about things that I can’t blog about. In some ways, those are the most exciting. I have plans to share some of my thoughts on this when it’s appropriate, and I think it will be an interesting exercise (and hopefully, interesting reading when I can share). We’ll see what happens.

2011 year end roundup

December 23rd, 2011 by Alan Page 2 comments »

I’ve been on vacation (whatever that means) for almost a week now, and don’t plan to post again until 2012. To help fill in the break (and for anyone new to my blog), I thought I’d share some stats and popular posts from the last twelve months.

I wrote 60 blog entries in 2011. Some of the more popular posts (in no particular order) were:

I did a bit of speaking in 2011 (although, as usual, more than I planned). I was a pnsqc, at Intel in Israel, and at the Swiss and German Testing Day conferences. I also attended the second Writing About Testing conference (and had a great time).

Next year, I’m trying (again) to speak and travel less, blog about the same amount, and keep having fun working on the Xbox team. For everyone who’s read or posted a comment, thank you for supporting my silly addiction to writing. I hope I’ve given you something to think (or complain) about.

Best wishes for the holidays and 2012.

The Ballad of the Senior Tester

December 16th, 2011 by Alan Page 1 comment »

I’m a Senior Tester, don’t you know

Been testing software for five years or so

I got bills to pay and need a better job…

Looking for jobs with ‘Senior’ in the name

Gotta’s admit, they’re all pretty lame

Looks like I’m over-qualified…

Someone (non-Microsoft) asked me recently what a “Senior Tester” does. I told them that I knew in the context of Microsoft, but really had no idea if the term meant anything in the industry. After a quick (and painful) trip to a jobs website, I was able to confirm that the ‘Senior’ title doesn’t carry a lot of weight. Consider some of these quotes – all from positions advertised as “Senior Tester”, or “Senior QA Tester (on a side note, wtf is a QA Tester?):

  • With minimal direction writes scripts and executes test cases during functional/system/integration testing.
  • Modify existing test plans and testing information to correct errors, to adapt to new test scenarios, upgraded interfaces and performance enhancements.
  • Monitor bug resolution efforts and track successes.
  • Participates in analysis and design walkthroughs, as well as team meetings
  • The Senior Tester will work extensively with the Test Lead to provide test estimates
  • Complete knowledge of QA Best Practices and the full Testing SDLC

 

Let me rant on the last bullet point first. Actually, never mind – anything I can say is something you’ve probably already thought.

As for the first five bullet points, are those really considered “Senior” activities? I was surprised that being able to cross the street by themselves or washing their hands after using the bathroom weren’t required attributes. Then again, I’ve been sheltered in the world of Microsoft for the past 17 years (and as a noob in a startup for 2 years before that), so my world view of testing has limitations.

So, let me talk about what I do know. Here at the evil empire, we have standard titles for all roles (more details on test titles are here). As I mentioned in the link (which I know you haven’t read yet), we have a “Senior SDET” title at MS, and this is where we expect testers to exhibit some leadership skills (they learn how to find the bathroom by themselves at a much lower level). To be clear, leadership does not mean management. ‘Senior’ is the minimum level where we like people (who are interested) to move into management roles, but we have hundreds of non-managers at the Senior level (about 8% of the total test population if you’re curious).

My random search for Senior test roles wasn’t entirely in vain. Consider the following:

  • Experience with leading testing efforts on integrated teams and developing and implementing sound testing methodologies
  • This is a senior role that includes evaluating existing automated testing process and recommending improvements

Now those seem a little better – now the role requires some leadership and decision making, so let’s look a bit closer at these a few other attributes I expect to see in Senior testers at MS.

  • Decision Making – senior testers make confident decisions, and do not rely on consensus for making (most) decisions.
  • Influence – Dwight Eisenhower said, “Leadership is the art of getting someone else to do something you want done because he wants to do it.”  Senior testers make their team better through influence rather than mandates – they are the point guard of the test team.
  • Network – senior testers use their network to find answers (or knowledge), and connect their teammates with their network (i.e. tester matchmaking)
  • Credibility – senior testers don’t proclaim they’re a leader, and no title demands respect. Leaders know that respect as a leader comes through establishing credibility with their team and peers. For me, the moment you demand respect as a leader is the moment you lose my respect as a leader.

That’s not an exhaustive list, and each of those points could be (and may be) a post unto its own. But that’s what ‘Senior Tester’ means to me (In my sheltered life). Undoubtedly, your definition is different, and that’s fine. Regardless of where your opinions lie, I hope this provides some food for thought on your own views of what ‘Senior’ means.

Changes, Three Ps, and More Changes

December 8th, 2011 by Alan Page 8 comments »

A little over five weeks ago, I got a new job (one of the things I find great about MS is that one can change jobs completely without going through the hassle of filling out new forms). In that five weeks, I was in Germany for four days, and off for two days for Thanksgiving, so technically today is my (…counting on calendar…) 23rd day on the Xbox team.

Admittedly, I’m still in the honey-moon phase, but I’m having a great time. But life just doesn’t seem to be as fun without a surprise here and there, and this career move wasn’t without exception. More on that later – but let’s first consider a bit of career advice.

One tidbit of career advice I often give is “The 3 Ps”. When you’re looking for a job (or evaluating your current position), you need to consider the Product, the People, and the Person.

  • Consider the Product – You’ll be more motivated and excited about your work if you have interest in the product (or the technical challenges regarding that product). On the corporate applications side of Microsoft, I honestly think that Lync (my old group) is freakin’ cool, but there’s no understating the sexy coolness of Xbox and Kinect either.
  • Consider the People – Nobody wants to work with a bunch of jerks. I don’t want to work with people who don’t care about their jobs. I happened to know dozens of people working on XBox (I worked with many of them on Windows 95 & Windows 98), and all are great people. When I was considering the move, I chatted with people on the team that I didn’t know – and they all had this vibe of loving what they do. To me, that’s the sign of a good team to work on.
  • Consider the Person – We all have to work for someone. Take time when considering a new position to make sure that whoever you report to (and ideally, their manager) are on the same page as you; and will support you and help you grow.

To me – the Person part of the equation is critical. I’m in a rare position at Microsoft – we don’t have many testers at my level who do not manage teams. Managing someone like me, and communicating my value (or lack of value) appropriately is a challenge. Because there are few of us extra-senior testers, there are very few managers who have experience using us effectively. I selected my last manager based on this criteria, and when I moved to Xbox, I used the same criteria. It was hard to leave a team where I had the 3 Ps, but the time was right, and I took the time to ensure that I would have the 3 Ps on my new team as well.

Three days into my new job, my manager called me into his office and said, “Welcome to the team – we’re having a re-org”. The details of the re-org aren’t important, but they make perfect business sense, and I’m excited about the change. Unfortunately, the manager I had carefully selected wasn’t going to be my manager any more – and with the upcoming release of the new dashboard, I wasn’t sure where I was going to land until a day or two ago.

So – with one manager on the way out, and another yet to be defined, I fell back on what I seem to do best – I did whatever I wanted. In the land of Xbox, I suppose that could mean a whole lot of Skyrim and Forza, but I dug deep into some testing challenges, looked at engineering systems, got to know people and basically spent a whole bunch of time figuring out how the org and technology work. I once considered a position at a company full of young folks where someone suggested that I spend at least a month or two “doing whatever I wanted” until I figured out what I really wanted to do. My recent experience wasn’t quite as directed as that, but I find it interesting that concept seems to repeat throughout my career.

The good news is that I’ve met with my new boss a few times, and I think we’ll work very well together. We’re still figuring out exactly what I’ll do (which is perfectly ok), but I’m completely comfortable with how he wants to use me, and although he’s still a bit of an unknown to me, I’m pretty confident my 3 Ps are still in place. I’m excited, and a little scared (another bit of good career advice), so I know I’m in the right place.

Just Fix It (mostly)

December 5th, 2011 by Alan Page 2 comments »

Chris McMahon’s latest post (Just Fix It) proposes that as far as bug tracking goes, the best course of action is to skip the “tracking” part of the workflow and “Just Fix It.” I’m a huge fan of this approach and think that for the most part, tracking a large number of bugs in a big fat bug system (and often overemphasizing the church of the bug curve) pretty much encourage a test-last / test-quality-in workflow.

I see this concept come up frequently, and I’ve noticed a bit of a trend. Teams that follow Just Fix It love it. Teams that prefer to fix bugs later are sure that the concept won’t work for their team, and that they need the curve and tracking data in order to ship their (undeniably unique) product. As a side note, one fun thing I’ve talked a few teams at Microsoft into doing is to pair on bug fixes – when Joe-Tester finds a bug, he Tells Kathy-Developer about the issue, and then the two of them pair-program the fix. I could write a whole post on why this is so cool, but I’ll leave it at that for now.

In short, I’m a huge fan of Just Fix It, but as usual, the totality of overlap of agreement between Chris and I is about 93%.

For example, let’s say on Monday, Alex-Tester notices that the froobnozzle isn’t working. He tells the developer, who fixes the problem immediately. Tuesday, Beth-Tester notices that the froobnozzle doesn’t work when interacting with another part of the system. She tells the developer, who fixes the problem right away. Over the following days and weeks, a lot of problems are discovered with the froobnozzle. The froobnozzle, is, in fact, a piece of crap held together by the 1s and 0s version of spit and duct tape. A bug tracking system let’s you see (I hate to say this out lout…) trends of where errors are. Bugs don’t appear randomly sprinkled throughout a product – they tend to congregate in clumps. Knowing where the clumps are can guide further testing, or risk decisions.

Source control almost mitigates this concern, but unless you have a diligent comment policy for check-ins, you probably won’t be able to differentiate between a “I was adding new code or functionality” check-ins vs. “I was fixing shit I broke” check-ins.

But I won’t go as far as to say you need a bug tracking system. As Chris describes it, and as most people use them, a bug system is really a work-item tracking system anyway. If you track work items on post-its or notecards, bugs should work the same way. As far as trends go, I think a simple tic-mark system would work just as well. When you discover a problem with the froobnozzle, write it on the board and put a tic-mark next to it. When a component gets n number of tics, schedule refactoring time, or do a design review (or both). Alternately, look at the components with the highest number of tics during the retrospective or sprint planning and review those for potential re-work.

But other than that, yeah. Just Fix It!

Note: I would have posted this as a comment on Chris’s blog, but I, for one, find the comment forms on blogspot completely unusable.

A bit of trouble shooting

November 30th, 2011 by Alan Page 2 comments »

I posted a few months ago regarding my move to using a virtual machine as my “mail” machine. I’m still a huge fan of that approach, but in my new job (the really cool one working on the Xbox team!), I’m running Win7 rather than server as my main machine. I looked into using an internal hosted VM server solution, but since the solutions I found are used primarily for testing, performance wasn’t quite what I wanted (or what I was used to).

Let me outline the problem. I don’t look at email or twitter or my rss feed all of the time – in fact, most of my electronic communication time occurs when I’m compiling / building (I could use that time to have a sword-fight, but I find it better to at least pretend I’m productive). I love to group the “non-essential” stuff together, and when I’m waiting on a build, it’s the perfect time to write email, documents, tweet (or sometimes blog).

imageThe problem is, that when I’m compiling, my 12 cores are pretty busy. This makes reading email, or doing pretty much anything else that would like more than a few time slices of cpu power sort of suck.

I have two computers (a desktop and a laptop), so I have an option of using my laptop for those tasks while the compiler elves are taking over my computer, but given the choice of using a 24” monitor and a full size ergonomic keyboard over a 13” monitor and compressed keyboard, which would you choose? To be fair, I adore my laptop (Lenovo X200s) – but I adore it because it’s small and I can use it anywhere (including on an airline tray table while the monster man in front of me leans his seat all the way back for 8 hours straight). But it’s not a computer I like to write large documents or presentations on.

The solution, as many have already guessed, is to connect to my laptop via terminal server and use it from my desktop machine. The overhead of TS is small enough, that I barely notice a perf problem even at peak memory and cpu usage. The TS session even stretches my desktop to 1920×1080, so it’s a pretty sweet setup. All that is good (and somewhat obvious), but few things in life ever go without a hitch.

Despite how much I wanted to love the setup, I noticed that my connection would drop frequently – and then it would take a minute until I could reconnect. I powered through it for a day or two (I tell myself that I was subconsciously gathering clues). Then finally, I found the clue that led me in right direction. I listen to music on Zune quite a bit while I work (I configured terminal server to play audio on the server machine (my laptop), so I select songs from the TS session on my desktop, and listen through headphones connected to my laptop). So…I noticed that whenever my computer disconnected, I lost audio a few seconds later. The first few times this happened, I (ignorantly) assumed that because I lost the TS connection, I also lost the audio. Then it hit me that since the audio is playing on my laptop, I should never lose audio…unless the network connection was lost.

Losing the TS connection and losing audio were both symptoms of the same root cause (lost network connection) – the only thing left to figure out was why two computers on the same subnet were losing their connection.

I took a look at power management settings to ensure that my laptop wasn’t suspending, but all was good. My next step was to look at my adapter settings to see if the network adapter was powering down for some reason. Sure enough, there was a setting named “System Idle Power Saver” that was enabled. I disabled the setting, and I’ve only had one dropped connection all week.

This example may sound more like yak-shaving than testing, but I’ve always liked the trouble shooting aspect of testing. Going beyond “here’s a problem”, to “here’s what (probably) caused the problem” is, in my opinion) an important skill for testers.

Oops – my build is done – time to get this posted.

Activities and Roles

November 20th, 2011 by Alan Page 1 comment »

I’ve been thinking about testing activities and tester roles lately, or more lately, since it seems to be a recurring topic on this blog. I have to admit that I remain a bit surprised how often testers argue about what is and what isn’t testing.

So – let me throw a few examples of potential testing activities out there for discussion or comment. For the scenarios below, consider two questions:

  • Does this describe a testing activity?
  • What role typically performs this activity?

Alex practices Test Driven Development. He consistently writes unit tests before implementing the code those unit tests verify. Over time, he’s built up a large set of unit tests that verify the correctness of all of the modules he owns. His unit tests give him the confidence to refactor or add functionality at any time.

Beth works closely with another teammate to ensure that the code implementation is highly testable. This includes pairing on many of the coding tasks, as well as adding hooks or accessible interfaces to the implementation when necessary. Her work results in code that the team finds straightforward and easy to test.

Chuck spends a lot of time analyzing code. Mostly, he’s a rock star code reviewer, and has found dozens and dozens of critical security and reliability issues in his team’s code base during the review process. He often uses tools and techniques like static analysis and complexity measurements in order to target his efforts. The whole team looks to him for critical code reviews, and he’s a mentor for many of the new team members.

Denise painstakingly enters test cases into a test case management system, and then regularly runs subsets of those tests as dictated by her management. She likes the predictability and structure of this approach and his attention to detail makes her successful in her job.

Frank finds product bugs by the handful. He uses a variety of test techniques, approaches, and tools to find several high quality bugs every day. Everyone on the team values his efforts, and many people on the team look to him for coaching on test approaches. His approaches are unscripted, but nobody doubts the effectiveness of his approach.

Fiona spends most of her day writing automated regression tests, and is constantly learning new approaches to writing automation. She writes high quality, trustworthy code that has few false positive / false negatives, and has earned the respect of everyone on the team. She enjoys writing automated tests and is proud of her accomplishments.

Greg works closely with the user experience and project management teams to ensure that the customer experience of his team’s product is of high quality. He frequently analyzes reports from customers and makes sure that all relevant team members know what the most critical issues customers are facing. He uses his broad knowledge of customer data to be influential on both product and test design.

Helen is a bit of a tool-smith. Although her team uses a lot of open source tools, she writes the applications and utilities that stitches the tools into an end-to-end testing framework. She loves thinking “big picture” and ensuring that all of the components in the system work together seamlessly. She doesn’t perform any product testing, but her work enables many of the testing activities to be successful.

To me, I could make a case that each of the scenarios above describe a testing activity – but I could also make a case that many do not. I’ll leave my observations at that for now and see what happens in the comments.

Trip Report: German Testing Day

November 14th, 2011 by Alan Page 4 comments »

As I’m writing this (or at least starting to write this), I’m on a plane from Frankfurt to JFK airport in New York (where I will catch another flight home to Seattle). I was in Frankfurt for the first ever German Testing Day event. The event is put on by the same folks that put on Swiss Testing Day, so I knew it would go well.

For those interested, here’s a quick recap of the trip.

November 6-7

I flew from Seattle to Detroit, then on to Frankfurt. I just reached “Silver Medallion” status on Delta, so I got a free bump to economy-comfort class and an extra few inches of room on the Detroit to Frankfurt leg of the trip. I’ve been to Frankfurt at least a dozen times, but this was the first time I’ve left the airport (travellers in the audience already know that Frankfurt is a busy airline hub).

I arrived at my hotel (~10 kilometers or so outside of the downtown area) around noon. In an attempt to fight off jet lag, I dumped my bags and then set off to explore. The train station was a 5-minute walk away, and within 20 minutes or so I was in downtown Frankfurt. I took a break at a Starbucks (who apparently have free wireless worldwide these days) to sync my mail and do a bit of work before grabbing some dinner and heading back to my hotel to sleep.

November 8

After a pretty good night of sleep, I had just 3 things on my agenda. 1) Explore more of Frankfurt; 2) Prep for my presentation; 3) Meet the conference board for dinner at 8:00pm.

I combined the first two by working at a coffee shop until I couldn’t stand the wooden seat anymore, then walking around Frankfurt until I couldn’t stand that anymore. Try as I might to park myself somewhere other than Starbucks, it was the only place I could find that had free Wi-Fi access. Coffee Fellows and O’Reilly’s pub both had free Wi-Fi, but they both required that I have a working mobile number (I asked about this at O’Reilly’s, and they said it was so they could track me down if I downloaded exceptionally large amounts of data).

One interesting discovery was a “Hammering Man” sculpture, since we have something almost exactly the same in Seattle (I’ve discovered these are two of three Hammering Men in the world).

Frankfurt "Hammering Man"                          Seattle Hammering Man

By 4:00 or so, I was feeling a little drained, so I went back to my hotel to dump my laptop and take a quick nap before heading off to dinner. It was great seeing Adrian Zwingli from Swiss-Q again and catching up with him. He’s such a passionate person and the perfect person to run these events. After a few beers and a plate of cheese Spätzle that was just a bit too rich to finish, we all headed back to the hotel.

November 9

After another fairly good night of sleep, I got up, prepped a bit more, then took a taxi to Jahrhunderthalle – the site of the conference. I gave the opening keynote of the conference (no pressure!) on Test Innovation at Microsoft. I haven’t given a talk on this topic before, and I had a huge number of insights and revelations during my preparation. I think this is a topic I will continue to develop (both test innovation in general, and sharing the amazing test innovations at Microsoft). The GTD folks got the first glimpse into some of the cool things MS is doing in testing – as well as some tips on how to make innovation happen (hint – you don’t start by saying, “I think I’ll innovate today!”). I felt like the talk went well, but also think that this is a talk I can repeat and improve on in the future as my own thoughts on the subject evolve.I did have quite a few people give me compliments on the talk during the day, but I also realize that people generally don’t track down a speaker to tell them that their talk sucked.

I spent the rest of the day listening in on some of the English talks at the event, and getting a bit of work done. A pair of presenters from eBay talked about test automation principles, and they had a good message (meaning that I agreed with what they had to say, and think they have a good approach). I talked to them a bit afterwards too, and they seem like great people too.

After the event, Sebastien Kernbach (Conference Head from Swiss-Q) one of his colleagues (a woman whose name I have, unfortunately, forgotten) and I had dinner together at the hotel before heading off to bed. Not a crazy night at all, but I was beat, and ready for sleep.

November 10

Time to fly home. I took the hotel shuttle to the airport, had some breakfast, and got on my flight. The connection at JFK went smoothly, and I was home, in my own bed by 9:00pm Seattle time.

Overall, I had a great time on the trip, and once again, the Swiss-Q folks showed me that they know testing and know how to create test events. I was honored to have been invited, and hope I have the opportunity to present at another of their events sometime in the future.

But for now, my travel schedule is completely empty, and I plan to keep it that way for as long as I can get away with it.