Q:

Scrum, but with no testing or documentation

What do you do when you join a team that says they use Scrum, but only use it as a time-management tool and not the whole process?
How can I reinstate back testing and documentation?
I was thinking to start off with adding user stories specifically for testing and documenting.
Perhaps someone else has more experience with this then I do about this as I am sure its not that uncommon.

A:

Is the issue that they don't have any documentation and tests, or that they aren't implementing the entire Scrum methodology?  Those are 2 very different problems in my mind.  
I would much prefer an organization that has taken the time and effort to find and fit a development process that matches their development style as opposed to mandating down from on high the one true process.  So I would not be concerned at all if they were using a process that they called Scrum but that didn't meet all the "official" guidelines.  Try to determine why the process is the way it is.  Chances are that if they have taken the time to tailor it, the team will be receptive to your ideas, especially if you have taken the time to determine why things are the way they are.  If you simply approach it as "this isn't Scrum and so isn't right", you will probably not make much headway, but by being pragmatic about the benefits you can likely make some substantial improvements.
Alternatively, if they aren't doing testing and don't have any documentation I would consider that a fairly bad sign.  And by documentation I am taking the minimalist view here - a list of features, bug tracking, etc. - I would be very concerned by the absence of these items, less concerned by the absence of items higher up the abstraction list.  In the absence of support from management, I would suggest you lead by example.  Take it on yourself to setup a simple bug tracking system (there are several - in a pinch, simple text lists in a central location work as well).  Don't declare your features complete until someone else has tested it.  This can be as simple as walking over to another developer and asking them to try it in front of you.  If someone claims a feature is complete, take a few minutes to familiarize yourself with it.  If you find a bug, politely mention it to the responsible developer.  Slowly build an environment where the team can see the benefits of running tests and tracking features and bugs.
Most teams operate in this manner simply because of a mistaken belief that they don't have time to "do it right", or that they will get to it later.  Often this will occur when a simple proof-of-concept done by a developer or two as a side-project turns into a full-on development effort.  By showing that it can actually save time and effort, and reducing the initial costs to the rest of the team, you will often find that it becomes ingrained as part of the process without ever actually being officially endorsed or accepted.
If you have management support it will make it much easier, but always be careful to make sure that the team is receptive to the changes.  This may mean it takes longer than you want, but so be it,  without the team's support any mandated process will fail at the first sign of pressure, which is when you need the process the most.
*Disclaimer - On my last project I spearheaded the movement to tailor the SCRUM process to fit our environment.  The "official" process was simply untenable for our client, but it was still an invaluable guide in tailoring our process.  

