Re: ERP testing
- From: darrell@xxxxxxxxxxxxxxxxxx (".")
- Date: 21 Nov 2005 22:15:28 GMT
On Fri, 17 Nov 2005, mabobine wrote:
> I was working as a business analyst and was switched to quality control
> engineer recently in a company who are working on an ERP system.
>
> What I am doing is that i am checking the application and locating the
> bugs. There is no tool with which i am locating any bugs. I just read
> the use cases, see the flow of the application, the GUI, give some
> inputs and check the output whether it meets the requirements as
> specified in the use cases, do some negative testing and check other
> requirements like field length, etc.
>
> I write down the bug into a bug log system called "IssueView". Those
> bugs are checked by developers and then i retest the bugs again when a
> new build (release) is given by the them.
>
> I just came to know that there are different types of testing like unit
> testing, stress testing, etc. but without even knowing about these
> types, i am doing my job well enough. i mean i tested the individual
> components of the application which lies in the UNIT TESTING. I tested
> the application by giving loads of inputs, which lies in Load/Stress
> testing.
>
> I don't know whether that is it for a quality control engineer/tester.
> I need some information what i am missing, what tools i need, what
> specifically i should study and all the stuff which is required. What
> else i can suggest to my company to make sure we have a good quality
> product.
>
> I need some information about how to test an ERP system. What are the
> steps needed to have a good quality and whatever you guys think i need,
> please do suggest me.
Does anyone feel there is a need for more? You might want to take the, "if
it ain't broke, don't fix it" attitude. If everyone is happy with the
software then the testing being done is sufficient.
If there are problems, assess how critical they are. If you are losing
money then more testing is justified. If it is going to cost you more to
find and eliminate the problems and they are not critical, leave them
alone.
As an analogy, I bring my car into the shop for a regular oil change. The
mechanic notices a scratch on my right fender. He decides to replace the
right fender. I get my car back with a huge bill that includes the new
fender. I'm not going to pay for it. The cost of the fender comes out of
the auto shop or mechanics pocket. Or they force me to pay for it and I
never do business with them again. Maybe I tell all my friends and they
stop doing business with the shop as well.
To take it even further, some times fixing one bug just creates more...
the mechanic takes the right fender off but as he does the bolts holding
the fender on snap. He attempts to weld new bolts on and damages the
mounting point for the shock absorber. He realizes he needs to replace the
whole front end assembly on the right side. I get the car back with the
huge bill and it rides funny because he only replaced half the front
assembly.
In other words, be careful you don't open a can of worms. The best
starting point is see if you are tracking customer complaints. See if
there is a common problem there. Or suggest doing root cause analysis
(RCA) on some of the customer defects to determine how they slipped past
your testing.
--
Send e-mail to: darrell dot grainger at utoronto dot ca
.
- Follow-Ups:
- Re: ERP testing
- From: mabobine
- Re: ERP testing
- References:
- ERP testing
- From: mabobine
- ERP testing
- Prev by Date: Re: Domain Change?
- Next by Date: Re: Query in TestDirector 8.0
- Previous by thread: ERP testing
- Next by thread: Re: ERP testing
- Index(es):
Relevant Pages
|
