Agile Ali

Still using XP ? This bug might just make you upgrade !

Microsoft has warned of a new security hole that could be exploited by attackers to take control of older Windows systems running Internet Explorer and for which proof-of-concept exploit code has been released publicly.

The vulnerability affects Windows 2000, XP and Server 2003-based systems, Microsoft said in a security advisory dated March 1.

Microsoft said that the vulnerability in VBScript could allow remote code execution of computers. “If a malicious Web site displayed a specially crafted dialog box and a user pressed the F1 key, arbitrary code could be executed in the security context of the currently logged-on user,” Microsoft said on its Web site, “On systems running Windows Server 2003, Internet Explorer Enhanced Security Configuration is enabled by default, which helps to mitigate against this issue.” Windows Vista, Windows 7, and Windows Server 2008 are not affected. More »

Its Alive, Its Alive ! again ! PS3 bug fixed

Sony PS3, the bug is fixed : The issue date of which affected the older model PlayStation 3 (PS3) is just a bad memory. Sony has indeed fixed this bug that prevented players from connecting to the Playstation Network.

Two days was all it took to Sony engineers to solve the problem of time that affected some models of the PS3. A concern due to the passage of the month from February to March and that has prevented some users from connecting to the PlayStation Network on Sunday and Monday. This bug has been identified as the older model PS3 (called Fat) and does not cover PS3 Slim sold since September 2009.

On its blog, Sony states that if, on consoles impacted by this bug, the date does not always gets updated automatically, you can now force it manually or via the Internet. The Japanese company also said that if it has new elements to correct any other recurring concerns, it will update the console via the web to solve them. Evidence that the connection problems are only the past now.

Turn the Love-Hate relationship with QA to just Loving QA ! :) !

You’re QA Team is the last line of defense before your software gets to the end-user. They are your last, best hope at finding any bugs that may be detrimental to a successful product. Treat them well and you will be well rewarded in the end with good communication and a successful product.

I’ve worked at places and with developers that see the QA Team as a nuisance. Constantly interrupting with bug issues when you’re just trying to move on to the next step. I mean, you tested it yourself right? What could some QA person have found that you didn’t account for? That’s the point. As the old phrase goes:

“It takes more intelligence to debug code than to write it. Therefore, if you write the most difficult code you can create, you are not smart enough to debug it.”

The other thing to remember is that when you as a developer test code you have the bias of knowing exactly how it works and will test with that in mind, there’s no escaping it. The QA Team is there to not only test it to see if it works, but to try the most asinine tests that end-users will do and see if it breaks. No matter how well you design your software the end-user will use it in ways you never thought possible, the QA Team is there to help you in these cases by testing obscure scenarios and reporting what they’ve found.

There’s more to it than understanding QA’s role and respecting them and relying on them. We as Developers need to be engaging them. When I turn over my software to QA, if I don’t hear anything within a few days I go bug them. My ultimate goal as should be the goal of all developers is customer satisfaction, if the customer isn’t happy you’re not going to be doing much development for them. We should be asking QA what we can provide so they can better test the code. Maybe creating a tool that will allow them to automate certain interactions or giving them DB access to see what’s getting stored. In any case we also need to be sitting down with them and making sure they understand exactly how the software works. Sit down and explain the DB table structure with them, make sure they understand the process flow. The more they understand of it the more they will know how to test it. Also keep in mind that a good rule of thumb to follow is however long it took you to develop it, it may take twice as long for QA to debug it. Your QA Team is your friend, not your enemy. QA is the body armor to failure. The more you help QA the better your chances of success.

So, Bottom Line : LOVE YOUR QA TEAM !