Reply to: Are you an Excel guru?

[Brussels Slumdog]

Wouldn't it be good to combine SAP experienced testers and non-SAP experienced testers in your team? That way you get people who know the basic functionality AND people who can ask the kind of awkward questions that find stuff nobody else has found.

This is normally the set up for Pharmaceutical companies where delivering the right product(master data) to the right customer is absolutely critical. My last pharma company had a non SAP experienced tester but he was PERM

[Mich the Tester]

I dont believe that I could test an Oracle or JD Edwards as I know nothing about these systems.

Yes you could; I could teach you. Even though I've never done any JD Edwards, I can test anything.

Anyway, I've tested SAP IS-U and HR and in those I haven't seen anything that would prevent a good tester testing well without prior knowledge of them.

[Mich the Tester]

And we all use excel for those, don't we?

Not me. Lady Tester does it; I've no idea how.

[Brussels Slumdog]

But you haven't tested the vulnerability to faulty master data yet, which is obviously a risk if it's so important and has to be input by people. If master data is that critical, I suggest testing that.

Plus, what is so special about SAP testing in your example? You've just described a typical process that you'd use in many other systems.

Master data is tested during data migration verified by the users. After golive its the responsibilty of the master data team to test the inputted data

I dont believe that I could test an Oracle or JD Edwards as I know nothing about these systems.
I guess I could teach you the basics of SAP and then you could do some testing. The guys in Pharma also have their own testing mentality

[doodab]

I know it will, but not before my testing mates and I have sent some juicy invoices.

And we all use excel for those, don't we?

[Mich the Tester]

It wouldn't matter. People will buy it and implement it and it will go live with a ton of bugs in it whether you find them or not.

I know it will, but not before my testing mates and I have sent some juicy invoices.

[doodab]

Wouldn't it be good to combine SAP experienced testers and non-SAP experienced testers in your team? That way you get people who know the basic functionality AND people who can ask the kind of awkward questions that find stuff nobody else has found.

It wouldn't matter. People will buy it and implement it and it will go live with a ton of bugs in it whether you find them or not.

[Mich the Tester]

Yes infact everytime you implement a new patch or someone from another site implements a new functionality another set of bugs appear.

I could implement SAP in the Netherlands and go live with no bugs and then roll out to Belgium next year and you could arrive on a Monday morning with several bugs.

Wouldn't it be good to combine SAP experienced testers and non-SAP experienced testers in your team? That way you get people who know the basic functionality AND people who can ask the kind of awkward questions that find stuff nobody else has found.

[Brussels Slumdog]

Continuous testing required

[QUOTE=Mich the Tester;1756221. Get the world's best testers together in one team and they'll be doing well to find 75% of the bugs.[/QUOTE]

Yes infact everytime you implement a new patch or someone from another site implements a new functionality another set of bugs could appear.

I could implement SAP in the Netherlands and go live with no bugs and then roll out to Belgium next year and you could arrive on a Monday morning with several bugs.

[Mich the Tester]

Example
The configuration is done in the test client ie client 100 then
transported to test client 101 and tested (SIT). Once the test is approved it is transported to UAT client 200 and tested then
moved to the production client 300. Configuration can only be done in the test client and transported.



If there are sensitive areas in master data the system can be configured to an approval to be made by a second user ie bank data

But you haven't tested the vulnerability to faulty master data yet, which is obviously a risk if it's so important and has to be input by people. If master data is that critical, I suggest testing that.

Plus, what is so special about SAP testing in your example? You've just described a typical process that you'd use in many other systems.

[Brussels Slumdog]

I'd want to see what happens if I make tiny mistakes in the master data and configuration if that's such a sensitive area. Do you test that? How?

Example
The configuration is done in the test client ie client 100 then
transported to test client 101 and tested (SIT). Once the test is approved it is transported to UAT client 200 and tested then
moved to the production client 300. Configuration can only be done in the test client and transported.



If there are sensitive areas in master data the system can be configured to an approval to be made by a second user ie bank data

[Mich the Tester]

The knowledge of SAP testing is passed on to others during user acceptance testing (UAT) . These users are Accountants who wish to remain Accountants and Logistical users.
Its possible to be a test manager without knowing SAP or business processes.
As a SAP FICO consultant testing is only a part of my job. My role consists of business analysis,configuration,training,data migration and go live support.

If the standard stuff doesn't work it will be discovered during SIT and UAT testing

I'd want to see what happens if I make tiny mistakes in the master data and configuration if that's such a sensitive area. Do you test that? How?

And your last statement assumes very good testing indeed. Get the world's best testers together in one team and they'll be doing well to find 75% of the bugs.

[Brussels Slumdog]

And that knowledge is only in the hands of SAP Testers and can't be passed on quickly to others?

What do you do about this assumption that the SAP standard stuff works and doesn't need testing?

The knowledge of SAP testing is passed on to others during user acceptance testing (UAT) . These users are Accountants who wish to remain Accountants and Logistical users.
Its possible to be a test manager without knowing SAP or business processes.
As a SAP FICO consultant testing is only a part of my job. My role consists of business analysis,configuration,training,data migration and go live support.

If the standard stuff doesn't work it will be discovered during SIT and UAT testing

[BoredBloke]

I can do the vba easily enough. but get stuck at anything more than a vlookup.

Dynamic Named ranges are what you need to learn. So each time you change your data you don't have to alter the table within the vlookup.

I did a little graph thing yesterday that has a drop down validation list to select a cunk of data and then a load of dynamic ranges and index and offsets so that each time you change the drop down it references the appropriate bit of the data table and alters the graph accordingly, including the x axis. No VBA in it at all. The bloke next to me wanted me to code it up in VBA

[Mich the Tester]

'SAP Testers' test that a business process is configured and programmed according to the blueprint which means that you need to understand standard SAP and business processes. The standard stuff won't work without master data and configuration

And that knowledge is only in the hands of SAP Testers and can't be passed on quickly to others?

What do you do about this assumption that the SAP standard stuff works and doesn't need testing?

I'd want to see what happens if I make tiny mistakes in the master data and configuration if that's such a sensitive area. Do you test that? How?