Interview with our first guest speaker Patrick Mullarkey

1.            Describe your current role.

I'm the Test Manager in the IT department of a financial services company that employs 400 people locally providing  payment protection insurance.  About 150 people work in IT and of those, 31 work in testing - that's in addition to a number of contractors.  Testing is expensive, it costs a lot to do it right.  

2.            Why did you decide to focus on testing?

I'm not a creative person - good software developers are.  Testers need to be good at communicating; you also need to be a good collaborator.  

3.            How has the software industry changed since you started?

Yes, about twenty years ago when I started with Symantec, it was mostly junior people who worked in testing, aiming to move into other areas.  I then moved to the U.S. and there was a different attitude there - much easier to hire and fire people - this was before the dotcom bubble.   

4.            Has software testing changed as much, and how?

That has all changed now, testing is seen as a career in itself.  Testers are better paid now. Coming back to Europe, I worked with a testing consultancy company, Insight.  

5.            Should testers be paid as much as developers and why/why not?

It depends!  User acceptance testing is really based on domain knowledge, not software engineering or testing knowledge, so it is not necessary to have highly qualified people. On the other hand, test automation does require similar skills to programming. 

6.            Where are the most common defects found, in requirements documents, designs, or implementation/code?

That question is ambiguous!  It depends whether you mean where are they found or where are they introduced in the first place.  A lot of business requirements are badly done to begin with.  People are busy with their day-to-day jobs .  This leads to dodgy functional specs which are used for the design of test cases.  

 [Draws a waterfall-type diagram on the board showing the relationships between these.  Has to go and insert "code" as intially fogot to put it in! Talks about the need for traceability back to specs, and then the occurrence of Incidents - i.e not defects.]   

Emphasises that a person makes errors , a fault is introduced into code; a failure only happens when the softwar is tested.  

[He  emphasises the importance of requirements and of writing test cases as early as possible.]  

If you cannot figure out how to test a requirement there is no way you can develop it. 

7.            What are your views on automation of testing?

It is an absolute requirement for regression testing, for iterative development, for code changes and for environmental changes.

 

8.            What do you think about qualifications in software testing, such as the ISTQB?

[He is in favour of them;  in his previous job, has trained people in preparation for the exams.]   

Check out irishjobs.com if in doubt about whether employers expect/desire these qualifications. 

9.            Which is more important, in your view, specification testing or software testing?

The primary reason that the V-model exists is to front-load testing in the life cycle - write tests first. There should always be a tester involved in business requirements.   

[I guess he believes that tests might replace specs some day.]  

 I always expect developers to do unit testing.  Who is responsible for software quality? - everybody on the team!!