SQL Azure 50GB Databases Now Available

Ahead of the promised June 28 target, the SQL Azure team updated SQL Azure with Service Update 3 (SU3), providing new database sizes up to 50GB.

Web Edition databases can now be scaled to either 1GB or 5GB, while Business Edition databases have increments of 10GB, 20GB, 30GB, 40GB, and 50GB.

The Web Edition tiers are $9.99 and $49.95 monthly, while the Business Edition tiers are increments of $99.99.

The new database tiers come with a new pricing model that evaluates your maximum daily usage, and each day’s cost accrues at the appropriate tier, based on the database edition chosen. For instance, if a 20GB Business Edition database never exceeds 10GB, its daily rate accrues at the 10GB tier. On days in which the database exceeds 10GB, it accrues at the 20GB tier.

For more details, see my post here.

Azure Guest OS 1.4

A few days ago, the Windows Azure team released a new Guest OS, version 1.4. The Guest OS is what runs in Azure’s environment and hosts your running applications.

The latest update includes fixes for Azure Drives and WCF Data Services. It also includes several security patches. If your Azure deployment is configured to automatically use the latest OS, then you’re already running Guest OS 1.4. This might have breaking changes for your code if you are using WCF Data Services.

For more details, see my post here.

Silverlight Unit Testing

I have just written a short series on doing Silverlight unit testing.

Azure SDK+Tools v1.2 now available!

Today, the Azure team launched the latest SDK and related Visual Studio tools, version 1.2. This release has several features:

  • Built-in support for .NET 4 roles in your Azure application
  • IntelliTrace for debugging deployed Azure applications
  • All-new publishing wizard, allowing apps to be deployed directly to Azure without having to visit the web portal or run an external build script
  • Built-in storage and service monitoring from Visual Studio

The SDK is available for download here.

I wrote two detailed posts about this release with more information and walkthroughs:

Microsoft’s Jim Nakashima provides further detail here.

Are we done testing yet?

Usually its every test manager's questions. "Are we done testing?", "Do we have enough confidence in our release"?. But on the complex projects with constant change in requirements, even Program Managers & Business stakeholders are "Paranoid" about test coverage and sign off. Development team will call out code complete and we have met all requirements. Test team will confirm all test cases have passed and there are no more bugs to regress and can't find any more bugs. Does this mean we are done testing? Does this mean we can sign off?

I think there is lot more than just code complete, feature working as defined in functional spec or business requirement document, all test cases have passed, and we have zero bugs. Below are certain guidelines for test team and engineering team so that they are ready when higher management asks the inevitable question - "Are we done testing yet?".

  • Is everyone (including key stakeholders) on board with the test strategy and release criteria?
  • Is our test strategy and planning consistent with the business requirements and business understanding?
  • Are we measuring release criteria accurately and are key stakeholders in agreement with the success criteria of the test coverage and test effort?
  • Do we have standard processes and controls in place to help our engineering team understand the requirements and make changes to code base?
  • Do we have knowledge base in place to capture quality data and trends over a period of time? Can everyone on the team retrieve this information at any given time?
  • Do we have enough visibility within the organization to effectively manage the change-control process?
  • Do we do regular reviews of the product to key stakeholders? Are they committed to provide feedback during various stages of the project development?

I haven't come across teams that have spent enough time clearly defining success criteria for the software development life cycle. Most of the time test team believes they have good reasons to not sign off, while program managers and other key stakeholders think that the primary end users will not be affected.

If test team can answer all or are atleast prepared for all the above questions, we can sure say with confidence that "we are done testing".

This post is open to further discussion. Would love to hear comments...