• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Testing Question - What do you call this?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #21
    Originally posted by SimonMac View Post
    If the acceptance criteria of your SIT is full end to end testing that god help your project budgets!
    Where the hell did I say that?
    You're now making stuff up to cover up for your overly-aggressive salvo at me an then misreading or misunderstanding what I'd said about acceptance criteria. The acceptance criteria for something leaving SIT and moving to UAT is very different to the acceptance criteria for full end to end testing.
    The greatest trick the devil ever pulled was convincing the world that he didn't exist

    Comment


      #22
      Originally posted by SimonMac View Post
      Not really, you mainly use stubs on dev and sometimes system test, not all interfaces you work with have test environments themselves.

      The stub just simulates a happy path call so you can check that was should be returned by the live system is accepted into your new system.

      If you have never come across a stub before you are either not a tester, or a crap code monkey
      Certainly not a tester or a crap code monkey, LOL, but, at least I do know what I'm talking about.‎

      I have seen plenty of integration projects go completely wrong, in the past, especially large ERP systems. In fact I saw one international news agency almost go bust, in the early 2000's, was costing them £1m, per day.
      I have, also, seen systems where core functionality, like order processing or invoicing does not work (!), as the interfaces were not fully integration tested.‎

      Obviously, this type of approach, stub, or whatever you want to call it, was used inappropriately, at the integration stage, you will always face a series of risks using it.

      Quantifying those business critical risks, presenting them to the business, getting extra budget, pushing back, is part and parcel of what an experienced contractor does.
      To be clear, I'm not talking about end to end testing of everything, either, that would be ludicrous.

      In addition, correcting mistakes, in core functionality, after the event, costs a lot more than identifying it and fixing it earlier!‎
      Clever thinking saves businesses money, it doesn't cost them it.

      HTH
      Last edited by MrMarkyMark; 7 April 2016, 14:47.
      The Chunt of Chunts.

      Comment


        #23
        Originally posted by Cirrus View Post
        You are a developing a system which needs to interface to another system. You don't however want to use a test version of the second system, so you build a dummy that has limited functionality sufficient to permit you to do primary system testing.

        Now the question is what do you call the dummy system?
        Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
        Or you could go for POC (Proof of Concept).
        So now I am worried, am I being deceived, just how much sugar is really in a spoon full!

        Comment


          #24
          Originally posted by DallasDad View Post
          Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
          Or you could go for POC (Proof of Concept).
          So last year Dahliing...

          "Stub" has more of a roguish, Hipster, charm about it
          The Chunt of Chunts.

          Comment


            #25
            Originally posted by Cirrus View Post
            To me a stub is where you insert some kind of class or mock that pretends to call a service (like a card acquirer) but actually just returns some data that the program can continue with.
            Same here. I've never heard it applied to simulating a system as a whole, until now.

            If that makes me a crap code monkey then so be it.

            Comment


              #26
              Generally:

              Stub describes a test double that returns canned responses.

              Mocks describe those which can be dynamically configured to produce desired responses & give the ability to verify interactions.

              Fakes pretend to be real functioning systems/components.



              People often refer to spies in reference to things which act like stubs, but save the invocations for later inspection.

              Comment


                #27
                Originally posted by DallasDad View Post
                Well it may not be PC for this thread but I personally like to call such sandpits errm sandpits
                Or you could go for POC (Proof of Concept).
                It's not a PoC.

                Comment

                Working...
                X