Software Test Estimation – 9 General Tips on How to Estimate Testing Time Accurately

This is a guest article by Author “N. Sandhya Rani”.

For success of any project test estimation and proper execution is equally important as the development cycle. Sticking to the estimation is very important to build good reputation with the client.

Experience play major role in estimating “software testing efforts”. Working on varied projects helps to prepare an accurate estimation for the testing cycle. Obviously one cannot just blindly put some number of days for any testing task. Test estimation should be realistic and accurate.

In this article I am trying to put some points in a very simple manner, which are helpful to prepare good test estimations. I am not going to discuss the standard methods for test estimations like testing metrics, instead I am putting some tips on – How to estimate testing efforts for any testing task, which I learned from my experience.

Factors Affecting Software Test Estimation, and General Tips to Estimate Accurately:

1) Think of Some Buffer Time
The estimation should include some buffer. But do not add a buffer, which is not realistic. Having a buffer in the estimation enables to cope for any delays that may occur. Having a buffer also helps to ensure maximum test coverage.

2) Consider the Bug Cycle
The test estimation also includes the bug cycle.  The actual test cycle may take more days than estimated. To avoid this, we should consider the fact that test cycle depends on the stability of the build. If the build is not stable, then developers may need more time to fix and obviously the testing cycle gets extended automatically.

3) Availability of All the Resources for Estimated Period
The test estimation should consider all the leaves planned by the team members (typically long leaves) in the next few weeks or next few months. This will ensure that the estimations are realistic. The estimation should consider some fixed number of resources for test cycle. If the number of resources reduces then the estimation should be re-visited and updated accordingly.


4) Can We Do Parallel Testing?
Do you have some previous versions of same product so that you can compare the output? If yes, then this can make your testing task bit easier. You should think the estimation based on your product version.

5) Estimations Can Go Wrong – So re-visit the estimations frequently in initial stages before you commit it.
In early stages, we should frequently re-visit the test estimations and make modification if needed. We should not extend the estimation once we freeze it, unless there are major changes in requirement.

6) Think of Your Past Experience to Make Judgments!
Experiences from past projects play a vital role while preparing the time estimates. We can try to avoid all the difficulties or issues that were faced in past projects. We can analyze how the previous estimates were and how much they helped to deliver product on time.

7) Consider the Scope of Project
Know what is the end objective of the project and list of all final deliverables. Factors to be considered for small and large projects differ a lot. Large project, typically include setting up test bed, generating test data, test scripts etc. Hence the estimations should be based on all these factors. Whereas in small projects, typically the test cycle include test cases writing, execution and regression.

8 ) Are You Going to Perform Load Testing?
If you need to put considerable time on performance testing then estimate accordingly. Estimations for projects, which involve load testing, should be considered differently.

9) Do You Know Your Team?
If you know strengths and weaknesses of individuals working in your team then you can estimate testing tasks more precisely. While estimating one should consider the fact that all resources may not yield same productivity level. Some people can execute faster compared to others. Though this is not a major factor but it adds up to the total delay in deliverables.

And finally tip number 10.
Over To You!

This test estimation tip is purposefully left blank so that you can comment your best estimation techniques in below comment section.

Recommended reading


#1 Prashanth

Hi Sandhya,

Why do you need to consider the Availability of All the Resources for Estimated Period and Know Your Team as the Factors for estimating. I think this is required for scheduling (Correct me if I am wrong). We just need to think how much time I will take to do my testing including defect retest and signoff’s.


#2 venkatesh.s


very good article
I agree with you , but only if we have experiance then only we estimate time apporximatly ,but most of the time we can’t estimate accuratly.
thank you

#3 venkatesh.s

i am new to software testing plz give your valuable suggitions , when you were new software testing how you improve your software testing skills


#4 sudhir

my tip no 10
very simple method tho estimate testing efforts:

Testing time= developement time/3

this is the formula we have been forced to use by our management!!!

#5 Suhas M

Think of Some Buffer Time – Do we need to think of the buffer time even before we have the estimation?
Consider the Bug Cycle – This would be considered in the regression testing effort
Availability of All the Resources for Estimated Period – We are doing the effort estimation here, if we check teh availability of the resources and then estimating – are we doing it right??
Can We Do Parallel Testing – If we do not have the older version of the application wont be we having the expected results for each of the test case?
Consider the Scope of Project – Based on this only you might have come up with the test plan.

Are we not discussing any formal ways of test effort estimation – like function point analysis, Estimation using Usecases, Data points etc ???

#6 Ambarish Karnik

Hello Sandhya,

I am really sorry to say that, this article is definitely not about ‘How to estimate software testing effort’ but about ‘How to avoid slipping software test efforts’.

I say this because…
1) There is not even a single estimation technique you talked about
2) The article starts with a point ‘Think of Some Buffer Time’ ahhh pleaseee!! To add buffer to your estimates, you need to have the estimates in the first place!
3) Leave plans of Team members?? You should consider this, once you have the estimation in first place!
And so many more points, I can write…

Hi Vijay (Owner of the site),

I really didn’t expect an article of this “quality” from Software Testing Help!

-Ambarish Karnik

#7 Amit Namdeo

Its a Nice article the only thing which i found in this article is the description is too generic can you please include some specific estimation technique like some measurement metrix or estimation of criticality or complexity of application.

#8 Sandhya

@ Suhas
@ Ambarish Karnik

I guess you people did not read the following in the actual article:

In this article I am trying to put some points in a very simple manner, which are “helpful” to prepare good test estimations. I am “not” going to discuss the “standard methods” for test estimations like testing metrics, instead I am putting some tips on – How to estimate testing efforts for any testing task, which I learned from “my experience”.

The article is about providing some “general tips” while preparing test estimation.

#9 Suhas M

~ Availability of All the Resources for Estimated Period ~
How do you think this is the part of effort estimation?
Well, if you say so – the “general tips” provided by you is for completion of “TEST EXECUTION” in “ESTIMATED” time and not really about Effort Estimation.

Please clarify if we are taking about test execution or test estimation ?

#10 Sandhya


Lets take an example, the initial estimations were prepared using 3 resources (who will be executing the tasks) for 2 months . Now one of these resources is not available after 1 month and we have proceed only with 2 resources. So in the rest 1 month only 2 resources have to complete the task. This will ultimately extend the no. of days to finish the task. Test estimations are obviously used for test execution. (one is supposed to execute task within the estimated time)

#11 Suhas M

One important thing to share here – whenever your estimation is done – its done in number of hours. For the given work you estimate the number of hours that is required. Most of the time calculated in man hours. The unit would be FTE hrs (1 FTE – Full Time Employee hours would be 160 hrs). Once you do the estimation then the work is allocated for the execution. So you may have 10 testers to execute it or 1 tester to execute it – that all comes under execution.

#12 quality paul

@ Suhas M

Hi Suhas ,

Can you please give me more detail inputs for “Test Effort Estimation”.Please send your sugestions and inputs to my mail id

quality paul

#13 Kajal Das

@ Sandhya
Your points are very practical. The standard effort estimations always impacted by the aforesaid points, which we tend to ignore during effort cal. We foresaw implicit probable which might impact the standard effort estimation. If an experience team member leaves the project or an organization in the mid of test execution, effort estimation goes off track and your point “9) Do You Know Your Team?” was just foresaw. The standard estimation + considering your point will definitely make a healthy estimation :-)

#14 Jai

Thanks for the ‘general’ tips. Made a good read. I would appreciate if you can follow this post with an post detailing standard estimation techniques.

Look forward to your post.


#15 Simply Tester


The article is even not elementary level. At least there should be some level for articles to be published here. Do not unnecessarily waste everybody’s time by publishing such low level articles.

Regards/Simply Tester

#16 Minhus

Hi every one,
What are the available estimation techniques available for software testing. Can any body provide materials how to estimate sothat i can use the estimation technique in my testing project.
Best Regards,

#17 Aman


#18 Puneet

I think Senior Tester should review the complete product documents to have a look there are how many screen and modules need to test,so that he/she must have a fair idea of estimation.

#19 Puneet

Points given by “N. Sandhya Rani” is really owesome,
one point that I think is most important is to check
“Is the build Stable or not”?
With this answer we will decide 90% of our estimation time.

#20 Pradeep Soundararajan

I am writing this comment to help you. How you take it is left to you.

I stopped reading your article after I discovered this line “Sticking to the estimation is very important to build good reputation with the client. “

I bet you are wrong for many reasons. You don’t realize that estimation is a kind of prediction and all ideas that you might have mentioned are heuristics that are likely to get you close but you never know how close. You could get close by 100 m but still be far away by a 1000 m.

A client will be happy to see you make changes to your work and time duration to achieve the goal the client has set when you discover that your predictions went wrong. The reason they ask for estimates is not to make you stick to the time frame but to budget funds based on the estimate. Every minute we stay in an organization is a cost to it. We use light, fan, AC – do we pay for it?

If the estimate is an year and it exceeds by a month for the sake of helping the quality improve or make a significant feature addition to increase the competitive advantage.

I think you should do lots of study about the topics you write or at least discuss it with people like me who would test your ideas up front before you consider writing more.

I am not discouraging you to write but I suggest that you would gain better credibility and recognition by writing something worth for the community.

I once went to Sachin (^really) when he was practicing for next day’s match in Bangalore Chinnaswamy stadium and asked him how many runs does he plan to hit in next day match?

He asked me one question: Do you really follow cricket?

If he had said “100” he wouldn’t have been Sachin Tendulkar that you all know today. He understands that it depends on if India is playing first or second. If India needs to chase a big total or a small one. If the wickets on other side is falling fast or standing.


Please be more valuable to the community of software testers.

#21 Amit Mhatre


Can you please write more on test estimates using WBS

Amit Mhatre

#22 Govardhan Reddy M

We are looking for fresh engineering graduates with the following eligibility to work out of our Bangalore facility:

Ø Engineers – B.E/B.Tech with 70% and above

Ø Graduation year of pass out – 2009

Ø XII Std – 75%

Ø X Std – 75%

If you have any of your acquaintances who satisfy the above criteria, you may please ask them to apply through the following link:

Shortlisted candidates will be called for a technical written test to be held in Bangalore, shortly.

Please note that:

Ø candidates not meeting any one of the above criteria will not be considered

Ø applications directly sent to the recruitment / HR team at Bangalore / Chennai will not be considered

Ø applications registered thro’ the above link will only be considered

Ø the above link will be open only till EOD of 15 Dec 09 and applications received beyond 15 Dec 09 will not be considered.

#23 Raghuram

Hi All,

After going through all the comments related to this post, i want to express few of my views here:
Provide the details which you know regarding the software test estimation, effort estimation etc
Please do not express your view as this article is at elementary level, this is very basic level, there are no metrics mentioned etc. I feel this post outlines the experience of the author related to the topic. It will be better if every one include their experiences about the topic discussed rather than giving vague statements.

#24 Senthil

Dear All,
Kindly provide the valuable/worthable article in this blog.

#25 Nauhsad

Great Sandhya,

You have something in you that’s the reason your article is been published. Keep writing you will do good.

All the very Best!


#26 Wasim

The points covered as part of this article directly or indirectly effect the test estimates. This is a nice article. I don’t agree with suhas on Function Point Analysis (FPA) will give right estimates. It strongly don’t believe in FPA.

#27 Suhas M

@ Wasim –

The point above affect the execution – There is a difference between execution and estimation and am trying to make that a point here.
I didnt say FPA gives the perfect estimation, I just gave the example of estimation technique.

Regards, Suhas Majale

#28 Wasim


There are few test estimation techniques like
• Test Point Analysis
• Function Point Analysis
• Use-case analysis

But will these techniques guarantee you a perfect estimate? It is only the experience on domain and work experience on application will get you a “close to right” estimate.

I agree with you that points discussed by Sandhya affect during execution but with a broader prospect all the risk have been covered, accordingly time is estimated. Thinking proactively on all the risk areas is not a bad technique.

If possible you explain one estimation technique which you think will yield the best results.

#29 Pradeep Soundararajan

Ok, so I got this from my side: on test effort estimation

#30 Aftab H

I agree with Wasim’s approach. In addition, QA need anlalyze the time to write test cases based on Business/functional requirement document. The amount of time allows a tester to determine an approximate time for test execution. There are other method involved to create an accurate test estimate. This is just one of the method to create test estimate.

Hope this helps little bit to some of our readers.

#31 Balaji


As many readers have already pointed out, this article is very elementary and vague. Plz do not pubish very generic articles like this. Plz mail me articles about “Test estimation” . My mail ID –

#32 linu

test estimation should include the time required for understanding requirements, preparing test plan, test case preparation, deployment, actual testing done, documentation of test artifacts, bug posting, issue resolution meeting etc and some buffer period for unexpected or accidental changes in the test plan or lack of any resources.

#33 Amit J

Hello Sandhya,
you are right you should know your team.
If your team understand requirement very well and team will start discussion on requirement then you get idea where we are and you can estimate easly with buffer time.
Parallel testing is fully depends upon which model we are using. For parallel testing I think its fully different kind of estimation need.

#34 Sanju

Hi Sandya

Good effort.

As you said experience play major role in estimation.
Not agree with article point 1, it will not work. because i don’t think none companies agrees with “buffer time” otherwise you have to be specific.

While estimating have to cosider capability of team members. Means to do one job one person required one
man day(i.e.8 hours) whereus other persone required 1.5 manday.

#35 Kishore sharma

Well written but nothing towards estimation. I am sorry to say but in testing everything should be measurable. And for that we must talk in terms of quantity, time, No. etc. I cannot measure the estimation effort from the above article.
Its well written !! No doubt but did not solve the purpose.


#36 Aman kumar

I think test estimation is depends on your past project experiences( means how you can utilize ur previous done project experiences) and availability of resources during testing(which mainly depends on your team members).

#37 Ravi

Hi All,

The above points mentioned are the points which should be keep in mind before sending effort estimates to the client. Can any body tell the formula how the effort estimates can be given for any scenario.


#38 sathish

very handy article

#39 Shakil

Hi Sandhya,

your point, ‘Parallel Testing’ is not clear to me. You said, if we have previous version of a product so we can compare the output. Don’t you think Comparing with previous version of product will be repeated task? Parallel Testing, if it starts parallely with development then it will save our time.

Please elaborate it so that i can understand what exactly what this point says.

#40 Debs

The given artical for the estimation is quite ok but it highlights pre considerations before doing the test or effort estimation. It will be useful if some more details are provided with an example

#41 Amit

@ Sandhya,

Your post is great. I am an SDE at Microsoft, and with all my experience over the years… I can say that you nailed it right…

@ Suhas
@ Ambarish Karnik

The Function point analysis and other methods are quantitative and theoretical. What Sandhya has mentioned is purely qualitative and practical. These are tips, I am assuming you know the difference btween a tip and a theory…
For example, you can be an expert in the estimation process… but if you dont know your team “well”.. some assumptions will go upside down… and they won’t be able to deliver as fast as you’d like to believe. In the end you’ll screw up big time. Your Use case analysis or whatever was spot on, but your team dynamics failed.

Appreciate the work Sandhya has done, and complete it with the quantitaive stuff… that will make this a still better post…

@ Pradeep Soudararajan

“at least discuss it with people like me who would test your ideas up front before you consider writing more.”

And you thought discussing something with you will make the artifact absolutely flawless… Grow up man… what do you bring to the table in this thread… except for a made up story involving your cricket star… Stop ranting and get a life!

#42 nitesh

Good article..Sandhya
I appreciate the flow and simplicity of this article. Its Practicl and applicable.

#43 Subrata

Thanks for your comment. before puting my thought I needed to go through all the comment twice to analyse the mentality of those guys-
@ Pradeep Soudararajan and @ Ambarish Karnik.
I have played different role in different time. Estimation at the end depends on the people who executes.
@Ambarish: lets say you are the best person in the world in estimation and you are not wel known with your team or might you have been approached by one client to do the estimation. You have done it. How much assurity you give that it is going to as per your estimation? It really depends on the team co-ordination and the level of skill.

#44 Sushitha

Hi Sandhya,

You have written a simple article which is very practical and gives light to points which have to consider while preparing a test estimation. I totally agree with you on points 2,6 and 9. Keep writing…..


Hi all, I reviewed the complete conversation of this article and feel that the effort estimation is something which depends on the Test policy of the organization too. Agree that all the factors mantioned above are also considered in estimation but the experience is always the key for good estimation.
Leaving one question here…
What is the phase when estimation happens in STLC. If you can share how and when happens in ur organization it would be great.

#46 Deepti

One more menthod of testing estimation is that the tema lead can make the tem to fill a task sheet every week in which they can fill the time spend on various test activities . Based on this sheet the time aestimation can be determined by dividing the total time spend on activities by the whole team by the number of test cases executed.
For example if total team spend 5 hours for 58 test cases to execute then in one hour the team execute around 10 test cases.Based on this the future testing estimation can be made.

#47 Viplav Anand

I have heard that in general we can take 40% of the development effort as the baselined effort for estimation of the testing time. But in current day scenario, wherein developers have various codes at stake of their googling, can we really benefit from that approach. However even some arguments have come in this regard, klike we have test cases for sign in features also avaialble with us, so it is indeed very tough on this count.

#48 Franklin

The Points Which have been Mentioned in this Article is the Factors which will influence the estimation but is not the estimation technique.

#49 Smruti Ranjan

The 10th point can be
Considering different functional and non functional testing activities
for example:
1. GUI testing
2. Validation
3. DB verifications
4. Regx
5. Boundary Values etc

This is one of the way i generally follow in my recent job.


#50 Dinesh

This is irrevalent discussion.I thought it is focussing on th eestimation techniques ie FP,UCP and WBS….

#51 Shibendu Banerjee

I agree with Smruti points while estimation. We can consider few more depends on your project
6. Browser compability
7. Security testing(basic security detail testing based on SOW)
8. Flow of the system


#52 Siddarth

I think Pradeep is self-proclaimed testing guru. Hope he gets out of his dilemma.

#53 Raghu

Adding to the above discussion – Time for Compatibility should be calculated, whether it is OS or Browser compatibility

#54 Nitin


Informative article. There is a lot of practicality in tips given.
My viewpoint given below hopefully adds value….
Add buffer time:- I believe, this is required to absorb the foreseen and unforeseen risks during planning and execution of test efforts. Previous experience with the older version of the product helps here. Buffer time can be added to estimates, as risk management effort in consent with client. We need to convince client about the risks foreseen based on the previous project experience. Client might say yes if the buffer time added is realistic. For e.g. if offshore team is working on a project, then remote connectivity might slow down the pace of execution or cause downtime if getting disrupted. The previous experience may count here and can be added as buffer time for an activity.E.g. test case execution time increased by some factor if done offshore.
Talking to team who has worked upon the previous project version adds value by coming up with foreseen risks.
To stick to estimated and agreed timelines, I believe, it requires:-
1) Team co-ordination with dedication
2)Continuous monitoring of progress on project activities
3)Client support for achieving the goal of the project
4)Sustained motivation of team members
5)Monitoring of risks encountered and corrective actions
And the list goes on…..:)

#55 Kumar

If 100 test cases are there.. How do we estimate ?
Question : – 1. how to we calculate effort estimation for test designing.
Question : 2- How do we calculate effort estimation for test execution.

#56 S Sarita

Thanks Sandhya,
Really Nice article..
By which we can consider the points while preparing the estimate.
And agree to Amit too…It took long time to read all the comments than the actual topic. :)

#57 Mandy

I wanted to bring to your attention that in agile methodology, the estimation technique could be your past experience because once the sprint plan is published than those resources will be engaged till the release of the project so there capacity of 160 hrs (4 weeks) by default is charged till project ends. So number of resources can be considered based on estimation and then there loading will be default 160 hrs till project ends.

#58 Priya Jose

In order to gain knowledge on the estimation process, I think we need to revisit once the project is complete to compare the estimated value Vs Actual value. This would give us the confirmation whether we are on the right track or should we work on the estimation to include or exclude certain factors.

#59 Giridhar


By going through the article, it gives an idea more of pre-requsites before starting an estimation fo the testing effort.
The article gives provide checklist which needs to be considered while doing estimations.

I would request Sandhya to come up with more elaborative estimation techiniques that would be helpful for the new joiners who would be insterested in estimations.

Regarding Comments from ALL: I would appeal to the community to rather provide valueable inputs on the topic as per their experience and help All in this initiative rather finding faults and ego hurtings….

#60 Ashish Mittal

Just two cents from my side:
Disclaimer: I am just mentioning my own experience of evaluating testing efforts for any project. It may not suite someone and may make sense for others. Please ignore, if my post does not help anyone.

@Pradeep Soundararajan: I really liked your post on your blog site :)

Factors affecting Testing Estimates

1) What is the total development time for that particular feature. Development time actually guides two things; (A) Complexity of Application / Feature and (B) Development Length of the Application or Feature. We consider approximately 20% as testing time for an application which takes 2 – 3 man months for development.

2) An application above 3 months of development time shall have 2% added for testing over and above 20%, for every one months of effort being added in development. This is needed to do multiple regressions of the builds.

3) We spend 3% of testing time in writing test plan and acceptance test cases.

4) We spend 5% of testing time in writing Bug Reports. Thus leaving 12% of time for actual functional testing for an application of length of 2 – 3 man months.

5) If Automation is included then writing acceptance test scripts will take additional 5% of time over 20%.

6) Who is the development team certainly matters for us. If any less experienced developer is scheduled to work on a module, we increase the testing time to certain extent. Estimates for that depends on my past experience with that development team.

7) Are we using any established CMS for building the website. If yes, then we reduce the testing efforts from 20% to 18% or so, though this decision totally depends on the complexity of the project.

#61 Tushar
Best article for estimation

#62 Sirisha Ch

In my experience, some time must be allowed for out-of-the-box testing, that is, subjecting the product to random scenarios that are spontaneously thought of by the Test team. This process helps the Test Engineer/Analyst to break free from the mould of the test cases, process etc and authentically attempt to break the product. A previous assignment I had worked on scheduled this random testing procedure by the entire test team. The result was some hidden defects that test cases could not uncover.

#63 Mahesh G

Sandya – Your article is simple and practical.

Estimations should always be given practically. Its not a good practice to rely on theory concepts (formulas). Formula based estimates fails most of the times because those are made with fixed set of rules. Rather we can use these formulas as a base reference to compare with our Customized estimates.

Clients will always like commitment. They will be happy to see if our actual outcome is quite near to estimated hours.

@ Mr.Pradeep Soundararajan – It seems you are studying a lot than thinking practical. Please come to practical world man.

Google Inc

#64 Ionut

Very good article!
For the people who actually provide estimates on recurrent bases your article makes sense.

For the once that didn’t read the ISTQB Foundation syllabus it might be a bit difficult to comprehend that estimating your own work is something that is based solely by work experience. If you work and you are keeping an eye on metrics you will know how long it will take you to test a certain item.
In order to make it simple i use to brake the system in a list of testing targets/areas [at high level at first] then i re-view the list with the production team/testing stakeholders, then i take each item and think to a use case which will exercise that item, and then i think how long it will take me to execute that use case, add 20% buffer, and multiply with the number of test session i think i will need to perform on each environment = High Level Estimates.
When the project development progresses and more information is available, i make a risk analysis on each item and i develop more use cases for the high risk areas. Based on that i update the High Level Estimates and communicate to the PM. If the estimated time exceeds the project plan, then i do an assessment with the PM and the Dev Lead to optimize the tests [bsed on risk priority or other conventions].

Hope it helps!


#65 Ionut

@Pradeep Soundararajan – you Sir need to learn how to provide feedback. Bullying someone with good intentions is not doing you any good.

You can be as good as it gets on your domain (which i doubt it since professionals never brag about themselves) but without knowing how to communicate your ideas in a diplomatic and proactive manner it makes you worthless within your organization.

In this case, i would prefer to have in my team a junior with good intentions than an expert with a bad attitude.

#66 Iyer Swami

Agree with @Pradeep Soundararajan –

I am not totally agree with point “Sticking to the estimation is very important to build good reputation with the client.”

Before writing the article please make sure that you are not spreading the wrong information.

I am not asking you to stop writing but keep in mind that spreading correct message to the world.

– Iyer Swami

#67 Ananthan

In one of the interview, panelist asked me a question. how do we estimates when the requirement itself is not clear /not given. Thanks in advance.

#68 Experience Tester

@Amit I agree with your comments, this article is simple and conveys the idea.
@Amit good comment on Pradeep Soundarajan’s comment.

@ Pradeep Soudararajan

In our own words “Please be more valuable to the community of software testers.” It applies to you too. Why do you keep bringing cricket example in testing? Testing is not a game Sir, so stop quoting examples from cricket….

For your other comment

“at least discuss it with people like me who would test your ideas up front before you consider writing more.”

You lack communication skill, that is all I can say…

#69 Velayutham

Good Article!
I would add a line item called “Humanize” to the textbook effort estimation methods and bring all these points under that line item. It is because of certain people like that I observed in the comments here who blindly followed the text book methods and abused the writer, engineers working at the task level spend sleepless nights and their weekends working at office.

Leave a Comment