Your browser doesnt support Xml Http Request – but the test passed ! errrrrorrr??

1. Open / Start QTP
2. Right click on the Menu toolbar (File  Edit View Insert ….)
3. Select “Customize”
4. Click on the “Toolbars” tab
5. then Click on “Restore All” button at the lower right hand side.

Wallah ! now All iz Well !

—-

U.S. regulators are moving to freeze the assets and trading accounts of a Russian accused of hacking into personal online portfolios and manipulating the price of dozens of stocks listed on the Nasdaq Stock Market and New York Stock Exchange.

A New York federal judge on Tuesday sided with the Securities and Exchange Commission and froze the assets of Broco Investments, believed to be a one-trader operation based in St. Petersburg, Russia. The SEC said Broco capitalized by artificially moving prices of more 38 thinly traded securities — enabling Broco to profit from up-or-down price swings.

“These transactions have created the appearance of legitimate trading activity and have artificially affected the prices of at least 38 issuers,” (.pdf)  the Securities and Exchange Commission said in court filing.

The so-called “hack, pump and dump” scheme is among the latest illicit methods of gaming the market though hacking.

An Indian man was sentenced to two years in prison for undertaking a similar scam in 2008. That same year, a Ukrainian hacked into Thomson Financial to get a peek about an upcoming negative earnings report for IMS Health, earning nearly $300,000 for a few minutes’ work.

And in July, a computer programmer working for Goldman Sachs was arrested on charges  he stole proprietary source code for software his employer uses to make sophisticated, high-speed stock and commodities trades.

In the latest case, the affected stocks ranged from Akeena Solar, Magellan Petroleum to Xerium Technologies. The prices fluctuated more than 20 percent in some instances.

Broco would purchase these and other stocks in its own portfolio and immediately place unauthorized buy orders at inflated prices of the same securities in hacked Scottrade accounts, the SEC said.

“Immediately or shortly thereafter, the defendants capitalized on the artificially inflated share prices of the targeted securities by selling the shares previously acquired in their account,” the SEC alleged. “In other instances, the defendants profited by covering short positions previously established in their account while placing unauthorized sell orders through the compromised accounts at substantially lower prices.”

Along the way, victims lost $600,000 in market value the last few months alone, the SEC said. And Broco, believed to be a one-person company run by Valery Maltsev, reaped $255,000 in ill-gotten gains during the same time.

Daily trading volume in Pennsylvania-based financial services company AmeriServe Financial averaged about 11,300 shares in from Dec. 1 to Dec. 20, the SEC said. The next day, volume increased 20 times. At least 200,000 shares were bought and sold through Broco or hacked Scottrade accounts, allowing Broco to leverage the prices for its own profits.

“Broco grossed $141,500 in approximately 15 minutes,” the SEC said.

[via Wired]

The Duo battery chargers for NiMH batteries are safe, but the software that enables the user to monitor the batteries is infected, PC World reported Monday.

The infected software includes a “backdoor” that allows some computer files to be to be remotely controlled, PC World said.

The trouble begins if the consumer downloads Windows software from the Energizer company website If this was not done or if the consumer uses a Macintosh computer, consumer files are safe.

Consumers were advised to uninstall the infected software, reboot the computers and then go to the System32 directory in Windows. There, consumers were advised to delete “arucer.dll,” the file that is the actual backdoor, PC World said.

Energizer has discontinued the software, but you can still buy the DUO at Amazon for about $20.

Most people probably just shrugged their shoulders at the news, but it’s yet another blemish against the company’s security record. This isn’t the first time Facebook has run into security issues, and I’ve grown increasingly concerned that the company might be playing fast and loose with its quality assurance policies because it doesn’t want to sacrifice the rapid iteration it’s famous for.  With this in mind, I reached out to Facebook late last week to ask about their protocol for deploying code and how the bug made it through in the first place. The company responded to some of my questions, and refused to answer others.

At least, Facebook eventually answered some of my questions. At first, the company sent me a vague statement reiterating that they were investigating the issue, and that they “maintain industry-leading quality assurance and security systems, and the reliability of Facebook is our top priority.”

In response, I reminded the Facebook spokesperson that it had just sent thousands of messages to people who weren’t meant to receive them, which would seem to indicate that it is not, in fact, on the bleeding edge of online security. I restated my questions and the company got back to me with this more detailed overview of its QA and code deployment policies, found below. Note that it begins with a general statement Facebook provided, along with more direct answers to my questions (which are in bold).

Facebook hires the most qualified and highly-skilled engineers we can find – most from industry or from top universities. Upon joining the company, every engineer and engineering manager participates in a six-week intensive ‘boot camp’ training. Our code review process is rigorous, and we phase out changes and test them before they go live for real users to detect any potential issues. During code pushes, our engineering, user support, and operations teams work cross-functionally to monitor the state of the push and to identify any problems early. We also have the capability to quickly push code updates to all of our datacenters worldwide, and to enable or disable critical features of the site if there is a problem.

All of these checks worked together on Wednesday, as designed, to limit the impact of the error and stopped it within minutes. We were able to swiftly disable access to the users who received messages and remove those messages from Facebook, although we were unable to prevent email notifications from being sent to affected users. It is important to recognize that no system is perfect and no company avoids mistakes all of the time. However, we would like to take this opportunity to sincerely apologize to all affected users and ensure them that we are committed to investigating Wednesday’s issue and to learning from it.

What are your protocols for pushing code?

We have staged rollout changes that go through multiple phases before going to end users, so we can proactively detect any problems. As the changes get rolled out to users, a set of support, engineering, and operation leaders are actively engaged to monitor the state of the push. As soon as any issue is identified, we have multiple tools to quickly disable critical features. The combination of these mechanisms dramatically limited the exposure related to Wednesday’s issue.

Are there multiple people reviewing all code that gets pushed?

Yes, we have a rigorous code review process and no code goes live on the site unless it has been reviewed and approved by a skilled engineer.

What changes are you making to ensure that this does not happen again?

We cannot discuss specific improvements, but we take privacy and security very seriously and are continually improving our code standards, processes, and systems to help us build high quality products quickly.

When do you expect to conclude your investigation, because I will certainly be following up for the details about it?

As a general practice, we do not comment on investigations like this.

While interesting, none of this is particularly surprising. And because Facebook isn’t commenting on the outcome of the investigation, we’ll probably never find out what caused the bug (or if company protocol was even followed in this case).  But hey, at least they saythey’re doing the right things.

It’s worth pointing out that Facebook is by no means the only company affected by such issues.  Last year, I wrote a post called the Sorry State of Online Privacy, where I detailed some of the security lapses that had hit Facebook, Twitter, and Google (and of course there’s the recent Google Buzz fiasco). All of these companies would likely claim to have state of the art testing and security measures, yet such problems seem to pop up every few months.  I’m aware that it’s impossible to have a fully secure system, but that doesn’t mean engineering teams should be treating these problems as inevitabilities.  To reiterate what I wrote last year, the word ‘private’ should not mean “this will remain hidden until we accidentally break something”.

[via TechCrunch]

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.

The advisory includes several workarounds, including advice to avoid pressing the F1 key when prompted by a Web site.

It also suggests restricting access to the Windows Help System, setting Internet and Local intranet security zone settings to “high” to block ActiveX Controls and Active Scripting, and configuring Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and Local intranet security zone.

Microsoft complained in its advisory and a statement that the vulnerability was not responsibly disclosed.

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.

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 !

the Selenium blogs have been updated recently, QTP will be next followed by more Selenium updates and then Loadrunner.

So Keep Reading and stay Agile !!!

Three of the notices relate to critical vulnerabilities, with the two just classed as “moderate”, while all of which could potentially allow a hacker to executive arbitrary code.

It is understood the US-CERT department is advising Firefox users to upgrade to version 3.0.18, 3.5.8 or 3.6. Thunderbird users have been told to upgrade to 3.0.2, with SeaMonkey users also advised to upgrade to 2.0.3.

The notices come after Mozilla employee Jess Ruderman wrote in a security blog post last week the company has begun to deliver updates and notices about security problems more quickly.