Software Testing - Tutorials, QTP, Manual Testing Automation Testing, Load Runner

1. Take the estimates that the developers and testers give you, and double them. :)
Triple them if there is a lot of multi tasking/task switching going on.

In all seriousness, people don't actually work 8 hours a day- there's meetings to attend, and email to read and respond to, and interruptions. Account for this in your schedule by only scheduling people for 6 hrs/day.

No tool is going to do this for you. Estimating is a combination of comparing the work to be with work that's already been done, along with your best guess.

2. If a module does nothing but set a parameter to a Boolean, such as WINDOW_OPEN :== TRUE, it should take less than an hour to test it. If a module reads many schedules and contains many decision paths, it could take a week to test the module. So an estimating tool would have to take module complexity into account.

I have divided software modules into three categories: high, medium, and low complexity. Based on past experience, I have calculated average time to develop and test each type of module. Then I created an Excel spreadsheet that automatically calculates labour hour estimates based on the number of high, medium, and low complexity modules in the software project. It is also a handy tool for the software change board meetings, where the PM must explain the cost, schedule, and risk implications of every change accepted for incorporation into an on-going software project.

As the above first point states -  developers are notoriously bad at estimating. Therefore, objective data should be used whenever possible.

3. Using a tool will not give the reasonable estimation for a project.
From my experience, firstly know the project criticality and then divide them into high level and low level functionalities and then estimate the time required.

For high level functionalities ---
Like where the data is entered and where we are getting the output.
Note:if there are any calculations included in it,then the estimation time will be more.

Low Level functionalities--- Like UI, cosmetic
This will not take much time and here the estimated time is low.

4. According to Roger Pressman, testing takes between 30% and 40% of the total project effort.
I've been guessing this effort to my test and it rarely fails.

5. Here is one approach, if helpful. Derive test cases based on negative and positive flows depending on importance of the functional flow. For example, some functional flows which have high business intensity may need more test cases (4 positive flows, 4 negative flows and 1 normal flow) per functional flow. And some may need less test cases. Again categorize test cases into high, medium and low level test cases, so that it is easy to allocate time per test case. Convert number of test cases into efforts (x number of test cases needs N amount of time).

We have to consider this for test case writing, execution, automation etc. Other than them, test strategy, test plan etc. would be standard efforts.

6. There are different ways for estimation and it depends upon the organization estimation techniques. Some organization follow SMC model, some follow Wide-delphi technique (as defined in 1st Point) + Use case estimation.

It is better to understand the requirements, discuss with your team, gain the information from them, time that requirement might take to test and apply that information for estimating using the SMC model or wide delphi technique. You will reach a certain number. Based on that you can add the PM effort + Risk Mitigation( Code delay, requirement changes) + Buffer.

This will help to reach to the close estimating figure and then treat this estimation as baseline for future estimation.

Your estimation also need to counter the experience of the Team members.

7. The very best estimates will be gained from historical data. Check for the last time you worked on a project of similar scope, architecture, and complexity, pull out the timesheet data, and use that as your estimate.

In my experience, the only way that testing could come out reliably to a set percentage of the overall project (whether 30%, 40%, or whatever), is by self-fulfilling prophecy. Testing stops simply because the deadline's been reached, the budget's exhausted, and other projects are waiting.

8. Also, for some projects, No Estimation method is accurate for testing (TP, FP, etc). All testing estimations are company and project specific.
Testing usually takes 35 - 40% of the entire project effort. 15-20 % variation is always.

Go Back to –> Software Test Management Suite

Related Posts:

1. Estimation Methods for Defect Estimation

2. Software Testing Estimation Guidelines

As the global crisis hit hard, more and more worries about how it will impact in the field of information technology. The companies to be more cautious and sometimes reluctant to give application business. Some customers of the withdrawal of its long-term projects, while others use the possibilities of renegotiating the contracts and lower price quote. Recent scandals also add fuel to the fire, and consequently the levels of customer satisfaction and plenty of projects will fall over expected and cost over expected. And all this happens while the client wants to accomplish better business processes for application vendors to increase customer satisfaction and save more funds.

So what are the challenges faced by testers when working with agile development teams and how they can meet the challenges?

In an agile development environment can not expect things to happen. You must be proactive. This is true for all team members, but is true for Testers. Members of the quality control team can not let anything get in the way of proof. Failure to follow the requirements they require to speak with the owner of the product for clarification. If you are unsure of how developers are going to implement the new code, they require to discuss how the code will execute with the developer. Must be self-directed experts in removing obstacles that prevent them from testing.

Recently, shipping through Application Testing Help I found an interesting article:

Tips to be more innovative in the era of Agile Testing \., written by JB Rajkumar - experienced trainer, quality manager, a frequent speaker for colleges, universities and international conferences.

In his long face Agile Testers of the problems when working with agile development team. And they must be able to apply root cause analysis when you find serious errors so that probably won't happen again. While Agile has different tastes, Scrum is a process for implementing Agile. A quantity of the rules scrum challenge to be followed by all individuals are:

- Get Number of hours of commitment Up Front
- Gather requirements / Estimates Up Front
- Introduction of the actual hours and estimated hours daily.
- Construction Daily
- Keep meetings short daily Scrum
- Code Inspections are critical

In order to meet the challenges, an agile testers require to be innovative with the tools they have. And here are some important keys to innovation:

- A lovely Agile Tester has to be creative in trying to cope up with the speed of development or release. For a tester, being creative is more important than being critical.
- Proof must be professional talent and strives more for learning and innovation of new ideas. Testers talent are seldom satisfied with what they have achieved and always strives to find errors unimaginable value and high priority.
- An Agile check should not be afraid to look at the code a developer and if necessary, and in extreme cases, to correct it.
- Must have a comprehensive view of customer expectations and delivering lovely product.
- Must be authorized to work in pairs. He will participate in pair programming so that the script shorter, better designs and finding more errors.
- Tester must be passionate and brings something distinctive that can be in terms of their innovative ideas or how to take the day to day.

Finally, Agile Tester must have multiple skills, and, Manual, functional performance tests of skills and soft skills such as leadership skills, communication skills etc, in this new world of professional testing focused on adding value to business and application development life cycle and act in a new and elevated position where the combination of structured-driven approach, creativity and ability to articulate and define quality criteria and testing new models will be critical for the success of the business application of technology.

Related Posts:

Challenges in Software Testing

1. Always review specification document with the entire testing team. Discuss each point with team members.

2. While reviewing specification document, look carefully for vague/fuzzy terms like – “ordinarily, most, mostly, some, sometimes, often, and usually” and ask for clarification.

3. Many times it happens that list values are given but not completed. Look for terms: "etc., and so forth, and so on, such as." And be sure all the items/list values are understood.

4. When you are doing spec review, make sure stated ranges don’t contain unstated/implicit assumptions. For example: “The range of Number field is from 10 to 100.

But is it Real, Hex or Integer? Ask for Clarification.

5. Also take care of vague/fuzzy terms like - skipped, eliminated, handled, rejected, processed. These terms can be interpreted in many ways.

6. Take care of ambiguous pronouns like – “The ABC module communicates with the XYZ module and its control flag is set.” But whose control flag?

7. Whenever a scenario/condition is defined in paragraph, then draw a picture of that in ait to understand and try to find the expected result.

8. In the specification document, if a scenario is described which hold calculations, then work on its calculations with minimum two examples.

9. If any point of the specs is not clear then get your queries resolved from the Business Analyst or Product Manager as soon as possible.

10. If any mentioned scenario is complex then try to break it into points.

11. If there is any open issue (under discussion) in the specs (sometimes to be resolved by client), then keep track of those issues.

12. Always go thru the revision history carefully.

13. After the specs are sign off and finalized, if any change come, then see the impacted areas.

Also Read:

1. Testing the design and Requirements of a Software

2. Reviewing Test Cases

4) Which Tab allows to configure conditional execution of Tests

Hint : Conditions like Test # 2 can be executed only if Test # 1 is completed

i. Execution Flow
ii. Design
iii. Attachments
iv. None of The Above

5) Test Cases created in Word / Excel can be uploaded in QC ?
i. Yes
ii. No

6) Types of Graphs available in QC
i. Reports
ii. Graphs
iii. Live Analysis Graphs
iv. All Of the Above

7) Follow Up Alert can be created on
i. A Test in Test Plan Tree
ii. A Test Instance in Execution Grid
iii. A Defect in Defects Grid
iv. All Of the Above

8) Favorites are almost always are High Priority Defects
Hint : User can mark a defect as favorite for easy tracking. A favorite can be PUBLIC or PRIVATE
i. Yes
ii. No

9) In QC, Requirements & Test Plan can be linked ?
i. Only Child Requirements
ii. Only Parent Requirements
iii. Both Child & Parent Requirements
iv. Neither Child nor Parent Requirements

10) In Test Lab Module , is it possible to store separate results for the SAME test case run at different dates and times ?
i. Yes
ii. No

11) Which of the Below is NOT a module in Quality Center
i. Requirements
ii. Business Component
iii. Defects
iv. Automation

12) Defect can be linked to
i. Tests & Test Steps
ii. Run & Run Steps
iii. Requirements
iv. All Of the Above

13) Test Cases can be added in Test Lab Module from
i. Requirements Module
ii. Defects Module
iii. Test Plan Module
iv. All Of the Above

14) Data is DYNAMICALLY updated in
i. Reports
ii. Graphs
iii. Live Analysis Graphs
iv. None Of the Above

15) Is is possible to link a single defect to multiple test cases ?
i. Yes
ii. No
iii. MAYBE. Depends on the TYPE of Defect

16) Which Tests can be scheduled to be run at a specific Date and Time ?
i. Manual Test Cases
ii. Automated Test Cases
iii. Both Manual & Automated Test Cases
iv. Neither Manual nor Automated Test Cases

17) In Test Lab Module
i. Tests are created
ii. Tests are executed
iii. Tests are created and executed

18) Results of an AUTOMATED test case are stored in "-------" module of Quality Center
i. Automation
ii. Test Plan
iii. Test Lab
iv. None of The Above

19) An Instance is
i. A copy of the Requirement
ii. A copy of Test Case
iii. A Copy of Defect
iv. A copy of Email

20) Quality Center is a
i. Defect Tracking Tool
ii. Requirements Management Tool
iii. Test Planning Tool
iv. Comprehensive Test Management Tool

Answers:

1) Quality Center is

Correct answer is: a web based (client/server) tool

2) Traceability Alert is depicted with "@" Mark against a Test

Correct answer is: NO

Traceability Alert is depicted with "!" Mark

3) For Test Plan Module , select the correct folder hierarchy

Correct answer is: Subject - Tests - Test Step

4) Which Tab allows to configure conditional execution of Tests

Correct answer is: Execution Flow

5) Test Cases created in Word / Excel can be uploaded in QC ?

Correct answer is: YES

6) Types of Graphs available in QC

Correct answer is: All Of the Above

7) Follow Up Alert can be created on

Correct answer is: All Of the Above

8) Favorites are almost always are High Priority Defects

Correct answer is: NO

Any priority defect can be marked a favorite.

9) In QC, Requirements & Test Plan can be linked ?

Correct answer is: Both Child & Parent Requirements

10) In Test Lab Module , is it possible to store separate results for the SAME test case run at different dates and times ?

Correct answer is: YES

11) Which of the Below is NOT a module in Quality Center

Correct answer is: Automation

12) Defect can be linked to

Correct answer is: All Of the Above

13) Test Cases can be added in Test Lab Module from

Correct answer is: Test Plan Module

14) Data is DYNAMICALLY updated in

Correct answer is: Live Analysis Graphs

15) Is is possible to link a single defect to multiple test cases ?

Correct answer is: YES

Any type of defect can be linked to multiple test cases.

16) Which Tests can be scheduled to be run at a specific Date and Time ?

Correct answer is: Both Manual & Automated Test Cases

17) In Test Lab Module

Correct answer is: Tests are executed

18) Results of an AUTOMATED test case are stored in "-------" module of Quality Center

Correct answer is: Test Lab

19) An Instance is

Correct answer is: A copy of Test Case

A Test Case copied from Test Plan Module to the Test Lab Module is called an instance of that Test Case

20) Quality Center is a

Correct answer is: Comprehensive Test Management Tool

Also Read:

Mercury Quality Center Interview Questions

QTP Certification HP0-M16 Practice Exam (Questions)

1. Performance testing is fundamentally different from functional testing. In functional testing, we are interested in the user perspective: Does the software provide the required or requested functionality? In performance testing, we are interested in system characteristics. Many of these system elements will affect how the software is perceived but are indirectly related to functionality—e.g., a slow transaction will annoy the requester but the function will still work.
2. The role of the performance tester is similar to that of a consultant. A well-planned performance test requires the involvement of all key personnel—DBA, system administrator, network administrator, developer, etc. The tester understands the test issues and requires the support of others to comprehend the technical issues. It is a rare individual who fully understands all aspects of a system—application, network, database and file system, operating system, etc.
3. There is a critical difference between performance goals and business goals . Many people confuse the two, and this misunderstanding negatively impacts the viability of the performance test. The fundamental difference between the two is simple. If you cannot measure a system-based resource to assess the performance, it is not a performance goal—i.e., a goal is to improve user productivity. However, there is no system resource you can measure to prove this goal has been met. The system may be performing fine, but the user is just slow in using the application.
4. Performance testing requires extensive time and effort. To be successful, a performance test has to begin at the start of the project with planning, analysis, and design. This is especially true for rapid development projects (agile, etc.). The remaining six areas listed below take considerable time to analyze and plan the testing. Trying to attempt a first-time performance test one to two weeks (or days) before shipping is insane.
5. Performance testing requires an environment that resembles as closely as possible the actual target environment. Many aspects of the application and system will behave differently on varying-size environments. Many aspects of applications and systems are non-linear, so methods such as extrapolation are highly dangerous and typically invalid from the start. Extrapolation is a linear predictive model; systems tend to be nonlinear.
6. Load tools are the least important issue in performance testing. If you do not understand the key issues and aspects of the test, especially those listed below, a tool will give you numbers that have no real meaning. Tools provide answers; if you don’t know the question, what good is the answer? Additionally, there are three types of tools that must interoperate successfully: load generators, monitors, and response time tools (end to end). There are numerous issues that must be addressed for tools to be useful.
7. A successful performance test requires a proper load definition—an operation profile (OP). All too often I hear people refer to performance as a simple calculation: Load = Volume/Time. This is where many tests fail. Volume of what? And more importantly, over what time period? Key elements of an OP are the time period, the number and types of activities in each time sample, and the frequency and distribution of those activities. The interaction of events is often the cause of performance problems. Failure to have an accurate model of event (user) behaviour renders the test invalid.
8. There are many types of tests that we can run. There are tests to measure specific resources (CPU, memory, bandwidth, etc.), assess response time, and press the system to its limits (stress). The types of tests in which we are interested will be driven by our performance goals, possible environmental issues, etc. Just running a lot of events and measuring system elements is not performance testing.
9. Many tests fail before they begin because there are no measures defined to indicate what constitutes poor performance. What are poor response times, excess load, and limits on memory and CPU? These measures need to be understood at the beginning of the test so the tests can indicate where and when problems are occurring.
10. Tools provide answers. The issues noted above are essential to ensure that your tools provide useful information. Most load generation tools generate dozens of measures. These numbers make great graphs but are of little use if you don’t know what you are looking for. If you want to get maximum value from your tools, you need to address the previous nine items on this list. Tools are great, but a fool with a tool is still a fool.

Read Also:

1. 10 Things You Might Not Know About Sustainable Test-driven Development (TDD).

2. 10 Things You Might Not Know About using Testing Standards