How to estimate testing efforts (6 approaches to get test effort estimate)?

Test effort estimation is a skill required of a Test Lead or a Test Manager. However, test effort estimation is not a skill that one can learn quickly. It requires understanding of several key concepts and practice. In this post, I will explain what test effort estimation is, point you to your existing knowledge of estimation and provide you the key concepts that you can use in your estimation.

First of all, we should understand what we mean by software test effort estimation. Test effort estimation is answering two basic questions about testing:
I. What will be done?
II. How much effort would it take?

There are other questions e.g. I. Who will do what? II. When will they do it? III. How will they do it? but these questions are not related to effort estimation but to planning and scheduling.

Even if you have not estimated test effort before (having relied on the effort estimates given by the client or your project manager), keep in mind that you do effort estimation on a regular basis. Let me explain. Do you recognize the following situations?

1. You are appearing in an examination. The duration of the examination is 3 hours and you have to answer n questions. You average the time available for answering one question while leaving out certain time for revision at the end. You look at the questions. Some questions are easy for you but some are not. You reserve less time than average for answering the simple questions and more time than average for the difficult ones.

2. You have to attend a job interview. The interview is at 10 a.m. You estimate the time it would take you to reach the interview venue, say 1 hour. You add some time e.g. 30 minutes for delays like traffic snarls. You estimate some time, say 30 minutes for collecting your documents and some time, say 30 minutes for dressing up. This means that you would need to wake up no later than 7:30 a.m. that morning to reach your interview venue in time.

3. It is the beginning of another day at work. Your manager has given you 20 test cases to execute today. In addition, you need to complete the annual self-appraisal form. You estimate that it would take you 1 hour to complete your appraisal form. Out of 8 hours of your work day, you have 7 hours remaining. You reckon that you need to execute a test case every 21 minutes (7 hours X 60 minutes / 20 test cases).

If the above situations look common to you, it means that you already do effort estimation even if you do not consciously recognize it as such.

Next, let us see the factors that you need to consider before you do test effort estimation:

a. Size of the system
It would take longer to test a larger system. In some projects, it is possible to know about the size of the system in terms of Function Points, Use Case Points or Lines of Code. You should take the size of the system into account when estimating the test effort.

b. Types of testing required
Sometimes, it is important to perform multiple types of testing on the system. For example, other than functional testing, it may be necessary to perform load testing, installation testing, help files testing and so on. You should create the effort estimates for each type of testing separately.

c. Scripted or exploratory testing
It may be feasible to only execute test cases or do exploratory testing or do both. If you intend to do scripted testing and do not have test cases available, you should estimate the time it would take to create the test cases and maintain them. Scripted testing requires test data to be created. If the test data is not available, you should estimate the effort it would take to create and maintain test data.

d. "Non-testing" activities
Apart from creating and executing tests, there are other activities that a tester performs. Examples include creating test logs/ reports, logging defects and entering time in the project management tool.

e. Test cycles
By a test cycle, I mean a complete round of testing (build verification testing followed by attempted execution of all test cases followed by all defects logged in the defect tracking system). In practice, one test cycle is not sufficient. You should estimate the number of test cycles it would take to promote the system to the client or production.

Now, let us understand the various approaches that you can use for test effort estimation. You may choose any of these approaches for your estimation. However, in my opinion, a combination of multiple approaches works best (by best, I mean that the effort estimates are close to the real actual efforts). In any case, you should be aware about the following approaches:

1. Use historical data from other projects
This approach is useful when you have effort data available from earlier projects which are very similar to the current project. For example, this approach is useful in the case of long-running projects where the test effort data from previous releases is readily available.

2. Your organization's approach
Your organization may have their custom approach to estimate test effort in projects.

3. Delphi method
This is useful when you have a number of experts knowledgeable in the testing to be done. The experts estimate separately and then their estimates are consolidated.

4. Use your own expert judgment
This approach is useful to arrive at a rough test effort estimate quickly.

5. Software size based approach
If the size of the system is available and the formula to convert software size to test effort is available, this approach may be used.

6. Activities based approach
This approach is useful if you can list the activities required. This approach may be used Top-Down (listing the high level activities and breaking them down to lower level activities) or Bottom-Up (listing the individual activities and combining them to higher level activities). Using this approach in the Top-Down manner is better since you can control the level of detail in your effort estimate. Remember to consider activities for each type of testing, any test cases or test data need to be created, the "non-testing" activities and the multiple test cycles.

As I mentioned before, you may choose any approach to do your test effort estimation. However, using at least two approaches is better. This way, you can compare the test effort estimates and address any obvious problems. Whatever hybrid approach you choose, you should document the assumptions made by you in the estimate.

Once you have arrived at the test effort estimate for your project and have convinced the stakeholders that it is a reasonable estimate, it does not stop there. You should track the actual progress in your project constantly to see if it is in line with your test effort estimate. You may find that some of your assumptions were not correct. You should revise your assumptions and your approach in line with your observations.

Continue to use your refined test effort estimation approach across test cycles and releases. In time, you should have a good estimation approach available with you.

Read More

10 reasons why you are not getting job in software testing

You might have applied to so many testing job vacancies, might have received some calls for interviews and even you would have attended some, but still you don’t have the job you are looking for. Well, then there could be many reasons you have not in the right job you dreamed of being.

Be honest and think on below mentioned points. What you did wrong until now? Probably you might get the answer – Why you couldn't crack any software testing interview yet!!

What are these reasons?

1) You have a bad formatted resume. No one cares to read it. You don’t even think to change it.

2) You don’t have passion for testing. You just run behind software testing job as others do. You look for software testing job just for the sake of being somewhere employed.

3) You don’t see the job details before applying, whether it suits your profile or not.

4) You don’t have strong and VALID reason for the question – Why do you want to join/switch to software testing?

5) You have not spent time doing some homework on job openings – about the company, required skills, experience etc.

6) You are faking the software testing experience.

7) You pretend to have all the testing skills.

8 ) You think “Testing is easy-to-do task” and “Anyone can do testing”.

9) You think no training is needed to work in software testing field and you will learn when you are on board.

10) You don’t have practical examples to explain and support your answers.

Read More

Few standard and non standard techniques for Test estamation techniques..

Hi frieneds in my previous blog i had written standard test estimation technique like

1)Best guess method

This is a very basic technique and it is puerly quess work,it is done by the project manager basic of his previous experience it is puerly based on your gut feeling generally time is assigned 200 percentage.

2)ad-hoc Method

The test effort based on tantative time framework the time line is set by the managerial people or done by the clinet without any experience/guess, it is done till finance runout. this is commonly immature organatation or lack of experience or budjet problem.Bassically it is done agile practice.

3)experience based

In this method get the informations from previous experience collected matrics from previous applications

In this method SME and bissuness development ex take an important role who knows the requiremnt and compare with previous project and get the time line. 

4)Work breakdown structure

It is created by breaking down the test project into small pieces. Modules are divided into sub-modules.
Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities.

behalf of sub functionality create a test or project estimation this is mostly companies are used tis method.

5)Delphi technique

It is created by breaking down the test project into small pieces. Modules are divided into sub-modules.
Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities. Each team member are responsible to give the estimation,Basically the team member are the key element.

6)Three point estimation

It is created by breaking down the test project into small pieces. Modules are divided into sub-modules.
Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities.

Formula to find Value for
Estimate (E) = a + (4*m) + b / 6
Standard Deviation (SD) = = (b - a)/6
7)Function point estimation

The FP technique is a direct indicator of the functionality of software application from the user's perspective. This is the most accepted technique used to estimate the size of a software project.

Estimate (E) = a + (4*m) + b / 6
8)Percentage ofdevelopment effort

9)Percentage distribution

Here all the phases of SDLC are divided in parts
and assigned effort in %. Like –
Project management 7%
Requirements 9%
Design 16%
Coding 26%
Test (all test phases) 27%
Documentation 9%
Installation and training 6%
Now testing % is further distributed into all testing phases

Pls resopnd if it is not correct thanks friends.....

10)Use case point estimation process

Read More

What’s Unique about Scrum?

In scrum is unique because it introduce the strict uniform application it is not a best guess and ununiform forecast, to plan and schedule release it will split into sprint,sprint means time between two release, release between two sprint is may be one week or two week some times sprint may be three week,
once sprint is over stake holder,scrum master and team member will make a plan for second release or next step,scrum has very strict and informal method,it is divided into three peso ponsibility, first is stake holder which is responsible for make product backlog,scrum master is responsible for maintaning sprint backlog,sprint backlog contain roles and resposibilty of each and every persion present in sprint, this is also called project plan.one main thing in scrum is team member are from cross platform like take an example of mobile application if it is a client server application,some people from server side some people from client side or working in mobile os,teasting people is also involve in each sprint,

all methodology of testing is adopted from the waterfall model.
one of my friend said to me how it si possible to get a sprint in every week As a seasoned professional software developer and architect, I can tell you quite simply that most career projects should have a minimum two week sprint. A one week sprint is absolutely unheard of in my experience due to unforseen complexities and analysis that must be performed in order to successfully implement solid coding to meet user requirements.

bUt i said that it is possible only in mobile domain or u can say in mobile gaming because gaming concept will never cahnge only few feature u can add to make it intresting.

anyway leave this topic we will talk about scrum,scrum is diveded in three parts one is stake holder,scrum master,and the application team or cross functional team.
Stake holder can maintain the product logs he is story writter he will assign work or he will write a project plan,scrum master can only able to assign the work and get the fesibility report if stake holder is not able to get the estimation he will be dependent on team member,team member will give the time frame as per fesibility.
THe role of scrum
The scrum Master must get involved every time and be creative, negotiate.
Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.
The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Read More

crud methodology in software testing...

Hi friends once again i am writting a new blog for fresher or recently joined software industry,generally when people will join gamining industry and mobile application testing for any platform.everybody is having a basic idea of testing game because now gamining is a very big industry.about application testing now a day everybody is having a gmail account and other sites.so everybody is having an idea about what is software and where it will be used and why used and how it will make our life easier. This is a general idea why we are creating a product simple to make our life more easier.Same why we are creating a software,only scope is different.Generally in a gaming or u can say in mobile industry companies are not involve in more documantation there r few reasion or chalanges everday,ex daily new launch handsets,no of OS,diff memory size, screen size,and less time to complete the project and we have another problem,very difficult to check the overall performance battery cosumption for each application,runtime memory allocation,dta tranfer speed in 2g or in 3g.

Ok we will talk about crud methodology,this methodologies is used in any domain crud means create,read,
update and delete.
When ever u start writting test case or SRS Or Frs,u can use crud metholodology even creating smoke test u can use crud metholodology.
Lets take an example :
The user interface level of most applications. For example, in address book software, the basic storage unit is an individual contact entry. As a bare minimum, the software must allow the user to
Create or add new entries
Read, retrieve, search, or view existing entries
Update or edit existing entries
Delete existing entries
Without at least these four operations, the software cannot be considered complete. Because these operations are so fundamental.
With the help of this method u can create a test case...in next blog i will tell u how to write a test case and what are the imp factors while writting test case...thats all for the day Thanks

Read More

why agile is less efficient than Waterfall?

hi friends i am also practicing a agile environment but i always thinking that water fall model is a more efficient in software development sometimes people are saying that agile is a cheaper than waterfall model but it is not true it is depend on the application or nature of project,team size,timeline,budget.
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.
If in the beginning of the project failures are detected, it takes less effort (and therefore time and money) for this error. In the waterfall model phases to be properly sealed first before proceeding to the next stage. It is believed that the phases are correct before proceeding to the next phase. In the waterfall model lay the emphasis on documentation. In the newer software development methodologies makes it less documentation. This means that when new people in the project, and people leave it is difficult to transfer knowledge. This disadvantage is not the traditional waterfall model. Milestones can be used to monitor the progress of the project to estimate.better forecast estimation.

There is some disadvantages on agile methods
1)More than one people can handle a team.
2)Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.
3)Difficult forecast.
4)There is lack of emphasis on necessary designing and documentation.
5)The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
6)If the team members are not committed, the project will either never complete or fail.
7.It is good for small, fast moving projects as it works well only with small team.
8.If any of the team members leave during a development it can have a huge inverse effect on the project development
9.less time to test.

Read More

Product development life cycle in agile methodology.

1. SME meets with the customer to determine the product requirements and build user stories.
2. Project manager break the requirements into independent tasks and estimate the time to complete each task.
3. Programmers present the customer with the task list and with time estimates, and have them create a priority list of features.
4. The programming team assigns tasks to pairs of programmers based on their skill sets.
5. Each pair creates unit tests for their programming task using the application’s specification.
6. The pair works on their task with the goal of creating a code base that passes the unit tests.
7. Each pair fixes/retests their code until all unit tests are passed.
8. All pairs gather and integrate their code base every day.
9. The team releases a preproduction version of the application.
10. Customers run acceptance tests and either approve the application or create a report identifying the bugs/deficiencies.
11. Programmers release a version into production upon successful acceptance tests.
12. Programmers update time estimates based on latest experience.

Read More

Scrum VS Water fall model

Water fall model is basically a traditional method of application development there are certain step to follow like requiremnet gathering,design development,development,testing,optimazation.but scrum had certain rules it is not a method it is a framework basically there are three leading people involve scrum master,stakeholder,and team.team is basically cross functional team ex server side developer,client developer,tester and others depends on project,project manager may be work as a scrum master or any body who is having a different role like tester,developer.
In water fall model only one activity will be happen like while requirement gathering people will gather the requirement,sme will write use case,then Pm will start arciture databse design,functional diagram,even teser will also start writting test case behalf of use case a requirement,then developer comes into picture with the help of use case and detailed UI dragram he will start writting code once code will be partically done then tester will come to the picture test the build and send report to the developer,then stake holder comes into picture if any how requirement gathering will be not done properlly then stake holder will get the build and say that that is not what i want then again requiremnt gathering will happen desing development then testing...it is really a very long process.

But if company will adopt a scrum frame work split the application into small programme send it to a team team will complete a p[art of app in a short sprint and send it to the stake holder so stake holder is confident atleast he will get someting and he can able to analysis that project is in right track.
Stake holder is always availble to set the priorites and stay in touch with the team.stake holder will create a product logs and set the priorites scrum master has responsible to create a sprint backlogs

backlogs basically contains the current status and roles and responsibility of the team member he can update daily with respect of improvement.

Read More

software release life cycle..

Bug has a life cycle like new,open,assign,reopen,defered,verify and closed. like same software release has his own life cycle there are different phases like pre alpha,alpha,beta,gama or release candidate,production relesae,end of life or no support.
let me explain one by one
pre alpha build or release:In this phase team involve in requirement gathering,design ,development and unit testing start but still build testing is doing by the developer.after alpha testing build comes to tester or in a qa cadare.in this phase only test plan and test case had done in water fall model but in scrum it is a continious process at any stage u can add new test case as per requirement.

Alpha release:Tester comes into the picture alpha is a first release come out from development behalf of test case or requirement tester will start testing write bugs and send report to test lead and PM.
in this phase different kind of testing performs like adhoc,integration,detailed test case execution.

Beta release:it is basically feature complete indication,first time company launch his application in a public some times stakeholder will do the beta testing or asssign third party testing it is some kind of filter.
in this phase different kind of testing performs like Smoke testing,adhoc,integration,detailed test case execution,performance testing,scalability testing.

RC BUILD:release candidate refers to a version with potential to be a final product.In this phase companies creating matrics to get the actual effort and application performance.
it allow only UI and few localization errors.
in this phase different kind of testing performs like adhoc,integration,detailed test case execution, scalability testing,matrics comparisions,Detailed UI testing.
Production build:This a final build launch in a market or ready for shipment.In a mobile domain we can say golden build.

End of life or no support:When software is no longer sold or supported, the product is said to have end of life. it means people will get the advanced system advanced functionality in a same cost or in less.

Read More