Andrew Podner has posted the first part of a new series to his site today. He'll be looking at using functional testing to improve quality of the resulting code and full application.

For this week, I wanted to focus on some different types of automated testing other than unit testing that can help developers build more robust applications and improve both the speed and effectiveness of quality assurance. Specifically, this post is going to focus on functional testing. Functional testing is composed of the tests that you write which are from the user's point of view. A functional test is used to perform quality assurance on all or part of an application utilizing the user interface as a pathway to the application.

He gives some examples of functional tests like clicking on buttons, trying a login, checking that the contents of the page are correct. He talks some about the purpose of functional testing and how it differs from unit testing. He suggests the metaphor of a race car - the pit crew would be the "unit testers" and the driver would be the "functional tester", saying whether or not all of the parts of the car are working together as they should for the race. In the next part of the series, he'll talk some about the actual software to automate this process.

Matt Setter has a quick new post that suggests a way you can get more done with less work - simplicity.

Though we can do so many things simultaneously - should we? Does it actually reduce effectiveness and productivity which are the antithesis of professional application development? [...] I had the thought, as is common in a western-based mentality, that to be busy, to be industrious, to try and multi-task a series of independent tasks and projects simultaneously was the right thing to do. It's meant to be a simple formula: "Greater productivity = Greater self-worth right?" Sounds almost like Thatcherism. I felt that this was not only right, but the sign of an intelligent and sophisticated developer, who truly had honed his craft. Perhaps you've felt the same at one time or another?

He points out that, while it's very easy for developers to fall into this trap and way of thinking, it's not sustainable. It leads to stress, bad code and even - possibly - an even higher bug count. Instead he suggests the good standby idea of "KISS" (essentially, simplicity).

Instead of trying to do everything at once - I stopped and decided to only do one thing at once. And that one thing, had my full attention and focus. When it was done, I then moved on to the next one. Not before and not after.

He includes some of his own experience trying to apply this in a Zend Framework 2 application.

Eran Galperin has a new post to his site today talking about the real cost of software development, how it's more than just time spent hands-to-keyboard.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

PHPMaster.com has a new article about a practice that's becoming more popular in recent years to help increase the quality of code that comes out of development - code reviews.

Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you've been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect - finding bugs is good, not bad!

In response to some of the "problem with PHP" posts that have been circulating lately, Anthony Ferrara has posted about the "true problem" with PHP - less about the language, more about the community.

The core of the PHP community is filled with a lot of really talented and smart developers doing some really amazing things. But on the fringes, there are a lot of people who are writing articles, tutorials, and posts designed to help beginners learn the language (and usually how to program). The problem with this is that the majority of those authors frankly don't have a clue what they are talking about.

He talks about why this is a problem (bad practices promoted, bad code) and what you, as a PHP developer, can do about it...and maybe help in creating a separate tutorials site with content "approved" to provide good practices and quality code.

In case you missed it (there's been a good bit of buzz about it in the PHP community lately) there's a recent post from Jeff Atwood about the PHP language and some of his thoughts on its usefulness, it's structure and some of this thoughts on the usual "PHP sucks" kinds of articles.

Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP. This has been going on for years.

He talks about the the anti-PHP rants that have been happening (over and over) for years, his thoughts on it being the "worst designed mainstream 'language'" out there...and how the discussion doesn't need to be around these points anymore. It needs to be about how to get programmers to use better tooling (whether or not PHP is the right tool for the job).

Of course, there's no shortage of comments on a post like this, so be sure to go through them and see the various reactions to Jeff's thoughts.

In this recent post on Reddit.com, a developer asks the community about some of his feelings about bugs in his software and his focus on quality:

No one has told me this and I don't need them too. I feel like one bug that has a negative impact on the user experience is too many bugs. I've been programming for over 5 years professionally and I still introduce bugs into my code. [...] I don't like the expectation that I (and maybe others have) that my code must be perfect when I am not perfect. I don't like the fact that it only takes one mistake to affect so many people. [...] I'm wondering if others on here have every felt this way. What have you done about it?

Suggestions in the comments talk about everything from dealing with the apparent burnout the developer is facing, a reminder that no code is bug free and some recommendations of testing and bug tracking to help make the quality of the code better (and give visibility into the level of work being done).

On PHPClasses.org today they've posted their latest "Lately in PHP" podcast - episode 21, "Is PHP Source Quality really Good or is it still Insecure?".

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

In this new post to his blog Artur Ejsmont shares some of his thoughts on bugs and how they can effect the quality of your software. He touches on topics like handling bug reports, how random code changes effect them and how effective a code review can be.

From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

In a new post to his blog today Phil Sturgeon responds to some comments made in another post about PHP not "being an acceptable COBOL".

Anyone who has used PHP for a while knows that it has its ugly parts. Recently I've seen a whole swathe of PHP-bashing articles and that would fine if they were they are making a valid point, but some of it has just been - as I tweeted recently - "absolute drivel".

He directly refutes some of the points made in that article, points out a newer post from the same author (which misses some points as well) and finishes it off with a look at why he "still" uses PHP versus something like Closure or NodeJS for his development.

Despite known flaws and imperfections I continue to use PHP as my primary language because during all the time I spend worrying about which technology is the neatest, coolest or shiniest I could have built a new application to sell or finished another client site.

Be sure to check out the comments for some other thoughts about the language (and Phil's responses).