Reflections

Found out we are losing time due to aborted runs. People are looking at different ways to avoid the run getting aborted. I feel it is mostly due to environment failures. Having a good environment should provent 70% of the failures. On another note, I would like to have an email sent to all of us in NFT whenever a run is triggered or when it is completed/aborted. I have two solutions for that which depends on following info (ie whenever a run is triggered or completed/aborted, VSTS writes into the loadtest database). 1. A trigger on the database . Basically fired on “insert or update”. And this sends an email to  us. 2. Wrote a script in Auto It which queries the database and finds out if a new run was introduced or not. This would require the script to know about the latest run id (which will be fed as input parameter) Had a discussion with our architect and he felt the first option was better. I felt the same too.

The last time I had mentioned about the pipeline which made sure the IIS paths are correct. Now we will go to the next step and look at the stages for this particular pipeline. The pipeline has 4 stages. TOC_Copy_JasCasStubFile TOC_Compare_JasCasStubSize TOC_Copy_Physical_Path_of_Stubs TOC_Compare_Physical_Path_of_Stubs We will look at each stage in detail in part 3 of this blog series.

I was just wondering if we could combine all our soak tests into one. One ground rule we can follow during performance testing is “how it is done in production”?. In this particular project, all the streams are deployed and used simultaneously in production. Well, I have raised the question to our client. Once I propose the solution (how to implement it), hoping the client would accept it. This would bring in huge savings in testing time. To the reader: Did you also have a good idea and ask the client to accept it? If so, what is the approach u followed?