Wednesday, October 12, 2011

Take a BITE out of Bugs and Redundant Labor

In a time when more and more of the web is becoming streamlined, the process of filing bugs for websites remains tedious and manual. Find an issue. Switch to your bug system window. Fill out boilerplate descriptions of the problem. Switch back to the browser, take a screenshot, attach it to the issue. Type some more descriptions. The whole process is one of context switching; from the tools used to file the bug, to gather information about it, to highlight problematic areas, most of your focus as the tester is pulled away from the very application you’re trying to test.

The Browser Integrated Testing Environment, or BITE, is an open source Chrome Extension which aims to fix the manual web testing experience. To use the extension, it must be linked to a server providing information about bugs and tests in your system. BITE then provides the ability to file bugs from the context of a website, using relevant templates.

When filing a bug, BITE automatically grabs screenshots, links, and problematic UI elements and attaches them to the bug. This gives developers charged with investigating and/or fixing the bug a wealth of information to help them determine root causes and factors in the behavior.

When it comes to reproducing a bug, testers will often labor to remember and accurately record the exact steps taken. With BITE, however, every action the tester takes on the page is recorded in JavaScript, and can be played back later. This enables engineers to quickly determine if the steps of a bug repro in a specific environment, or whether a code change has resolved the issue.

Also included in BITE is a Record/Playback console to automate user actions in a manual test. Like the BITE recording experience, the RPF console will automatically author javascript that can be used to replay your actions at a later date. And BITE’s record and playback mechanism is fault tolerant; UI automation tests will fail from time to time, and when they do, it tends to be for test issues, rather than product issues. To that end, when a BITE playback fails, the tester can fix their recording in real-time, just by repeating the action on the page. There’s no need to touch code, or report a failing test; if your script can’t find a button to click on, just click on it again, and the script will be fixed! For those times when you do have to touch the code, we’ve used the Ace ( as an inline editor, so you can make changes to your javascript in real-time.

Check out the BITE project page at Feedback is welcome at Posted by Joe Allan Muharsky from the Web Testing Technologies Team (Jason Stredwick, Julie Ralph, Po Hu and Richard Bustamante are the members of the team that delivered the product).


  1. Cool! Some of this functionality I had hoped to get out of Atlassian's Bonfire, but being reliant on other non-Atlassian test tools for our team, integration wasn't feasible.

    You don't give specific server constraints, but are there any? Can you give more information about what servers are or aren't supported? Is there any kind of bug attribute schema mapping necessary or something?

    Either way, sounds like a great tool, can't wait to try it out. Way to go, Richard!

  2. Can you talk a little more about how to set up a server? I see the wiki page with the method requirements, but I'd rather not write something up from scratch if I can avoid it....

  3. Thanks for the comments!

    What we've open-sourced is the client portion of this tool. There is documentation so that a motivated developer could create a reference server, but the server that the tool is tied to internally is coupled to internal systems and products in ways that makes open-sourcing the server infeasible.

    There aren't really many requirements on the server, which basically has to act as a bridge to get bug data to/from your actual data source. (By design, BITE's server shouldn't actually store bug data). Capability-wise, the server just needs to be able to deal with HTTP requests with JSON data.

    To Jacob's question, there is a wiki page on the project site with information about the schema the server expects (including the mapping of BITE's "important" bug data).

    To Joe Helfrich's question, as noted above, we've open-sourced the client only. We've worked to provide enough documentation for the community to create their own servers (in which most of the code is specific to your actual Bug provider), but there are no plans at this time to specifically release an open-source server.

  4. I have been looking at what's involved to write a server for BITE, with some sample code that gets the initial bits of client UI to display.

    Is anyone else out there interested or doing something similar? :) At the moment I've been hacking something up in Perl, with the vague assumption that it will be easiest to target Bugzilla first.

  5. iam not clear how to use this ? can some one throw more light?.can i start using this now?

  6. @Tim I'm in the very early stages of doing the same thing for Trac. (So early that I'm still reading up on the Trac API to see if it's even possible, while hoping someone else will beat me to it.)

    @sasikumar Not yet, apparently--the plugin needs a backend, and Google chose not to release that, so you're going to have to implement a solution yourself, or wait for the community to come up with one.

  7. @Tim - You're awesome! Thanks for taking initiative on this and let us know if you run into issues.

    @sasikumar - Yes, but it takes some work. You need to download the source code, install the dependencies, and build the project to get it running. There's more information about how to do so following the link below:

  8. How to configure the server? can anyone help me!

  9. how to configure the server.
    can anyone post as how to implement the project.. help of any kind is appreciated

    thanks in advance

  10. Any one successful with this server!

  11. @jinu - did you try latest download her ,

    let me know if you are sucessful.I will try it mean while

  12. I like this. How does the information/bug get processed? Is there a bug database behind it?

  13. Hi
    1.i'm able to configure the server (app engine and deploy the same)
    2.i was able to install the extension as well

    the issue i'm facing is i'm unable to connect my extension to the server
    i'm getting
    "try logging in error"

    can anyone help me on the same

    thanks in advance

  14. I have been successful with the server but I need to know has anyone connected this to a jira system

  15. Is Google still using this system?

    Will this be supported by Google if we want to use it?
    I see that there are no updates on this project since beginning of 2012

  16. We're not actively developing this tool anymore and won't be available for support issues. However we did release it to the open source community so others can take on bugs, add features, and so forth at

    The last commit was on April 22 2013, and there's periodic activity.


The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.