Looking for a QA Job? Come Work for Telligent!

UPDATED: It’s now December, 2010 and I’ve got another open position on my team! Everything below still applies. Contact info is at the bottom, or use the link on the blog’s sidebar. I’d love to talk with you if you’re interested!

Telligent is expanding our QA/testing team and we’re starting the process of looking for passionate, detail-oriented folks who might be a fit for the team. You’ll be working for me in my new role as the QA Team Lead, and you’ll be testing our neat products like Telligent Community, Telligent Enterprise, Telligent Analytics, plus a host of cool add-ons like our Mail Gateway and SharePoint integration products.

I don’t have a formal job description yet, but frankly, most job descriptions stink or don’t match reality.  Here’s my unofficial, completely unapproved description of what you’ll be doing:

• Working hand-in-hand with our Product team to create testable acceptance criteria for each new work item (feature, user story, bug ticket).
• Developing automated test suites using a number of tools like Selenium, Watir, Cucumber, and Visual Studio’s web test.
• Creating, updating, and executing test plans for all our products.
• Creating and updating matrices for supported platforms, then executing test plans against those. (You’ll be helping stand up and maintain those platforms in various virtualization environments.)
• Working hard to exercise the systems through exploratory testing.

Below are some of the tools we’re using or exploring in our QA work right now. I’m all over using any tool that will bring value to our work, so if there’s something you’ve had success with then let me know.

• UI testing: Selenium, Watir, possibly VS web test
• Languages: C#, Ruby
• Other cool toys: Cucumber, PowerShell

What you’ll need to bring to the table:

• A detail-oriented mindset.
• Passion about improving quality.
• Passion about improving yourself – what else are you doing other than reading my blog?
• Excellent communication skills in e-mail, written documentation, and verbally.
• Critical thought. Talk to me about how you approach problems.
• Patience and a pragmatic outlook. I plan on changing the world, but it will be a long haul. We’ll lose occasional battles but the war will be won. Fill in other over-used clichés here.

Notice I didn’t mention much about specific skills? What you’ve got in your head and heart are far more important to me. That said, it would be helpful, but not required, if you’ve got some exposure to the following:

• Software development experience. Something .NET-ish best, other languages are fine too.
• Experience with SQL Server 2005 and/or SQL Server 2008. (Exposure to SQL of any type helpful.)
• Understanding of software development lifecycle.
• Exposure to Lean and Agile development. (If you’ve decided neither of those disciplines are of value then please look elsewhere for an environment that will make you happy. I’m emphatic about both and you won’t be a good fit if you’ve looked Lean and Agile over and don’t care for them.)
• Previous experience in a QA role.

Telligent’s located in Dallas, but we have remote workers scattered all over the country and a few overseas as well. I’m happy to work with remote folks, but you’ll need to demonstrate that you’re able to be productive from a home office.

You’ll be working for me, so you may want to do a little digging around the blogosphere, Twitter, and the region’s dev community to see if that’s for you or not. I’m strong coffee with strong opinions that I’m happy to change when a well-thought debate is put forth. I care deeply about my work and I care even more deeply about my teams. Look up some folks who’ve worked for me or with me and get their opinions. (Steve, James, Brian, Todd, Nate, Sean, Dave, Leon) I didn’t ask them if it was OK, but I think you’ll get varied, honest feedback from them. 

Still interested? Drop me an e-mail with your resume: JHolmes AT Telligent DOT com. Feel free to drop me a note via the contact link on the blog’s sidebar, too.

Is Software Engineering Dead? (Process, not Construction)

Tom DeMarco, author of the seminal book Peopleware has written a short, interesting article Software Engineering, An Idea Whose Time has Come and Gone?

DeMarco’s article is really around engineering as it refers to controlling the process of creating software, not the actual software construction itself. The article’s short and doesn’t start any in-depth discussion, but the general point is awfully good: working too hard to control the process of software construction is a bad thing. A great quote from the article:

For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

We can’t use this as an excuse for being sloppy with our clients’ time or money, be those clients internal or external. That said, the points DeMarco makes line right up with my own beliefs:

• As an industry, we suck at estimation. Badly. The problems we solve are similar, but nearly always different from each other.  We make little or no effort to keep a good history of our estimates’ accuracy, nor do we do much to train folks on estimating.
• Because estimation is a time sink, use velocity for projecting project pace and what you can build within the client’s budget. (Get your work item granularity small, though!)
• Value is delivered to clients by creating software, not managing the project. Project management’s critical, but it needs to be a light hand. Oversight and correction versus harsh controls. (That means you’d damned well better spend a lot of time building great teams that are good enough to manage themselves, by the way.)
• Value is delivered to clients by being flexible enough to change what you’re building in order to meet the clients’ changing environment. (Or the clients’ evolving needs as their understanding of the business problem evolves.)

DeMarco’s article is way too short, and I really wish he’d provided more detail on the metrics and measurements he’s decrying – but I think there’s some good conversation starters there.

Upcoming Speaking Gigs

I’ve got a number of upcoming speaking gigs through September:

• 23 July. Three Tips to Improve Your Development Process, Dayton .NET Developers Group.
• 24 July. Acceptance Testing with Selenium & Cucumber. Central Ohio Application Lifecycle Management Group.
• 7-9 Aug. Leadership 101. eRubyCon in Columbus.
• 13-15 Aug. Three Tips to Improve Your Development Process, devLink in Nashville.
• 18 Aug. Three Tips to Improve Your Development Process, Evansville (IN) .NET user group.
• 14 Sept. Leadership 101. Columbus Architecture Group.

Let me know if you’re going to be around for any of those meetings!

Book Review: Beautiful Security

Beautiful Security, ed. by Andy Oram and John Vega, ISBN 0596527489, published by O’Reilly.

Like O’Reilly’s Beautiful Teams, this book’s a series of essays by industry experts, this time focused on security. The various authors do a great job of covering topics from social engineering to forcing firms to focus on security. The chapters are all well-written, although a few do better jobs of keeping the material interesting and flowing.

You’ll find plenty of security-related history in the book. Phil Zimmerman’s chapter on PGP’s Web Of Trust is one example. Pieter Zatko’s discussion of his work on the LH0phtCrack is another. Both stories help expose mindsets which, sadly, haven’t changed a whole lot.

Security, as with testing or overall quality, is at its most fundamental roots a culture issue. Not every story focuses on this aspect, but pointing out bad culture is a common theme through many of the chapters. Zatko’s discussion of “Learned Helplessness,” John McManus’s Security by Design, and Jim Routh’s Forcing Firms to Focus are all great reads on this line. Many of the stories correctly emphasize that security isn’t just about someone hacking code – it’s a much broader issue.

As with any good security book, there’s plenty of well-done content which will likely scare you in to re-thinking how you and your company approach security. Beautiful Security can help you identify practices, problems, and mindsets which leave you, your company, or your clients at risk.

Overall it’s a very useful, highly readable book on a critical subject.

Book Review: The Nomadic Developer

The Nomadic Developer by Aaron Erickson, published by Addison Wesley. ISBN 0-321-60639-6.

If you’re in the software consulting business, or considering going in to the consulting business, then you really, really need to read this book. It’s chock full of things too many consultants don’t stop to think about before joining consulting firms, or don’t pay attention to once they’re in.

Erickson does a great job covering critical issues like why one would consider going in to consulting, culture profiles of typical consulting companies, critical business aspects of consultancies, and a number of other things I wish I’d known before joining a couple of consulting firms I’ve worked for. Erickson’s writing style is clear, concise, and entertaining. He’s also pulled in a number of “annotators” who provide excellent counterpoints and additional insights throughout the book.  There’s also one chapter of short articles by experienced consultants like Ted Neward and Bruce Eckel.

While all of the book is highly useful to readers in the consulting line of work, several topics stood out:

• Understanding critical concepts like sales pipelines, revenue, and margins
• Learning how to ask questions during an interview, and learning which questions to ask
• Figuring out how to survive and thrive at a client and at your consulting company

This book isn’t just for folks in the consulting line of business, it’s also good for independents. Moreover, the career, business, and interviewing advice are great reads for anyone, regardless of the sector they work in.

Book Review: The Manga Guide to Physics

The Manga Guide to Physicsby Hideo Nitta and Keita Takatsu. Published by No Starch Press, ISBN-10: 1593271964.

This book is an awfully fun, highly educational read. My last involvement with physics was 30 years ago in high school when I sat in the back row of Mr. Davis’s classroom with my best friend Ernie Fatta. I was more interested in trying to flirt with the pretty girl who sat near us, plus math wasn’t my strong suit, so I didn’t get much out of the course. Go figure.

This book uses a story line to expose readers to fundamental physics concepts like Newton’s Laws of Motion, vectors of force, and kinetic energy. A patient physics geek walks the main character through the concepts using practical demonstrations with tennis balls, bodies, etc.

All the concepts are laid out in very clear fashion, and the examples are really spot on and understandable. There’s math involved, but it’s kept at an understandable level and is presented in very short, progressive steps.

This was a really enjoyable read – and it was even educational. I loved the format and I really appreciated the effort and thought that went into laying out the material in such a clear fashion.

There’s an entire series of these Manga Guides covering everything from molecular biology to databases. If the others are as good as this one then I’d be happy to read them too!

Book Review: The Economics of Iterative Software Development

The Economics of Iterative Software Development, by Walker Royce, et. al., published by Addison-Wesley, ISBN 0321509358.

This is a lean book (small size, only 170 pages) which attempts to help managers and decision makers move to iterative approaches over waterfall.  The book’s well written and has some good, thought-provoking discussion in it.

You won’t find discussions of specific methodologies in this book, but you will find repeated emphasis on critical concepts like delivering running systems over useless documentation (not ignoring documentation, mind you, but delivering the right amount of it). Doing the right amount of planning at the project’s start is also emphasized: avoiding over-architecting and big design up front.

It struck me that much of the authors’ definition of “iterative” development is subtly scattered around the book. It’s not always In Your Face, and that’s actually OK because you’re able to better focus on their deeper points.

The economics part of the book’s title comes through some good discussion on ensuring you’re delivering business value, plus an entire section on measuring your project’s success. There’s good discussion in those sections to help you understand opportunity cost (if I do this, what else am I unable to do?), net present value, and a great example on prioritizing features based on their value to the business.

Some things in the book are a little vague for my tastes, but the authors did a nice job of keeping the book brief, concise, and on target.

Overall it’s a very good, useful read.