Phone line tester does not warn users that the test is intrusive!

[#1]

Performed a phone line test this evening (intermittent crackling) and was fairly impressed with the automated testing ... until I realised that the "this will take a while" message was going nowhere.  I then checked the BB connection only to find there was none.

After the connection was restored the test screen reported

Oops, something seems to have gone wrong

Indeed it did!  There is no evidence (visible to me) in my tickets that the test was run ... and failed as does happen with BB testing.

The phone line test advises users to not use the phone - it does not explicitly indicate that this is an intrusive test which will impact broadband operation.

Given that broadband operation is impacted then the test can never report completion successfully to the user.  May be there should be an instruction to run the test via a different connection - e.g. a mobile phone.

[#2]

Thanks for flagging that up, I'll pass the feedback on to the relevant team.

As for the message you receive at the end of the test, I believe that you'll get that regardless of the test result even if you completed the test on a different connection. That's something I think is already flagged and being looked into.

Anoush

[#3]

What does that imply for the effectiveness of the auto test? Does it actually report a result to anywhere?

[#4]

If the line test detects an external issue, it will report the fault to Openreach and raise an open ticket on the account for our faults team to follow-up after the initial response time.

If the line test detects no issue or an issue that requires an appointment, nothing will happen.

[#5]

So if the latter condition arises one just gets the "Ooops" message?

If that's the case as an expedient improvement can a message be added to to say something along the lines of "The automated testing did not find an issue which could be automatically reported to BT. Please contact support for further information as an appointment might be required.".

In the meantime I'll return to my intermittent crackling line next week.

[#6]

I'm not convinced that error should ever be seen, irrespective of the outcome. Also not convinced the testing is intrusive as far as the BB connection is concerned, although I could be wrong.

[#7]

I may be wrong but I believe the test is intrusive on ADSL but not FTTC.

I'll see if it drops mine when I go home although ideally I don't want to kill my 95 day+ connection

[#8]

Neither did I - it might not be intended to be intrusive, but it did kill my session.

[#9]

Unless I'm mistaken, the phone troubleshooter runs the same line test that we run in WLR3 [staff reference] and usually always drops the ADSL connection. Occasionally, it can drop an FTTC connection.

[#10]

In which case how is the test page supposed to 'pick up' again after restoration of the connection (if it does reconnect)?

Assuming it can 'pick-up' again would a change in IP address impact the operation?  I'm thinking of session states here.

Should there be a recommendation that this customer test is NOT run over a connection which is using the phone line being tested?

[#11]

In my experience, I *think* once a line test has begun, it will complete even if the test is cancelled or interrupted part way through.

[#12]

How do we find out (for sure) what does happen and see if the user experience can be improved?

My perception / understanding is that...

1. The test broke the broadband connection

2. After a long delay seeing "This might take sometime" I see a failure message

3. The failure message can also mean a fault was detected which requires an appointment and therefore contact with support

4. Only if an external fault is identified will a ticket be raised - otherwise no footprint is recorded of the test

At the very least I suggest that the "error" message could be improved to indicate that a fault requiring an appointment was identified.

[#13]

I be 100% sure what the troubleshooter is designed to do without investing a bit of time looking into it.

One thing I am certain of though, is the fact that the non-descript error messages are *not* intentional.

This thread is relevant (and the one linked there-in), where @PlusnetLiam seemed to show an interest?

I'm of the opinion something is broken, rather than there being a design omission e.g. I have just run a no dial-tone test on my own fibre circuit and received the 'Oops, something seems to have gone wrong' error. My PPP connectivity remained uninterrupted throughout and there's zero audit trail/tickets raised on my account.

Having said that, it's not out of the question that the different tests might return different results:

[#14]

Hi guys - cheers for flagging up @bobpullen

I'm very interested in the performance of this piece of kit & have been investigating it with our tech teams for a while as had a hunch it's not been doing what it should.

Any examples that I can pass to them would be appreciated but I do believe this (and the BB Fault Checker) needs some work and would feed in to the project I mentioned before about a consolidated Troubleshooter.

Liam

[#15]

@PlusnetLiam, it definitely used to work up until fairly recently. In fact, I don't think I've ever known there to be problems with it (it's historically been one of the better self-serve tools we have).