I recently hired a programming team to do a port of my iPad app to the iPhone and Android platforms.

Now, in a separate contract, I am asking them to implement a bunch of tips on how to play the app, similar like you would find in Candy Crush or Cut the Rope. They want to charge 12 hours @ $35/hr for the "Testing all of the Tips", telling me that normally it would take them more than 25 hours but that they will 'bear the difference'.

I am not familiar with this level of itemization, but maybe it's a new practice? I am used to devs doing their own quality control, and then having a testing/acceptance period.

They are using Cocos 2D-X, and they say that the tips going to multiple platforms makes all of the hours jack up. I feel like they might be overcharging, and it's difficult for me to know because it's kind of like with a mechanic. "It took us 5 hours to replace the radiator". How can you dispute that?

It seems to me that most of you would charge for the work but NOT for hours that you are 'testing'. Am I missing something?

Thanks for any help and advice you can give!

closed as off-topic by Jimmy Hoffa, Steven Evers, GlenH7, Jim G., gnat Oct 29 '13 at 3:30

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    "They want to charge 12 hours @ $35/hr for the 'Testing all of the Tips' [BUT] I am used to devs doing their own quality control" Sounds like the exact same thing, except itemized a bit differently. – user16764 Oct 28 '13 at 22:37
  • 2
    They gave you an itemized invoice, basically they're giving you the option that they don't test it. Up to you whether you want your stuff tested. Perhaps the part is so simple they don't feel it likely they could mess it up, and are therefore giving you the option that they don't test that part. Your call whether you want them to test it or not. The "doing their own quality control" bit is something that they do but it doesn't take 0 hours, it takes time and you either pay for that time or you don't and you don't get that time. – Jimmy Hoffa Oct 28 '13 at 22:46
  • 4
    Contract disputes and invoicing practices are not on topic for this site. – Jimmy Hoffa Oct 28 '13 at 22:47
  • 2
    When you get work for $35/hr, they're only going to do exactly the work that you agreed to do. If you didn't specify hours for QA, you get code that the dev writes and says "yup, it works for me". Consider yourself lucky that QA hours are cheaper than dev hours. – Sean McSomething Oct 28 '13 at 22:49
  • 2
    What am I missing with this question? Software Developers (at least semi-competent ones) don't just code and throw things out the door without doing some form of testing to make sure the sw works. Whether they lump that testing in coding or separate it out; it is all the same. They don't go on the clock while coding but off the clock when testing. – Dunk Oct 29 '13 at 15:25

To determine whether or not the software "works" you and the software developers evaluate the software against the software requirements that you provided to them, and determine whether or not the software they provide to you actually meets those requirements. The way you direct this process is by providing testing requirements within the requirements themselves.

Software requirements should be specific, measurable, attainable, relevant, and time-bound. Every requirement must also be accompanied by clear, specific and unambiguous criteria that demonstrates that the requirement has been met. Generally speaking, that means you're defining a test as part of the requirement; if it passes the test, you declare success. If you have requirements like that, then you already have a built-in mechanism for insuring that your software developers deliver the product that they promised, because they have to demonstrate to you that the software meets each of the requirements, in the manner stated in the requirement.

Tips for writing testable requirements include:

  • Use short, direct, complete sentences
  • Make requirements internally & externally consistent
  • Remove ambiguity
  • Make requirements measurable
  • Make requirements finite
  • Include testers in the requirements peer reviews
  • Define a testing strategy for each requirements as soon as it is specified
  • Trace requirements to test cases

If the tips were part of the original requirements/specifications that you provided to them, and they bid the job on a fixed-cost basis based on those requirements, then they are obligated to deliver to you an app that works. If they need to test it to make sure that it works when they deliver it, then that's what they need to do. Otherwise, they will be fixing problems that you find later, for free.

Further Reading
Writing Testable Requirements

  • 2
    Worth noting: 12 hours at $35 per hour sounds like cheap insurance to me. Just make sure everyone is crystal clear about what that money is paying for. – Robert Harvey Oct 28 '13 at 23:02
  • I've never seen their testing. I don't know how one can predict precisely what, if anything, it insures. – dcaswell Oct 29 '13 at 0:56
  • 1
    @dcaswell: What role do you play in this conversation? – Robert Harvey Oct 29 '13 at 1:54
  • My role is Commenter. Rather than discussing roles, I was curious whether you would share the criteria you used to judge the testing as cheap. – dcaswell Oct 29 '13 at 2:10
  • @dcaswell: See quora.com/How-much-does-it-cost-to-build-an-iPhone-app. Assuming that the testing has added value, it is a tiny cost relative to the total cost of building an app. – Robert Harvey Oct 29 '13 at 2:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.