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!
How is the business not maintaing data a SAP functionality issue. Not too mention, if they filled in some bollux port in the delivery, how did the customer ever get their product?
Spot on .... Mich you should change your name to "Mich the user"
Spot on .... Mich you should change your name to "Mich the user"
Not at all. It's a functionality issue; too much functionality, too many input fields and too many process steps for the context in which the user works. Plus, it's slow as hell, which is a technical issue, not functional.
A tester from the context-driven school of testing would have found this. One of the TMap scripting crowd wouldn't.
And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014
If you force a user to fill something in, he will fill something in.
If you force someone to spend a lot of time on something he doesn't have time for, he will find a way of spending less time on it.
If you force someone to do something complicated and boring, he will find a way of making it easy and fun.
You have very little control over what 'something' is.
And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014
If you force a user to fill something in, he will fill something in.
If you force someone to spend a lot of time on something he doesn't have time for, he will find a way of spending less time on it.
If you force someone to do something complicated and boring, he will find a way of making it easy and fun.
You have very little control over what 'something' is.
True, but these are issues that should have been solved during design & implementation. This is what happens when you use piss-poor consultants who don't understand the business or process.
Allowing a trader to select a 'dummy' customer is unforgivable. How did they ever get paid for the trade?
True, but these are issues that should have been solved during design & implementation. This is what happens when you use piss-poor consultants who don't understand the business or process.
Allowing a trader to select a 'dummy' customer is unforgivable. How did they ever get paid for the trade?
They e-mailed the admin people to send an invoice.
You're looking at this from a traditional IT point of view, going through business case, design, build, test, acceptance etc; that whole process has a fatal flaw; it assumes that the user knows what he wants. The user doesn't know what he wants; he has a vague idea of how he wants his business to work, but really doesn't have a clue of how to get the technology to support that. A tester who is restricted to only testing and reporting functionality cannot give that user the information he needs, which is what risks are associated with going into production and what possible benefits there will be. The tester has to break out of his IT mindset and place himself in the shoes of the user and the business owner; don't just test the screens and the batches, but test the whole thing; application, business, interaction with the ouside world etc. I actually don't care if an issue is technical, functional, business related, user related, support related, design related etc; it's an issue, and thereby forms a risk for the customer. Working out how to categorise and solve the issue is the next step.
And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014
I've two projects involving HR BW data munging. For both, the timesheet is an Excel spreadsheet. I get all the kerching for working with SAP HR, and none of the hassle of actually having to use it.
Comment