Testing

*) Ask them if they ever spend time manually testing features that have been out for a while
*) Ask them if they ever shipped new features that broke old features
*) Ask them if they are happy with this?
*) Ask them if they think it makes them and their company successful or if they think they need to change

You can take a couple of points from the business case blogpost about why to do CI here:
http://blog.codeship.io/2013/04/11/a-business-case-for-continuous-integration.html

Testing is about making sure your users can walk through the most important parts of your system and use your product. When testing you should be thinking about your users first and how they interact with your system, not how you can get 100% unit test coverage (which is a nonsense metric)

Start testing from top to bottom: http://blog.codeship.io/2013/03/15/testing-top-to-bottom.html

Testing is not to make the developers happy, but testing is a tool to make our customers happy because we ship great software and don't fuck things up constantly. It's as important as great support and other tasks to make people happy. Testing is not just a technical challenge but a people and product challenge.

It's about providing value to our customers by building great features but making sure those great features are here to stay. People want new and better tools, but they don't want a constantly broken system that adds tons of new stuff, but kills everything else. Innovation is not possible without the proper groundwork, and testing (as well as proper development workflows, code review, continuous deployment) are part of that groundwork