Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« April 2013 | Main | June 2013 »

May 30, 2013

Back to school! - Determine Optimum Number Of Sprints In Agile Engagements using Mathematics

There has been a rise in adoption of Agile methodology for software development due to benefits such as absorbing late requirement changes, early availability of first version etc. However, decision of adopting Agile needs to be arrived at by balancing project priorities/characteristics (such as lack of requirement clarity upfront) and effort/cost overruns. In certain scenarios, the effort required for developing a product/application is more in Agile compared to that of Waterfall model. It can be easily observed that incorrect number of sprints planned can lead to effort overruns. Several program metrics can influence the decision to adopt Agile as well as to arrive at right number of sprints to keep the efforts in check.


We tried to bring a mathematical approach to decide on adopting Agile and planning for right number of sprints with an objective of optimizing the efforts. Based on certain assumptions, we have arrived at the equation (inequality) to help decide whether to go for Agile or Waterfall model. The value of 'n2' calculated using below equation will determine the number of sprints to be planned. Agile is preferred whenever  'n2' > 2.


((n2+1))/2 * {E+(P(n2)*R(n2)*(2n2+1))/3}  < n1*{E+P(n1)*R(n1)}


X - Total number of test cases

n1 - Number of test cycles in Single Development Cycle Model

n2 - Number of cycles estimated in Iterative Development Model 

E - Effort for one test case execution

R(n) - Rework effort during the nth cycle

P(n) - Probability of a test case failure during the nth cycle

N(n) - Percentage of test cases considered in nth cycle


We have presented this approach in detail through a paper. You can read the same here.

May 28, 2013

Frustrated over testing delays? Cloud based testing can help you

Guest Post by

Nilanjan Ghosh, Project Manager, CORPIVS, Infosys

Testing on legacy datacenter has proven to be a time consuming affair, given the extent of bottlenecks it brings in. It affects the business delivery as product release gets delayed. In this post, I would be highlighting the major concerns which have forced the industry to think on some workaround and paved the way for Cloud based testing. 


Setting up and provisioning the testing platform: With the commencement of a new testing project, comes the requirement of new test environments. The testing team relies on the Infra team to get the specific test set-up with specific compute resources (memory, processor, storage, NICs) and Operating Systems (UNIX, Windows, Solaris). However, Infra teams are usually under pressure as they get requirements from disparate teams and typically have limited workforce. This results in days if not weeks to make it available. More diverse and complex is the environments greater is the time required to prepare the platform, leading to the initial idle time for the testers.


Adding to it is the lack of understanding of the required test environment by the Infra team. It happens due to no or little collaboration among concerning teams. Also, in most of the organizations request of the set-up is sent through the organization's ERP system which occasionally lacks the detailed and explicit description of the set-up causing more delays.


Procuring/Renting specific hardware for specialized testing: There can be incidents when it is required to test the Application on a specific hardware which is unavailable in-house, for e.g. testing on an AMD based processor while only Intel based processor is available. In these scenarios, the vertical needs to convince the business for acquiring or renting the specific hardware. The next step is to engage the finance team and the procurement team to get the approval. Lastly starts the vendor interaction to own/rent the hardware. This process makes you lose valuable days and can force testing teams to keep some testing scenarios unexplored. This directly impacts the quality of the testing.

Defect testing/bug fixing of an application in production: Once the application is moved to production the criticality of it increases manifold. At this time, any defect or bug will need immediate fixing. This demands to reproduce the client-like environment for testing. To create a similar environment would take time as there might not be any hardware available to recreate the same scenario in-house.  Even if, the previous environment is retained in the datacenter, restoration of it may take a while before the actual testing can start. This adds to considerable delay for testing.

Sharing of environment: Owing to the environment limitation, specifically in case of highly customized set-up, the same platform has to be used by both Development and Test teams on time sharing basis. For e.g. to check the Apps compatibility with databases it may be required to configure a HP-UX or IBM-AIX machine which may not be present in abundance. Consequently a single HP-UX or IBM-AIX box needed to be shared by both teams. This directly affects the delivery of the project as more time is required to complete the testing. Had there been a dedicated server allocated, testing would have completed at a much earlier date. Moreover, there can be issues with changes in the environment by either team which can lead to start the activity again from the beginning.

All of the above concerns are eradicated with the evolution of Cloud based Testing. With the migration of the testing environment on cloud, the testing team can start their activities immediately. It gives them ample time for end to end testing and enhances the quality of the deliverables. In my next post, I will cover how cloud testing helps in getting rid of issues of testing on legacy datacenter.