[c-nsp] Acceptance Test Procedure for New Cisco Devices
Alex Balashov
abalashov at evaristesys.com
Tue Jan 20 19:18:25 EST 2009
Yep, that's the other end of the spectrum.
If the test is extremely detailed, it can also mitigate liability by
being "thorough" and "complete" from a contractual obligation
perspective. Precision is always better than ambiguity from a legal
perspective, all other things being equal. It can still consist of
little to no meaningful work.
Something like:
* Power-cycle high availability metrics assessment.
* IOS command line interface code train regression test.
* Layer 2 Media Access Control interface state transition test.
* NTP time server synchronisation exercise under nonzero load.
* Telnet RFC 854 interoperability regime.
* RFC 1073 NAWS compliance test.
* NVRAM installation verification.
* Flash I/O subsystem test.
* Professional interface inspection for jumbo frame incidence.
* Deployment of Maximum Transfer Unit (MTU) processing engine.
* Metaphysical Feature Card (MPFC) integration.
But unless that seems straightforward to do, the best route is cloudy
ambiguity.
Marc Binderberger wrote:
> Hi Ziv,
>
>> But I guess we'll finally opt for letting the Cisco QA be enough as a
>> guarantee the devices work (there's always RMA) and have Alex's
>> suggestion be the winner here, just be as nebulous as you can and
>> follow the "ill-defined and metaphysical characteristique" of such
>> undefined term as "Acceptance Test Procedure"
>
> Is a hardware failure what the customer is worried about? You mentioned
> a turn-key solution and as a customer I would be more worried about if
> the solution actually works as expected. The detail that you have RMA
> contracts with Cisco and within what time is only part of it.
> Routers/Firewalls are mostly a software product with all the consequences.
>
> Regarding the "ill-defined" - may work. Sometimes it also works to be
> extremely detailed. You describe a test procedure in the very detail, so
> there is no doubt what you have tested and how to reproduce it. Doesn't
> mean the test has to be complicated - even if it's trivial you can hide
> this is many test steps ;-)
>
> E.g. power-cycling a whole setup is a valid test - after an power outage
> you want your solution come back up again.
>
>
> Regards, Marc
>
>
>
>
>>
>> I'd ask the customer:
>> Are you married? Did you fill an ATP form before you said "Yes, I do"
>> ??? No??? Then c'mon, gimme a break!!! It's just a darn router we're
>> talking here, not chaining your entire life with the same woman!!
>> A router can be replaced when malfunctioning, with a wife it's a bit
>> more difficult, isn't it??
>> Thak you all again!
>> Ziv
>>
>>
>>
>> -----Original Message-----
>> From: Alex Balashov [mailto:abalashov at evaristesys.com]
>> Sent: Tuesday, January 20, 2009 3:38 PM
>> To: Ziv Leyes
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] Acceptance Test Procedure for New Cisco Devices
>>
>> But if it's attached to a legal statement, the more nebulous and elastic
>> (aka BS) it is the more protection you have from incurring liability for
>> actually having done or not done something.
>>
>> That gets easier when the "acceptance testing process" is ill-defined
>> and metaphysical, not harder.
>>
>> Ziv Leyes wrote:
>>
>>> Ok, let me be more specific
>>> When we buy devices for our own use, we just open it, plug it, and
>>> start using them, if there are any problems, we call the provider and
>>> they fix the problem (RMA or whatever)
>>> In this case, we're going to sell the equipment as a kind of turn-key
>>> project, and the customer asked us to provide them with "our" ATP,
>>> which we don't really use for ourselves, so I'd like to implement one
>>> sort of testing procedure from now on for this type of cases. We're
>>> going to attach this to a legal statement so we can't just type some
>>> BS there and that's it, we want to actually implement it, and if we
>>> write we do a,b,c,d then we'll going to do a,b,c,d procedure for real.
>>> I was thinking some of you guys may already use this kind of test
>>> routines and can help me creating one.
>>> I don't need some really serious stuff, I can imagine I'll check the
>>> delivery status of the package, open it, check all the contents that
>>> need to be there are there, to plug the device and see it works,
>>> perhaps load some configuration, plug the hardware that is planned to
>>> hold if any (HWICS and so), perform some soft and hard reboots, see
>>> the device responds, there are links on all interfaces, and pack it
>>> back exactly as it was.
>>> The problem is I don't know how exactly write it down on a kind of
>>> form that there's a checkbox for each test.
>>> Does anybody have some ready to go stuff?
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Peter Rathlev [mailto:peter at rathlev.dk]
>>> Sent: Tuesday, January 20, 2009 1:31 PM
>>> To: Ziv Leyes
>>> Cc: cisco-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Acceptance Test Procedure for New Cisco Devices
>>>
>>> On Tue, 2009-01-20 at 12:13 +0200, Ziv Leyes wrote:
>>>> Could anyone share if possible a kind of basic ATP you may use for new
>>>> Cisco devices that you may receive?
>>>> I'm in need of providing a customer with such procedure for two new
>>>> devices, a Cisco 1861 router and a Cisco ASA5510
>>>
>>> Is it just the hardware that needs to be acceptance tested or is it some
>>> kind of service depending on this hardware? I don't specifically recall
>>> the term "ATP" but I guess Operational Acceptance Testing is the same.
>>>
>>> We only supply services, and the acceptance tests are defined by the
>>> receiving end, typically with some help from a Service Manager and a
>>> network engineer. The tests only check functionality not endurance of
>>> the system. Typically the tests check everything defined in the SLA.
>>>
>>> When receiving hardware we use for ourselves we have no formal
>>> acceptance tests; for core equipment it runs in a lab for some time and
>>> the takes on a role as a standby unit in the production net. Sometimes
>>> when time limits dictate it we end up just placing some new component in
>>> an important role without testing. I hope the manufacturer does some
>>> kind of burn in test. :-)
>>>
>>> HTH,
>>> Peter
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ************************************************************************************
>>>
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals &
>>> computer viruses.
>>> ************************************************************************************
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ************************************************************************************
>>>
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals &
>>> computer viruses.
>>> ************************************************************************************
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>> --
>> Alex Balashov
>> Evariste Systems
>> Web : http://www.evaristesys.com/
>> Tel : (+1) (678) 954-0670
>> Direct : (+1) (678) 954-0671
>> Mobile : (+1) (678) 237-1775
>>
>>
>>
>>
>>
>> ************************************************************************************
>>
>> This footnote confirms that this email message has been scanned by
>> PineApp Mail-SeCure for the presence of malicious code, vandals &
>> computer viruses.
>> ************************************************************************************
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ************************************************************************************
>>
>> This footnote confirms that this email message has been scanned by
>> PineApp Mail-SeCure for the presence of malicious code, vandals &
>> computer viruses.
>> ************************************************************************************
>>
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
> --
> Marc Binderberger <marc at sniff.de>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
More information about the cisco-nsp
mailing list