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:[email protected]]
Sent: Tuesday, January 20, 2009 3:38 PM
To: Ziv Leyes
Cc: [email protected]
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:[email protected]]
Sent: Tuesday, January 20, 2009 1:31 PM
To: Ziv Leyes
Cc: [email protected]
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 [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Marc Binderberger <[email protected]>
_______________________________________________
cisco-nsp mailing list [email protected]
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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
