Our blogger is a freelance front end web developer from Germany with the goal of building fast, responsive websites which work today and in the future — on every device possible, be it a laptop, smartphone, tv or fridge.
Rebecca Murphy’s JS development blog. She have spoken at dozens of conferences focused on front end development, including Front-End Ops Conf 2014, multiple jQuery Conferences, JSConf US 2013, JSConf US 2011, JSConf EU 2010, FrontTrends 2012, Fronteers 2012, and many others. Great blog for every front end web developer also from a great front end web developer.
Bug reporting may not be the most fun activity in the world, but doing it the right way by the right person is very helpful and efficient when it comes to optimizing projects. There have been some hideous attempts at bug reporting. Some, from sheer laziness. Others, from forgetfulness. And even some, from over-creativity because there is a multitude of ways you can produce a bad bug report.
A bad bug report would be one that isn’t filed in the right place. It may have useful, clear, and well thought out content but filing it in the wrong place isn’t the best way to communicate with a developer. An example of this would be sending a tweet or an email. Tweets can turn into long chats about finer details. Emails are bad because bug reports aren’t the only things popping up in them. It’s overall an unreliable and decentralized way to send a bug report.
Developers understand that their work won’t be perfect on the first try. It may initially compile, but there will always be bugs. As a user or a tester it is important that your bug reports are clear, concise, and informative. A perfect bug report is able to effectively tell the developer where, what, and how, so they can address it in a timely manner.
Here are some key points to writing the perfect bug report
1. Descriptive Title
This is the first thing seen by the developer. You want this to put the entire problem into context. Something like “The calendar doesn’t respond to home page navigation.”
You want them to know exactly what happens and be able to walk your soon-to-be best friend through the steps to re-create the problem. E.g. – “When clicking “calendar” on main menu of the “about” page, the calendar pops up. And when you navigate back to the “home page” with the top left icon, the calendar stays on the screen after you navigate, obstructing the view of the “home” page”. You want this to be under 140 characters to put the size and briefness into perspective.
E.g. – “When I click on the home page icon while the calendar is up I expect the calendar to close as I navigate to the home page”
4. What actually happened
E.g. – “The calendar stays up even after the site navigates to the home page and it obstructs the page”
5. What version of the software and what system are you using
Maybe they could be working on a new version that fixed that bug or they didn’t write it to be completely compatible with your system. Checking the smaller details like these are essential for saving time thinking about what could be a small issue.
This is a plugin that is meant to serve as a development ground for WordPress admin UI components, such as one might find in front end development frameworks such as Twitter Bootstrap or Zurb Foundation. Wordpress development is a lot harder without it.