Lisa Crispin

Organisation – ePlan Services Inc., a Paychex Company

Role/Designation – Tester

Location – Denver, CO, USA

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: a Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009). She has worked as a tester on agile teams for the past ten years, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit www.lisacrispin.com. @lisacrispin on Twitter. gplus.to/lisacrispin on Google+.

1. How long have you been associated with software testing?

I started my first programming job in 1982, and switched to testing in about 1993

2. How did you become a software tester?

I worked in tech support for a software company starting in 1986. Nobody at that company (which, when I started there, was larger than Microsoft) even heard of testing. We tech support folks had the idea that if we tried out new releases as soon as we got them, then when customers called in with problems, at least we could say, “Oh yes, we know about that problem, and we’re working on a patch”. The managers realized it was possible to find problems before the customers did, so they formed a testing department. I jumped right in!

3. By any means, do you regret being associated with software testing?

No, it has always been an honor to me. I’ve always enjoyed good relationships with everyone on the software development team. We are working towards a common goal – delighting the customers.

4. Do you think software testing is less respected than other disciplines within software development or professions such as accountancy?

Unfortunately, many companies and many managers don’t understand testing. So they may hire people who call themselves testers, but who really don’t want to ever get outside their comfort zone, and learn something new. They simply execute manual regression test scripts and wait for code to come “over the wall” to them. These people give testing a bad name.

5. What will you suggest to people who want to join IT industry as software testers?

Realize that testing isn’t a separate phase (to borrow a phrase from Elisabeth Hendrickson). We must find ways to communicate better with programmers, and collaborate with them, with the business stakeholders, with other roles in software development to deliver a high quality product.

6. You strongly believe that team approach is the best approach in finding solution within agile development. Why do you think so? Are there alternatives to this philosophy or approach?

That’s right, in my experience; the “whole-team approach” to quality works the best. Everyone involved with delivering software wants to please the customers. When we work together with this common goal, we have the best chance of succeeding. For example, if we begin by thinking about tests and how we will automate them, the programmers will find ways to design the code to make automating tests easy.

7. People normally say that agile team should be self organising. What benefits do you see with this approach?

Software teams must be free to find the best implementations of the features the stakeholder’s desire. These implementations must be testable. Self-organizing teams can experiment, look at the results of those experiments, and adapt accordingly. The teams I’ve worked on have been able to try things that we thought might not even work, because we were committed to delivering high-quality software. We need to make the commitment, and then we need to make the commitment really meaningful.

8. Some people criticise that automation is overemphasized within agile development. Do you believe these are unfair criticisms and automation is a key to the success of a project?

When I started working on XP teams in 2000, I saw a lot of emphasis on unit test automation. If there hadn’t been a rule that we needed to automate 100% of our regression tests, the testers would have been out in the cold without help in automating functional and other types of testing. I personally have not seen any situations where automation was over-emphasized. Automating regression tests frees our time for the important exploratory testing.

9. With the large scale adoption of agile development, coder is churning code at fast speed that they are no more bottlenecks in the product delivery cycle. Continuous integration helps business meet their timescale in majority of cases. It is believed that ops are now the bottleneck in the delivery chain. This has resulted in the introduction of DevOps which is picking up pace. Is this just hype or a reality? Have you seen such trends during your work and would this speedup the continuous delivery in real terms?

I’m not that knowledgeable about DevOps and continuous delivery, though I have read Jez Humble and David Farley’s excellent book. I think the need for continuous delivery depends on the business domain. My company produces financial services applications. We’re capable of delivering to production every day, or continuously, but our business people do not generally see a need for delivering new features more often than every two weeks. However, we have put a lot of effort into our continuous integration, running thousands of tests all day, every day, to make sure we have a releasable build on hand at all times.

In my opinion, your feedback loop can’t be too short! We work to keep our JUnit suite running in under eight minutes, and have feedback from tests at all levels within 45 minutes of any check in. We’d like that feedback to be even faster. This helps us stay on course and allows us to spend our time adding value, not stopping to fix regression bugs. Eight years ago we were happy to have a stable build by the end of the iteration. Now we expect to have one at all times. It will be interesting to see what the next step is.

10. Recently we had a discussion on the role of testers in the next five year and it was unanimously accepted that testers in future may be called Test Master like Scrum Master or Test Assurance Expert. How do you see the role of a tester changing in the foreseeable future?

That’s interesting. It’s hard for me to judge how the tester role might change, because I’m accustomed to the tester role on my own team. The programmers on my team do lots of testing. They look to the testers for expertise in eliciting examples of desired and undesired behaviors from customers, for expertise in how to turn those into automated functional tests that drive development, and for expertise in manual exploratory testing. I don’t see that role changing.

11. In the same discussion it was agreed that there are four types of testers: traditional, agile, CDT and security and they all require different skill sets to function. Do you think there are common skills that a middle-of-the-road tester can acquire to cover a broader area of testing?

Personally I see more areas of specialization than that. For example, I know testers who are specialists in performance or reliability testing. I think any tester should hone their thinking skills, learn how to apply critical thinking to testing, learn how to collaborate with other roles on the team with the goal of delivering the best quality product. I think the key is that every tester should be working on improving skills that apply within her own particular context. Everyone should be getting outside her comfort zone.

12. Where do you see Software Testing heading in the next five years?

I’m not really a visionary. I hope software testing is heading towards being an integral part of software development, not a separate phase or activity.

13. What qualities would you look for in a candidate when you want to recruit someone for software testing job?

As Kay Johansen said to me several years ago, attitude and mindset are everything. I feel it isn’t hard to teach technical skills. But you can’t teach attitude and mindset. I look for someone who is passionate about software quality, and willing to work as part of a whole team to make that happen. The technical skills are just details.

14. What do you do when you are not working?

I have too many interests! I train with horses in dressage, I work with my miniature donkeys, I read extensively, I garden, I love opera and theatre, I love to hike, I have many pets, I love travel, I do lots of family activities.

15. Complete this sentence  “I use twitter because –“.

I use twitter because it connects me with a supportive community and helps me improve my skills every day.

16. Last question – Do you read Testing Circus? If yes, what is your opinion about this magazine?

Testing Circus gives me insights from practitioners that inspire my team to try new experiments.

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Lisa-Crispin_Testing-Circus.png?fit=557%2C741&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Lisa-Crispin_Testing-Circus.png?resize=150%2C150&ssl=1Ajoy Kumar SinghaInterview with TestersInterview with TestersLisa Crispin Organisation – ePlan Services Inc., a Paychex Company Role/Designation – Tester Location – Denver, CO, USA Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: a Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful...