Powering down DOMReactor

    The time has come to power down the reactor. We built DOMReactor with the ambitious goal of reliably detecting visual differences across browsers, and we worked hard towards that goal up until the end. Visual consistency testing remains a difficult problem to solve, but we are proud of the progress we made and the knowledge we have accumulated along the way.

    Binary Mechanics, the team behind DOMReactor, will continue working together to make it easier to test software, and we look forward to tackling the problem of visual consistency testing from new angles. We would like to thank everyone for using our software, and we look forward to showing you something new in the future.

    Cheers,

    Team BiMech

    Sharing reports with anyone

    Let’s say you are a developer and you want to quickly share a report for a test you just ran with your designer. Or may be you are a designer and you want to show the effects of a recent change to a developer on your team.

    How would you go about that?

    Up until today, there was no way to access this report without logging into DomReactor.

    Well, not anymore!

    From today onwards, you can go to the reports page and generate a shareable link to the report by clicking on the “Share Reaction” button. Just copy this link and send it to anyone who would like to show the report to.

    Anyone with this link will have a read only access to the report and won’t be able to make any changes.

    Here is a link to a reaction that we have shared within our company.

    We are thrilled with new feature as it allows us to seamlessly share reports with each other. We hope you find it as useful as we do.

    Until next time.

    Happy Testing,
    Your friends at DomReactor

    Bootstrapping - Part Time Pursuit. Full Time Focus.

    I have “liked” more funding news than I can count. And I mean it, as much as one can mean a digital like. It’s a small nod to a pretty monumental accomplishment in any startup’s life. It’s very cool. It’s validation.

    Money often defines success and someone giving you a bunch of it to give your idea a shot has got to feel pretty great. I wouldn’t know, because we are bootstrapped. We aren’t just bootstrapped, we’re part-time bootstrapped.

    There isn’t a load of cash or press releases or launch parties. We don’t often grab headlines - we aren’t bus crashes. We’re high blood pressure.

    When I was approached to get involved by Frank for creating Domreactor, our automated cross-browser UI consistency testing platform, there were some things I was immediately sold on. “This solves a need.

    Almost every company I know does this manually or mostly manually. It’s time and labor intensive in a field that often has little of either. Companies rightfully spend gobs on UI and UX and they want to guarantee consistency. What’s the point of that experience if IE9 on windows 2008 jacks it up?

    Alternatives were scant. There were a couple of other companies trying this. We felt we could do it better. I asked about his perception of cost, both in terms of time and dollars it will take us to get a usable product off the ground. He believed this was something we could accomplish in a reasonable amount of time without a load of capital, part time. On our own. “Bootstrap it”. He then slid me a copy of Rework from 37Signals. It’s a great read, full of non-traditional ideas, I recommend checking it out.

    Up until that point I did not know a lot about bootstrapping. I had worked a long time with alternative asset managers and I knew all about the “traditional” path. It did seem easy enough.

    Keep our day jobs, work on this nights and weekends.

    Boom, MVP in no time.

    No equity given up.

    No risk of losing your day job.

    No endless pitching business plans and ideas and groveling for cash and divvying up your shares and dignity.

    Early on, this notion was left unchallenged. We eventually brought on a third member, then a fourth. We worked when we could. I went to tons of events and panels and meetups for startups and entrepreneurs and techies. By far, the majority of the companies presenting and talking were companies that had pitched their ideas fairly early on and had gotten angel or seed capital. They were for the most part much younger than the 30-somethings we were.

    I met very few people in the same boat as us - *older and eschewing investment**. I thought, these people had taken the hard road. The stories of humiliating pitches, watching out for bad investors, handing over half your company, the constant fundraising, the lawyers. So many lawyers. Why jump through all those hoops when you don’t have to? There were not many bootstrappers to talk about the unique perils of bootstrapping.

    Shortly thereafter it began to happen. It wasn’t as easy as we had thought. This was actually a pretty tough problem to solve. No wonder only a few companies had tried tackling it.

    We went through a lot of code to create a prototype that was wasn’t all that useful in a production environment. Our app kept falling over like a drunk toddler with inner ear balance disorder.

    We talked to potential users. We pivoted. Then pivoted again.

    While having that day job afforded a financial sense of security, costs mounted in other ways. Time. Focus. Energy.

    If your day job is your startup you can put in those 8-12 hour days, go home and relax, unwind, or focus on other things (though I am sure many opt to not or feel they cannot). But when you’re bootstrapped, it doesn’t matter that you just finished a 70 hour work week, that you’re exhausted, or that you’d really rather have half a pizza, 3 beers and watch battle bots. You need to get to work.

    I wasn’t prepared for the mental demand. Typically you can use your nights and weekends, a few of them at least, to refocus and reenergize. We weren’t really afforded that luxury. When you don’t have this downtime, your work, both day and night, suffers.

    As much as time was an issue, the biggest one was pretty constant. It was life.

    And when you’re in your mid-30s you tend to have a lot of it. We had wives, kids, mortgages, car loans, dependent bartenders. At first it was easy. We were full of confidence, energy and enthusiasm. Friends, significant others and family were behind us. Giving us time and space and we gave ourselves the same.

    But as the months rolled on, the work would ebb and flow along with all that energy, confidence and enthusiasm. Patience would wear thin. Not just from others but with ourselves.

    Typically you can focus on your career M-F during the day and bucket everything else outside of that. But when those nights are taken up by your bootstrap, there are only so many nights you can go without quality time with the significant other or kids, only so many dinner times you can skip, household budget concessions to make, only so many instances of asking others to pick up the slack in your home and personal life to accommodate your endeavors.

    We had one original member bow out due to the real demands of 2 kids and a new house. When hard decisions on priority need to be made, it becomes easy for others to look at a part time bootstrapped venture as possibly less “serious” an undertaking than a full time gig. If you’re not fully invested in the startup, how serious could it be? In fact it was easy for me to think that way and lose focus and momentum.

    But it never strayed much down the list or from our minds and eventually we regained our focus, cleared a path and pushed to make Domreactor a reality.

    It never hurts to have affirmation. Todd Connor, co-founder of Flank5 Academy and Bunker Labs gave a speech at Fund Conference. He spoke about getting to revenue without taking investment. It was the talk I enjoyed the most. Not only because he gave tips on how to get to there, but because of his belief and enthusiasm that there is another way that many people don’t really consider. In the context of a conference meant to mingle startups with capital, this stood out even more. It’s a valuable message and one I never tire of hearing.

    When I do meet other bootstraps that have launched, I always get a little more excited. We should have a handshake or something.

    The trials of launching a startup, particularly a bootstrapped one, led to an unexpected outcome. It actually helped me discover where my limits were in terms of a work/life balance. As they bleed into each other so completely in this kind of lifestyle, hard limits were needed.

    An expected outcome was that when we finally had our production launch, we took satisfaction in knowing we created something valuable completely on our own and put ourselves in a better position as a young company going forward.

    No headlines.

    No launch parties.

    Just product.

    Weekly Update #5

    Happy Monday!! Hope you all had an amazing weekend.

    Here is a quick update about some of the improvements we made to DomReactor this past week. Also, here are some interesting articles to get your week started. I hope you enjoy them as much as we did.

    What we are reading this week

    The Internet of Things. And Testing.
    Andrew Antal, our CEO, wrote a candid post about “Internet of things” and testing in general. As more devices are connected and new platforms are brought on, handling the consistency of that experience will be a pretty big problem. DomReactor might be a great first step to that.

    Ludicrously Fast Page Loads - A Guide for Full-Stack Devs
    Your website is slow, but the backend is fast. How do you diagnose performance issues on the frontend of your site? We’ll discuss everything involved in constructing a webpage and how to profile it at sub-millisecond resolution with Chrome Timeline, Google’s flamegraph-for-the-browser.

    Accidental Leadership
    “The biggest challenge for us was to remove the predefined baggage that came with separating responsibilities, and making sure we were clear that company strategy was always a joint effort.” - Natalie Nagale

    Lessons from the Woman Who Built Squarespace’s Customer Care Team from 1 to 184
    Superb customer care translates into great word of mouth. The trust of your customer is not only what’s at stake; it’s the potential conviction of each customer’s network, too.

    Notes on Startup Engineering Management for Young Bloods
    Put one foot in front of the next. Keep going. Be open-minded. Be curious. Read about what other people are doing. Make friends who are running tech at other companies. Be kind to yourself, even if you fail. You have the power to make the world better for all of those people on your team. Use it responsibly.

    The Fear of Failure Can Be Paralyzing
    When you step into unknown territory, the paralysis is a natural thing to happen. When you don’t know what’s going to happen, the simplest thing for us is to stay away from taking the plunge. I know this feeling very well, and I’m finding myself faced with it again right now. It gets even harder when it stops just being you, and when other people’s income and supporting their families is on the line.

    An employee handbook built for inclusion
    Clef just open sourced their entire company handbook. The document includes Benefits and Perks, Employment Policies, Onboarding Documents, Hiring Documents and pretty much everything you need to run a company. Kudos to them for being so transparent.

    What we shipped this week

    Fix reactions that have no associated report (Bug)
    We found an issue around reactions that were either still running or didn’t have an associated report. If such a test existed, the dashboard page was not loading and threw an error. That has been fixed now and dashboard will load irrespective of the status of the the reactions on the page.

    Generate a shareable token for every reaction (Bug)
    Shareable token was not getting created when the reaction was kicked off. This resulted in an invalid link getting generated for sharing reactions. However, we have fixed this issue so that the shareable token gets created properly and a valid link to share a reaction is generated.

    Happy Testing,
    Your friends at DomReactor

    The Internet of Things. And Testing.

    Last week I went to an event hosted by General Assembly Chicago on the Internet of things(IoT). The panel opined on a range of topics covering wearables, data analysis, what to do with said data, privacy, Opt in networks vs Opt Out networks (interesting), and possible federal regulations. But the 2 things that stuck out to me were the social cost of connectivity on cultures (really interesting and for sure a topic for another day) but also managing the consistency of user experience across all those platforms. Coleman Collins at Thoughtworks brought this up. It was an aside at the start of the panel, but it got me thinking - How big is this problem today, and how big will it be in the future?

    My immediate responses were: not too big and massive. IoT has yet to completely pervade our lives. While we have cars, watches and fridges that remind us to slow down, walk more and stop buying hot pockets: this isn’t commonplace yet. We have yet to have a google toilet that reads your emails, texts and also tells you to stop eating hot pockets. I also think a large segment of the population will actively resist this movement and decide laptops and smartphones are as connected as they want to be. That makes a product like Domreactor pretty relevant and useful today and for the foreseeable future.

    In automating UI consistency testing of web sites and apps over desktops and mobile, we cover the most important platforms. And UI is still one of the most important mediums a company can express a user experience and its brand.

    But as devices are connected and more and more platforms are brought on, handling the consistency of that experience, as Colemen pointed out, will become very difficult. How do you maintain that same experience for your brand across laptops, tablets, phones, glasses and toilets? We already have a fairly broken and disjointed state when it comes to mobile testing alone.

    This felt like an overwhelming problem. But I am kind of an idiot so I felt it best to ask Coleman his thoughts. Thankfully he said it’s exactly this problem that keeps him up at night. It’s a big issue. I felt better. I may not be an idiot (tbd). Next question, how do we tackle it? “I don’t know”. He said automation, akin to what we are doing with Domreactor, will certainly play a part, as well as understanding there is an allowable amount of acceptable deviation a user can tolerate without eroding the experience and figuring out what that is. My gut feeling is that it will take a confluence of automation, end user input, and design to overcome this consistency of experience in an IoT world.

    I really liked his “I Don’t Know” answer. First of all it meant I didn’t miss out on any big news I should probably be tuned into. But mostly because this means there is opportunity there. At Binary Mechanics, we are betting on the technologies of machine learning and image analysis (like computer vision) will continue to grow at a pace on par with that of the IoT. When we let our minds wander towards what we can provide in the long term, it’s not too hard to think of Domreactor as a first step in a new, exciting and comprehensive way to test consistency across multiple platforms of all kinds.

    Stay posted.

    Weekly Update #4

    Happy Monday!! Hope you all had an amazing weekend.

    Here is a quick update about some of the improvements we made to DomReactor this past week. Also, here are some interesting articles to get your week started. I hope you enjoy them as much as we did.

    What we are reading this week

    Here’s Why Founders Should Care about Happiness
    “There’s a common assumption, that you will be happy when you are successful. But the reverse is actually true, and not just anecdotally. Hard neurological science supports the idea that happy people have more capacity to succeed. And beyond that, that happiness is not a genetic mandate, or a product of circumstance. It’s a choice.” - Scott Crabtree

    How to Create Company Values That Mean Something
    You have to look beyond the superficial labels and words that comprise your values and into the purpose and history behind them. That’s the only way we’ve been able to resolve seemingly intractable conflicts.

    Always Improve, Never Stop, Never Pause, Never Appreciate
    Taking a moment and a step back to reflect and appreciate what you’ve already achieved can be a much more powerful and energizing experience than always looking for more things to improve.

    Using imagemagick, awk and kmeans to find dominant colors in images
    A neat little article about how you can find dominant colors within images. This is something that we deeply care about. We might end up using this for generating the colors of the bounding boxes on the screenshot comparison tool.

    How to scale your company culture
    What do these values actually mean, though? If I’m a new employee coming into an organization, am I expected to know how to convey these values? No. Of course not. That’s why companies instill their cultural values in all kinds of different ways. For example, at Facebook the value “moving fast and breaking things” is introduced during onboarding. But instead of just telling people to “move fast and break things,” Facebook sends all new employees off for 6 weeks to literally code new things, break things, and learn from seasoned “fast movers and breakers”.

    Not Wanted
    Instead of focusing on trying to sell more stuff to people who have plenty of that stuff, I focused on the people who don’t yet have these tools or experiences.

    No, I do not subscribe to the Church of the Nonstop Hustle’s teachings
    Evenings spent without work, a relaxing weekend (even if just one day), and time spent away from the office should be seen as a net gain for your brain and be encouraged.

    What we shipped this week

    Share a reaction and its reports (Improvement)
    You can now share your reaction and its reports with anyone by sending them a link to the report. You can generate this link from the reports page. Anyone with this link will be able to view the report without logging into DomReactor. However they will only have read-only access to the reports and cannot make any changes.

    Autocompletion of URLs on the new reaction page (Improvement)
    On the new reaction page, DomReactor will now try to autocomplete your page URLs based on URLs you have already tested against. This will make kicking off those tests even faster.

    Happy Testing,
    Your friends at DomReactor

    Weekly Update #3

    Happy Monday!! Hope you all had an amazing weekend.

    Here is a quick update about some of the improvements we made to DomReactor this past week. Also, here are some interesting articles to get your week started. I hope you enjoy them as much as we did.

    What we are reading this week

    Put an end to feature creep
    This interactive post by the smart folks at Intercom talks about how to say to no to new features and instead work on improving your current application.

    Strategic Apathy
    By deploying strategic apathy when appropriate, you’re not really giving anything up: you’re just making it more difficult for the world to distract you with shiny, worthless baubles.

    Do fewer things well
    Having a productive day starts off by generally understanding the important goals you are working towards and blockers that will get in your way. This doesn’t start on the particular day but actually days, weeks, and months beforehand by doing a few things well.

    Give it five minutes
    Dismissing an idea is so easy because it doesn’t involve any work. You can scoff at it. You can ignore it. You can puff some smoke at it. That’s easy. The hard thing to do is protect it, think about it, let it marinate, explore it, riff on it, and try it. The right idea could start out life as the wrong idea.

    When do fans get hooked on TV shows
    A new study reveals when viewers get “hooked” on their TV shows, which episodes lead to binge-watching? Netflix examines “when fandom began” for 25 different series.

    The one secret thing that all successful people do
    Summarizing this would be a disservice to our readers.

    Cargo Culting
    As we are designing something, are we just cargo culting an experience we take for granted somewhere else? Do we understand the actual job someone wants to do with the thing we are designing? Are we designing to be consistent with a pattern our users expect at the expense of figuring out how to help them kick more ass?

    What we shipped this week

    Show all tests on the dashboard (Improvement)
    We made an assumption early on that people don’t want to share the tests that they are running with other people in the organization. And boy were we wrong. So we fixed that. Now, on your dashboard, you can actually see all the tests that have been run by your team members.

    Improvements to the dashboard UI (Improvement)
    We have made some tweaks to the dashboard screen so that the information displayed about each test is more relevant and intuitive. We have added specific columns to display the baseline and comparison browsers along with the total number of differences that were found during the test.

    Happy Testing,
    Your friends at DomReactor

    Weekly Update #2

    Happy Monday!! Hope you all had an amazing weekend.

    Here is a quick update about some of the improvements we made to DomReactor this past week. Also, here are some interesting articles to get your week started. I hope you enjoy them as much as we did.

    What we are reading this week

    The Right Way to Ship Software
    In a profession where we carry out decade-spanning holy wars over tab widths and capitalization, it’s no surprise that people get attached to their development and release habits. But if shipping so much software has taught me one thing, it’s to be an agnostic. Different methodologies optimize for different goals, and all of them have downsides.

    7 Rules for creating gorgeous UI(Part 1)
    If you went to art school or consider yourself a UI designer already, you will likely find this guide some combination of a.) boring, b.) wrong, and c.) irritating. But if you are a Developer or UX Designer, this article is for you.

    7 Rules for creating gorgeous UI(Part 2)
    Follow up to the above mentioned article. We’re talking about rules for designing clean and simple UI without needing to attend art school in order to do so.

    How to Know What Advice to Take (And What to Ignore)
    It’s easy to get overwhelmed by advice, and just as easy to forget to think for ourselves when smart people tell us what they would do.

    7 Rejections
    “In 2008 we were raising $150,000 at a $1.5M valuation. Here’s the response. Think of this next time you’re rejected.” - Brian Chesky (CEO, Airbnb)

    Slack’s $2.8 Billion Dollar Secret Sauce
    Slack acts like your wise-cracking robot sidekick, instead of the boring enterprise chat tool it would otherwise be.

    Disruption is better when it’s other people’s jobs
    The sooner you stop fighting the present, the sooner you can get to work on figuring out the future.

    What we shipped this week

    Improve the URL Validation (Improvement)
    We can now work with web URLs with special HTTP Headers or self signed SSL certificates.

    Improve the browsers list view (Improvement)
    We have improved the browser list on the Account Setting page to be more intuitive. It is a lot more easier to find and add browsers now.

    Fix screenshot rendering on Reports (Bug Fix)
    We have fixed a bug on the report page where sometimes the screenshot was being rendered after the bounding box for the differences had been loaded. This would cause the bounding boxes to become hidden behind the screenshot.

    Happy Testing,
    Your friends at DomReactor

    Weekly Update #1

    Happy Monday!! Hope you all had an amazing weekend.

    Here is a quick update about some of the improvements we made to DomReactor this past week. Also, here are some interesting articles to get your week started. I hope you enjoy them as much as we did.

    What we are reading this week

    GitHub: Scaling on Ruby, with a nomadic tech team
    Github is actually a really pragmatic set of hackers that just hack on Ruby, hack on C and spend their time working on more interesting things using a more stable stack, rather than chasing after the latest and shiny tech.

    From Products to Platform
    Apple’s declaration that “The Future of TV is Apps” is a very compelling one, but the degree to which that vision is realized is inextricably tied to the prospects developers have for making money.

    Don’t embrace failure, embrace discomfort instead
    Instead of getting okay with failure, we should all work on getting okay with discomfort. Because once we’re okay with discomfort, we’re okay with — for most of us, the single hardest part of starting a business.

    How we support 1650 customers with one just rep
    Being able to support this many customers with just a single full-time support rep is the result of many small decisions. It’s the cumulative affect of tweaking copy, highlighting a subtle requirement, and trimming the interface down to the essential parts.

    Do the simple things first: the engineering behind Instagram
    “Doing the simple thing first started as a survival tactic, and became a mantra. Today, that phrase is burned into brains of all my engineers, which is awesome.” - Mike Krieger (CTO, Instagram)

    Speed as a habit
    When you think about it, all business activity really comes down to two simple things: Making decisions and executing on decisions. Your success depends on your ability to develop speed as a habit in both.

    What we shipped this week

    Performance fixes to the report page (Bug Fix)
    We just made some improvements to the report page. We are now able to load each report page 3 times faster.

    Disable Chrome 43 on Linux (Bug Fix)
    There is an issue that we are investigating currently with Google Chrome version 43 on the Linux operating system. There are high number of false positives being reported during the DOM parsing and we have not been able to get to the root cause yet. For the time being we have disabled running reactions on that particular version of Chrome. For more inquiries feel free to reach out to support@domreactor.com

    Improvement to our analysis algorithm (Improvement)
    We have further improved our analysis algorithm to narrow down the false positives. It’s a small win but we will keep improving our analysis strategy.

    Adding Pagination on the dashboard (Improvement)
    We have added pagination to only display 20 reactions on the dashboard page. We hope this would be a better experience for our users.

    Happy Testing,
    Your friends at DomReactor

    Did you know you can get started with DomReactor for free.

    Make your tests resilient to browser focus

    Focus-related test failures can be tricky to diagnose. One moment your tests pass, the next moment they fail. Same code, same data, no race conditions or timing issues, and yet intermittent failures crop up. I encountered this recently while tweaking a test suite to support Capybara-Webkit, which is a headless Webkit driver for Capybara. Previously, we had only been using the Selenium driver and we wanted to add support for both local and remote headless execution.

    After I had ironed out all of the configuration related issues, I noticed that tests executed with headless Webkit were not intermittently failing, as they were with Selenium. At that point I realized this was almost certainly a focus-related issue, as a Selenium-controlled browser is much more susceptible to losing focus than a headless browser. Sure enough, when I dug into the code I noticed that we had a web form with input elements that were dependent on blur events firing to complete their business logic. Without browser window focus, Selenium cannot conventionally trigger blur events, and tests start behaving strangely.

    It was especially difficult to diagnose the blur issues with the test I was working on because visibly (and network-wise) the test appeared to be doing what it was supposed to do. The text inputs were populated with the correct data, the submit button was pressed and an AJAX request was made to the server. The response from the server, however, was incorrect. Digging into the code further, I noticed the blur event handlers were designed to incrementally augment the AJAX request. As the events were never getting triggered, the request was never augmented and instead a default request was made, which of course returned a different response.

    The solution ended up being somewhat heavy-handed, but necessary: trigger the events manually with JavaScript. So where previously I was doing something similar to:

    fill_in "Foo", :with => "bar"

    I was now doing:

    fill_in "Foo", :with => "bar"
    page.execute_script("$('#foo').blur()")

    I was also using the excellent SitePrism page object library, so I was able to wrap those two steps in a simple method. It was a small change that made all the difference; tests now ran reliably whether the browser had focus or not. I view this solution as a fight-fire-with-fire approach. Injecting JavaScript into an automation sessions isn’t really a legitimate representation of user interaction, but it is also not possible for a user to enter text when the browser does not have focus, but Selenium merrily does so anyway. If Selenium is going to bend the rules of user interaction, you shouldn’t feel bad about bending them back to get your tests back into a stable state.

    Simplify your acceptance testing environment with puffing-billy

    Automated browser-based acceptance testing is a valuable but costly undertaking. There are costs associated with execution time, test maintenance and environment configuration. If the application under test also happens to have a service oriented architecture, the costs of test-environment configuration can multiply. Lately, I’ve started using puffing-billy to reduce the number of dependencies needed to run automated acceptance tests.

    If you’re familiar with tools like VCR, you’ll catch on to puffing-billy quickly. By it’s own estimation, VCR enables you to “Record your test suite’s HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.” Indeed, VCR allows you to mock HTTP requests to eliminate a test’s dependance on external resources. This allows your tests to run faster, and you always retain the ability to disable mocking when you want to exercise the integration of services.

    Puffing-billy now provides similar HTTP mocking functionality. It sits between the browser and the web app server and acts as a proxy. When an HTTP request is made to the web app server during an automation session, puffing-billy intercepts the request and can return a mock response if you tell it to. Similar to VCR, this mocked response is essentially a cached response of a previous HTTP interaction, so the client consuming the mock is none the wiser.

    This mocking ability is particularly useful when running browser-based acceptance tests against an SOA. For instance, let’s say the client-side app makes an AJAX request to the public server-side app for a JSON object. To construct that object, the public server might in turn have to talk to one or more private services. So, to get this test running in a continuous integration environment such as Jenkins, you must have the full stack of every service dependency up and running. That’s a lot of configuration and maintenance for just responding to the client with some JSON.

    Instead of getting your entire architecture chugging when you want to run a few Capybara specs, just have puffing-billy serve up cached responses of previous HTTP interactions. With this approach, your acceptance tests can run in CI without having numerous backend services on-line. All client-side requests can be satisfied by the puffing-billy proxy. Just as with VCR, when you want to do full-stack integration testing just disable the proxy and your acceptance tests magically become indirect integration tests.

    I contributed to a puffing-billy pull request that was recently merged in which adds some enhancements for using the tool with an SOA, and I’m excited to have this in my toolbox. As more and more web apps continue to beef up their client-side, it’s a great opportunity to find ways to simplify acceptance testing of those clients.

    Holistic cross-browser testing at Selenium Conf

    Here’s the full talk we gave at Selenium Conf 2013 in Boston. In the talk we discuss how to take an integrated approach to cross-browser testing. Enjoy