Completing a piece of the system, referred to as a story or backlog item, means that product management, development and testing work together toward a common goal. The goal is for the story to be ‘done.’ Stories are identified and prioritized by the product owner, who manages the backlog. Stories are selected based on their priority and effort estimate. The effort estimate is another team activity, which also includes testers. The team also identifies dependencies, technical challenges, or testing challenges. The whole team agrees on final acceptance criteria for a story to determine when it’s ‘done’

During an iteration, several stories may be in various stages of development, test, or acceptance. Agile testing is continuous, since everyone on an agile team tests. However, both the focus and timing of testing is different depending on what type of testing is performed. Developers take the lead on code-level tests, while the tester on the agile team provides early feedback during all stages of development, helps or is cognizant of code-level testing being performed, takes the lead on acceptance test automation building regression test plans and uncovers additional test scenarios through exploratory testing.

In addition, the agile tester ensures acceptance test coverage is adequate, leads automation efforts on integrated, system-level tests, keeps test environments and data available, identifies regression concerns and shares testing techniques. Additional testing, such as performance and regression testing, that falls outside the scope of story-level testing, can be addressed through test-oriented stories, which are estimated, planned and tracked just like a product-oriented story.

Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure “in the cloud” that supports them.

Cloud computing customers do not generally own the physical infrastructure serving as host to the software platform in question. Instead, they avoid capital expenditure by renting usage from a third-party provider. They consume resources as a service and pay only for resources that they use. Many cloud-computing offerings employ the utility computing model, which is analogous to how traditional utility services (such as electricity) are consumed, while others bill on a subscription basis. Sharing “perishable and intangible” computing power among multiple tenants can improve utilization rates, as servers are not unnecessarily left idle (which can reduce costs significantly while increasing the speed of application development).

Architecture:

The majority of cloud computing infrastructure consists of reliable services delivered through data centers and built on servers with different levels of virtualization technologies. The services are accessible anywhere that provides access to networking infrastructure. Clouds often appear as single points of access for all consumers’ computing needs. Commercial offerings are generally expected to meet quality of service (QoS) requirements of customers and typically offer SLAs. Open standards are critical to the growth of cloud computing, and open source software has provided the foundation for many cloud computing implementations.

Key Characteristics:

• Agility improves with users able to rapidly and inexpensively re-provision technological infrastructure resources.
• Cost is greatly reduced and capital expenditure is converted to operational expenditure. This lowers barriers to entry, as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options and minimal or no IT skills are required for implementation.
• Device and location independence enable users to access systems using a web browser regardless of their location or what device they are using, e.g., PC, mobile. As infrastructure is off-site (typically provided by a third-party) and accessed via the Internet the users can connect from anywhere.
• Multi-tenancy enables sharing of resources and costs among a large pool of users, allowing for:
  • Centralization of infrastructure in areas with lower costs (such as real estate, electricity, etc.)
  • Peak-load capacity increases (users need not engineer for highest possible load-levels)
  • Utilization and efficiency improvements for systems that are often only 10-20% utilized.
• Reliability improves through the use of multiple redundant sites, which makes it suitable for business continuity and disaster recovery. Nonetheless, most major cloud computing services have suffered outages and IT and business managers are able to do little when they are affected.
• Scalability via dynamic (“on-demand”) provisioning of resources on a fine-grained, self-service basis near real-time, without users having to engineer for peak loads. Performance is monitored and consistent and loosely-coupled architectures are constructed using web services as the system interface.
• Security typically improves due to centralization of data, increased security-focused resources, etc., but raises concerns about loss of control over certain sensitive data. Security is often as good as or better than traditional systems, in part because providers are able to devote resources to solving security issues that many customers cannot afford. Providers typically log accesses, but accessing the audit logs themselves can be difficult or impossible.
• Sustainability comes about through improved resource utilization, more efficient systems, and carbon neutrality. Nonetheless, computers and associated infrastructure are major consumers of energy.

Coverage measurement also helps to avoid test entropy. As your code goes through multiple release cycles, there can be a tendency for unit tests to atrophy. As new code is added, it may not meet the same testing standards you put in place when the project was first released. Measuring code coverage can keep your testing up to the standards you require. You can be confident that when you go into production there will be minimal problems because you know the code not only passes its tests but that it is well tested.

In summary, we measure code coverage for the following reasons:

* To know how well our tests actually test our code
* To know whether we have enough testing in place
* To maintain the test quality over the lifecycle of a project

Code coverage is not a panacea. Coverage generally follows an 80-20 rule. Increasing coverage values becomes difficult, with new tests delivering less and less incrementally. If you follow defensive programming principles, where failure conditions are often checked at many levels in your software, some code can be very difficult to reach with practical levels of testing. Coverage measurement is not a replacement for good code review and good programming practices.

In general you should adopt a sensible coverage target and aim for even coverage across all of the modules that make up your code. Relying on a single overall coverage figure can hide large gaps in coverage.