Could I video-record your bug, please?


Have you ever video recorded your desktop while executing a test case and attached the video as a repro in your bug to the dev? I haven’t. I agree it sounds cool to be able to do it, but in 4 years of testing, I have never seen anyone do it either. Most people I talk to think it’s cool and proffer possible scenarios of usage, but no one seems to have ever used it at all.


Can someone who has used desktop recording and attached video files in their bug reports please reply or leave a comment as to why you guys love this concept? All feedback greatly appreciated!


Other senior testers I spoke to at MSFT seem to have a divided opinion on its usefulness, but I could not locate anyone who actually used it regularly. So, I spent some time thinking… why would I ever attach a video file in my bug repro? Because I couldn’t repro the issue again? Ummm….unlikely. If I can’t repro the issue I saw 5 mins ago, I couldn’t possibly expect my dev to do that looking at a lousy video. Perhaps the video’ll help me investigate the issue myself? Yeah – to a certain extent. Armed with the system info, event logs and stack trace info, this will be a great additional supplement. Also, if I were doing exploratory testing, it’ll certainly help me to remember how I arrived at the buggy state in my system and perhaps, help me trace that path again if I am lost. But like I mentioned above, so far, I have been satisfied with system info, event logs and system logs to point me to the buggy state. I see tools like Camtasia and Test Explorer even have audio recording thrown in along with desktop recording. So, someone has gotta be using these features!! Will that someone help me please?


 

Comments (11)

  1. Sumod says:

    Without going into too much details, the scenario is where you have to test a 3/4 tier system (connection to webserver and DB server etc). The client will have a slower network connection and their server and clients will be on different machines, possibly different locations. So the bug happens due to slow network connection. But the tester has the setup in house and hence has a faster LAN connection. So the tester cannot see the bug. If the tech support engineer attaches a video recording then you can actually see the bug in action.

  2. Thanks Sumod. That was a neat scenario. Perhaps, tech support engineers or for that matter even beta testers having the bug recording facility would be good in such situations.

  3. I.M.Testy says:

    So, in the example above, why doesn’t the tester test on various network connection speeds to better simulate ‘real-world’ scenarios.

    Instead of recording what is happening at the client (because I recording doesn’t tell you what their network connection speed or bandwidth limitations are so I am not sure how a video of the clients desktop will provide value.

    This is not to say that recording a client’s desktop may not be valuable in some situations, but I suggest we really think through the type of information necessary to best solve the problem at hand.

    • Bj –
  4. Chris Kinsman says:

    In many cases we have testers that cannot accurately describe what they did to cause the issue to happen.  The video helps document that and make it clear that they clicked on a certain area vs a button, etc.

    The problem we have is that to make it valuable it must always be running.  Most solutions extract such a performance penalty that isn’t realistic. Hence it is infrequently used.  

    We use Black Box today like this with our customers…

  5. I started typing up a response to Bj and Chris’ comments but realised that this is a post by itself 🙂 Next post dedicated to the two of you, folks!

  6. dbhat says:

    Video need not be used always to record a bug repro. In India, many companies provide testing services for clients in US and Europe. One such customer I met    said that they are investigating on how Video can be used as a proof of work done.

  7. When I see some of the tools available to "aid" testers, I alternate between shock and anger and disappointment!

  8. Ashish Maheshwari says:

    I had forced to use Video record my bug once ;).

    Developers could not reproduce the bug at there end which was constantly happening with me. Also they could not figured out by logs, Screen Shot and System SnapShot provided. So ulimately I had to take a 2 minute video of Steps and provided it with bug report.

    Result of this Instead of Cug being closed as Closed>CanNotreproduce, it was closed>Deferred. 🙂

  9. Hi Ashish –

    That was funny – I hope your mgmt did not push the vide rec tool as a mandatory one by citing the number of reductions in "No Repro" resolutions 😉

    BTW, I met you on the Software Testing Discussions, right? Glad you dropped in!

  10. Steve Nuchia says:

    When the bug in question is an aesthetic issue, especially a dynamic aesthetic issue, the video allows management to prioritize response without having to leave the bug tracking application and repro the bug from a (laboriously written) narrative.

  11. Norman Diamond says:

    Sometimes we received bug reports with attached videos.  I don’t know who decided whether or not to make a video, but it never really hurt to make one.  Around 50% were useful and 50% were useless but the useless ones don’t really hurt.

    Among the reports with useful videos attached, around 75% were user errors, around 15% revealed bugs that we hadn’t caught ourselves, and around 10% revealed bugs in APIs or drivers for which we had to add workarounds.  No matter which case it was, when a video was useful it was really useful.  Without them we would have needed a far longer time to investigate them and sometimes we wouldn’t have believed them.