Software Development

Which CMS Should I Use?

WordPress, Drupal, and Joomla! Which CMS Should I Use?

It was only time that kept bloggers around the world from whipping out their laptops to write some long-winded comparison between the three major Content Management Systems taking over the CMS industry. The three most popular CMS systems by far are WordPress, Joomla and Drupal. Now that these systems are becoming more and more integrated into the business world, people everywhere are breaking out their laptops and logging into their blogs to share how they feel about these Content Management Systems. Browsing the web, users can find WordPress loyalists, Drupal enthusiasts and Joomla! fanatics. The truth? All of the CMS have their pros and their cons. Which CMS should I use?

WordPress can be considered the Content Management System late to the game, but it surely is the underdog, as well as the go to CMS for bloggers. WordPress is an excellent system to create a quick and professional looking website, but while it is often used as a blog, it can be used to work in many other interesting ways as well.

Drupal is a content managers dream come true. If you’re the type of person who would rather hand-code the content of your pages, a CMS like WordPress will be nothing more than a disappointment. Drupal on the other hand allows for developers to completely customize websites, blogs and more through their completely open platform designed for the code-friendly content manager. Another benefit of Drupal is that it has a huge community support group for those who may not be so familiar with coding, so experienced content managers can help new users get acquainted to the site.

Joomla! is more like Drupal than WordPress. Joomla! is a content management system designed with the developer in mind. Many call Joomla! an excellent combination of WordPress and Drupal. The name Joomla, in fact, means ‘all together’ in Swahili (Urdu), and it appears that they have been living up to their name in how this powerful CMS works. Designers will choose Joomla because of the amazing capabilities that its engine has in making websites look fantastic. Newbies will enjoy Joomla! because of its user-friendly features and wide community support network.

ios 7 flaws

Apple Security Issues Continue With New iOS 7 Flaws

Apple really needs some help with security testing as part of its release cycle for new software. In particular, iOS 7 flaws continue to show up that should have been caught prior to release. The latest issue is that anyone can bypass the iPhone’s lockscreen to hijack photos, email, or Twitter. Also, there’s a bounty for hackers to crack the fingerprint “Touch ID”. Some security analysts claim that this will be a near impossible feat, but my money is on the hackers.

So, why do we hear of so many instances where a company, often a large one, has released a new product or service that has gone through their QA team only to have the public and their customers find some serious security issues and bugs? Well, it’s partly the “see the forest for the trees issue” that’s at the heart of the problem. You and your team are often too close to your products to formulate enough of a unique perspective. You see, no matter how sophisticated of a team you have, the processes you have in place, the tools you use, the test cases you use, you are still limited and myopic to a certain degree by those same sets of tools, processes, people. Whatever your QA process is it will still be dictated by the definition of that very process. If that process has a flaw in it then chances are good you’ll release software that your customers will find issues with.

So, what can you do to increase your odds of finding issues in-house before your software leaves the lab? Secondary QA testing, by a professional software quality assurance company will help. This means to bring into your release process a separate QA team that employs different processes than what you use and to use a team that isn’t as familiar with your product or service as you are and are not already “tainted” with how it should work, look, and feel. Our company, QuadrixIT, is often used by other software development firms to employ a fresh look and fresh test perspective to supplement their in-house test teams and processes. More times than not we’re able to report back to our clients new bugs – both in functionality, feel, and security that they completely missed.

Some companies further try to reduce bugs by implementing a beta test cycle where they have some of their customers test their software after their QA team has completed testing or near the tail-end of the development cycle. While this should certainly be standard protocol, beta testing does not replace the expertise of having a secondary QA team employ their own test processes, tools, and methodologies. If you can utilize a secondary QA team that uses completely different test methodologies (albeit some form of accepted QA processes) than what your team uses, you’ll be that much more assured that those fresh eyes will find issues that your team may not have caught.

Apple and other companies can try to keep the QA team and the development team separate enough from each other to emulate this “freshness”, but in practice that doesn’t work well in the corporate world. Corporate process often dictates that the model is usually one of a shared expertise so that resources can be cross-utilized between teams to meet project timelines and release/development cycles. This close-team integration might be positive for product design and sharing of tools, etc. but it is a sure way to corrupt that fresh perspective when testing. Apple certainly could have benefited by having a secondary QA team review iOS 7, potentially finding these flaws prior to release.