February 21, 2011

QA Teams, Truth or Myth?

This article was originally published in php|architect in May 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better.

In the last couple of years, there seems to be a growing trend in the PHP world where application and library developers put out claims that their piece of code is high-quality and thoroughly tested. Indeed, often this is true, but how can you really guarantee quality like this?

Quality Assurance, What Is It All About?

You might wonder, what is Quality Assurance (QA) all about? Is it something you might want to start utilizing for your project?

I don’t want to go too deep into this topic since this is a mere short article but QA can be so many different things depending on who you ask. I’m going to take the plunge and attempt to give my thoughts on QA teams and hopefully enlighten you in one way or another along the way.

The QA Team

So what is the QA team? They are the keepers of quality, those who aid the developers in maintaining the balance between productivity and chaos, these are the people who strive for perfection – The QA Team *cue theme song for “The A team”* Modern day heroes.

From my perspective, the responsibilities that a QA team would take on range from monitoring the ticket system, gathering more accurate information for tickets, verifying tickets, and making sure developers are upholding the coding standards, and any other standards, the project is employing, just to name a few.

One important purpose of QA teams is to think up new ways to make it easier for developers to adhere to the standards, to make it really easy for end users to report issues and to find information they need to reduce duplicate reports or invalid ones. To create a better end-user experience usually requires the QA team to bother the developers to write proper API documentation and harass the documentation team to produce a proper user manual. In many projects, the QA team will also deal with the tests – Writing user stories based on the specifications (if they are so lucky to have such a thing) so that the developers can write accurate functional and unit tests. This will also allow the QA team to do proper verification before releases and sprint closures.

QA teams are an impartial third-party, they have an outside perspective on the application. The problem with developers is that they don’t make good users due to how close they are to the product. They know what can be done and what can’t be done and are thus less likely to be as creative as end users when it comes to using/testing the product, QA is the bridge between the two.

QA will point out things that work but are not as clear or obvious as they could be, e.g. obscure error messages, unintuitive interface (be it user interface or API design) or finding fragile code where something is a little off and ends up blowing up in your face.

This is just the tip of the iceberg and, as you may have noticed, QA teams need to able to touch every aspect of the product, know it inside out, and play nicely with everyone inside the project. They are indeed the most powerful weapon a project manager can have in his/her arsenal, and if used correctly, the entire team will be more productive and produce higher-quality products on time … Well that’s the general idea, at least. ;-)

They Are Around – Even When You Think They Aren’t!

More often than not, projects will have a QA team, or at least QA people, without anyone involved even knowing about it!

Just think for a moment about all of those projects that you have come across that are high-quality and are well-managed, yet have no official QA team nor any mention of QA anywhere.

This scenario tends to happen when you have smaller companies or smaller development teams within companies. They become their own QA team, usually without appointing someone to take care of the bug system, with no one doing proper bug triage sessions and with verification simply happening when someone tries to fix the bug and ends up chasing down the person that filed the report just to get enough information to be able to actually fix the problem. This is all highly inefficient but still displays an effort to maintain a certain amount of quality.


A good 7 years ago, the PEAR QA efforts fell into the category: “It is around, even when you think it isn’t.” The project had a QA mailing list where there were some people around that did the occasional poking about and kept the project in decent shape. Quality was by no means bad, but as the project grew in size, the demand on high-quality code rose and since PEAR had some standards in place already, it became evident – A QA team would have to be formed to take on this challenge in a more official and more efficient way.

With that in mind, an RFC was written by Lukas Smith and yours truly (http://pear.php.net/pepr/pepr-proposal-show.php?id=60) on various things in regards to operating the PEAR QA team. The RFC was accepted and became the QA team’s modus operandi which still holds true to this day.

Sadly, as is often the case with open source projects and indeed even companies, resources and man power are scarce, and as such, a QA team may not be in place from day one or it’s just too overwhelming for the team at hand and things start piling up, which was the case for PEAR.

Bug reports as old as 6 or 7 years were still open and unattended, something not acceptable by a project claiming high standards, and so in 2008, after brainstorming, we decided to attempt a bug triage bimonthly in the spirit of the Mozilla-run bug days, where end users and developers come together on a specific day and go through old bugs or a specific part of the system(s) decided upon in advance, verify reports, write test cases and fix code.

I ran the first couple myself with a small group of people attending. Finding myself lacking time, Daniel O’Conner stepped up to take over my role, and he has done it so well that PEAR has never before been in such a good state quality-wise!

This is just one example of how an active QA team can make a difference for a project, another excellent example would be the Test Fest the PHP team put together for 2008, which was all about involving the user groups and communities to help write new test cases and get the coverage up for PHP itself. As a result of the first Test Fest, PHP received over 158 new tests, a truly great effort to combine test writing and community involvement.

The moral of the story is this: A QA team can bring a lot to your project and is an important part of the development process – Do not only think about delivering quickly, think about quality for the sake of your end users.

Tags: , ,
February 18, 2011

Backwards Compatibility

This article was originally published in php|architect in April 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better and updated a few year references.

Just remember, this article was written a while ago and any references to PHP 4 reflect that, take it with a pinch of salt :-)

In my last blog post, I went on a little rant about version naming standards and how that standard has helped PEAR, and other projects, to deal with their version naming and what users and developers can expect from the naming rules (e.g. seeing Foo- 0.5.0beta5 = A backwards compatibility break could happen) and so on. A version naming standard is a positive thing, but now I’m going to focus on something that is both a positive and at the same time a negative side effect of the version naming standard we keep in PEAR, something people have both praised and condemned PEAR for. Yes people, it is backwards compatibility. Continue reading

February 16, 2011

Version Naming

This article was originally published in php|architect in February 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better.

Standards evolve all the time but this specific standard has not changed much at all since I wrote my article but as always for something written a year or two ago, take it with a pinch of salt :-)

PEAR has been around for many, many years, and thus has accumulated a lot of knowledge on how to run a large-scale project.

PEAR has run into countless hurdles along the way that had to be solved in one way or another. As a result of getting over these hurdles, we have produced good things that affect the whole PHP community and also things that well…let’s face it, didn’t help PEAR or PHP a whole lot.

Continue reading

January 15, 2011

2011, PHP Advent and First-Class APIs

And here we are, 2011, excitement in the air and all that jazz! It’s looking to be a great year ahead of myself and my company (echolibre). I’ll be speaking at a few conferences this year such as PHP Tek and writing articles for various magazines and online publications – I already have 2 slated for PHP Architect and as a bonus I will be publishing my old PHP Architect articles and columns to this blog in the coming days :-)

On the subject on online publications, last December I wrote an article called First-Class APIs for the PHP Advent Calendar – A topic I enjoyed a lot writing about. But I wanted to take a minute to thank my two good friends Sean and Chris for taking their personal time to bring the whole thing together. Editing articles, cat herding writers and generally being awesome for helping the PHP community to be even beter. If you have never read any of the articles that get published on PHP Advent then head over there right now and read up on them! I’ve been privileged enough to have an article up there the past 3 years and hope I get to write for them again this year :-)

Seems they don’t have any way on the website it self to go back years so here you go: 201020092008

Anyway, I just wanted to get my blog rolling for 2011 and here’s hoping I can keep up a real blogging schedule at least for the first part of the year! :-)

January 4, 2010

Web Developer, what art thou?

A few weeks back couple of my friends announced that they started a co-operative together called Analog. A highly talented group of guys who create web sites that will knock your socks off, and then some. The name is quite interesting, especially the meaning, to me Analog means personality, warmth, simple yet sturdy, tough yet soft, exactly what a company should strive for. I wish them all the best and good fortune.

One of the Analog guys, Andrei Zmievski wrote a very inspiring blog post about the journey the co-op went on, from idea to reality. There was one point in the post which caught my attention, where Andrei talks about claiming back simple, honest phrases like web sites and web developer. As Andrei puts it

They are precise and descriptive despite having been shunned or dismissed by people in favor of things like web application, front-end/back-end engineer, and other seemingly sexier nomenclature meant to sound more important.

Simple, yet a good point none the less. But lets not dismiss a completely valid term such as front-end engineer just yet.

Continue reading

December 28, 2009

PHP Advent

With Christmas over it also means the annual PHP Advent calendar has been concluded. As with previous years, there is a good bunch of authors with a great choice of articles, worth reading if you haven’t done so already. You can also read 2008.

I find the idea of article driven advent calendars absolutely fantastic, as it gives authors an interesting venue to write for and readers new quality material to read every day for 24 days. With a lot of my TV shows going on a break in December, I cherish the opportunity queue up a few quality article and putting aside an hour or two to read through, with hot chocolate. PHP Advent is not the only one I read, two other advents I’ve been keeping tabs on is the Web Design Advent and the Performance Advent, and you should as well.

Continue reading

October 28, 2009

ZendCon, the aftermath.

Now that ZendCon 2009 is over and I’m back home safely, albeit tired, in London after a whole week of giving presentations and meeting old friends and making new, I have an itch to reflect a little bit on the trip, reminisce if you like.

First I would like to mention the talks I gave at ZendCon and make my slides available, as I have been asked quite a few times so far to publish them but have no yet had much time to deal with it.
If anyone wants the originals they can contact me directly and I will be more than happy to oblige :-)

Continue reading

October 15, 2009

ZendCon 2009

I just wanted to give everyone heads up on the fact that in a few days I will be flying over to San Jose to give 2 talks at ZendCon 2009.

I will be presenting Frontend Caching – The “new” frontier, which is all about how to squeeze the most performance out of your frontend and I will also give PEAR2 & Pyrus, the look ahead where I will talk about where PEAR2 stands currently and how the new PEAR installer is progressing (e.g. Pyrus) and how it will revolutionize your life.

Both of those talks I have given before on couple of occasions, where they have gotten good feedback from the crowed and I have been tweaking them along the way, so I hope everything will be in tip top shape for the ZendCon crowed! :-)

I would link directly to the descriptions of my talks but apparently S&S do not know how to make websites that are usable so I can’t without digging in deeper than I want to bother with! Sorry!  Just go to http://www.zendcon.com/ and browse the agenda to see the descriptions of my talks and many other great talks.

I hope to see you guys there!


As Chris of the phpdeveloper.org and joind.in fame pointed out, you guys can see the description for my talks at joind.in :)


Also you can use that to give me feedback and rate the talk after I have given it, I would very much so appreciate that.

July 30, 2009

Where have I been? Well here's where!

Just wanted to give people heads up that I made a new blog post at my companies blog about what I’ve been up to, for the most part, personally and professionally, the last 3 months or so: http://blog.echolibre.com/2009/07/conferences-conferences-conferences/

February 23, 2009

Changing Jobs

As the title suggests, I will be changing jobs very soon. I have decided to leave Ibuildings UK and my last day will be Friday the 13th of March, scary isn’t it ? :-)

I have accepted a job at echolibre, a company based in Ireland, where I will be heading up R&D, among other things, in addition of taking up part ownership, where I will be working along side great people like David Coallier and Eamon Leonard. If you are looking for a great company to take care of all your PHP needs, then contact us to get further information ;-) </shamelessplug>

I look forward to this opportunity and am very excited since I will be able to spend a whole lot more time on my open source projects than I have for the past 6 months, as well having more time for other side projects, such as writing columns and articles for php|a, a book and other exciting new things on the horizon (Keep tuned on this blog!). This new position will not mean a decrease in my conference attendance, so fret not – I will still come to the usual conferences and spread my joy all over the place and paint the town red!

I got a great office space in Soho, London for when I start at echolibre, so if any of you web people are located in the area, DM me (@h) or drop me an email if you’d like to talk business over drinks or just general farting about.

I would like to thank all my co-workers at Ibuildings for a great time the last couple of months and all the best in the future.

A co-worker of mine of Ibuildings UK Arpad Ray decided to leave at a similar time as my self to venture back into the contracting business, so congratulations are in order ! If anyone needs good developer than contact Arpad