What Is Performance Testing: Guide to Speed, Scalability and Reliability

Users don’t wait. If a page stalls, a checkout hangs, or a dashboard times out, people leave and systems buckle under the load. Performance testing is how teams get ahead of those moments. It measures how fast and stable your software is under realistic and extreme conditions. Done right, it gives you hard numbers on speed, scalability, and reliability, and a repeatable way to keep them healthy as you ship new features.

Problem:

Modern applications are a web of APIs, databases, caches, third-party services, and front-end code running across networks you don’t fully control. That complexity creates risk:

• Unpredictable load: Traffic comes in waves—marketing campaigns, product launches, or seasonal surges create sudden spikes.
• Hidden bottlenecks: A single slow SQL query, an undersized thread pool, or an overzealous cache eviction can throttle the entire system.
• Cloud cost surprises: “Autoscale will save us” often becomes “autoscale saved us expensively.” Without performance data, cost scales as fast as traffic.
• Regressions: A small code change can raise response times by 20% or increase error rates at high concurrency.
• Inconsistent user experience: Good performance at 50 users says nothing about performance at 5,000 concurrent sessions.

Consider this real-world style example: an ecommerce site that normally handles 200 requests per second (RPS) runs a sale. Marketing expects 1,500 RPS. The team scales web servers but forgets the database connection pool limit and leaves an aggressive retry policy in the API gateway. At peak, retries amplify load, connections saturate, queue times climb, and customers see timeouts. Converting that moment into revenue required knowledge of where the limits are, how the system scales, and what fails first—exactly what performance testing reveals.

Possible methods:

Common types of performance testing

Each test type answers a different question. You’ll likely use several.

• Load testing — Question: “Can we meet expected traffic?” Simulate normal and peak workloads to validate response times, error rates, and resource usage. Example: model 1,500 RPS with typical user think time and product mix.
• Stress testing — Question: “What breaks first and how?” Push beyond expected limits to find failure modes and graceful degradation behavior. Example: ramp RPS until p99 latency exceeds 2 seconds or error rate hits 5%.
• Spike testing — Question: “Can we absorb sudden surges?” Jump from 100 to 1,000 RPS in under a minute and observe autoscaling, caches, and connection pools.
• Soak (endurance) testing — Question: “Does performance degrade over time?” Maintain realistic load for hours or days to catch memory leaks, resource exhaustion, and time-based failures (cron jobs, log rotation, backups).
• Scalability testing — Question: “How does performance change as we add resources?” Double pods/instances and measure throughput/latency. Helps validate horizontal and vertical scaling strategies.
• Capacity testing — Question: “What is our safe maximum?” Determine the traffic level that meets service objectives with headroom. Be specific: “Up to 1,800 RPS with p95 < 350 ms and error rate < 1%.”
• Volume testing — Question: “What happens when data size grows?” Test with large datasets (millions of rows, large indexes, deep queues) because scale often changes query plans, cache hit rates, and memory pressure.
• Component and micro-benchmarking — Question: “Is a single function or service fast?” Useful for hotspot isolation (e.g., templating engine, serializer, or a specific SQL statement).

Key metrics and how to read them

Meaningful performance results focus on user-perceived speed and error-free throughput, not just averages.

• Latency — Time from request to response. Track percentiles: p50 (median), p95, p99. Averages hide pain; p99 reflects worst real user experiences.
• Throughput — Requests per second (RPS) or transactions per second (TPS). Combine with concurrency and latency to understand capacity.
• Error rate — Non-2xx/OK responses, timeouts, or application-level failures. Include upstream/downstream errors (e.g., 502/503/504).
• Apdex (Application Performance Index) — A simple score based on a target threshold (T) where satisfied ≤ T, tolerating ≤ 4T, and frustrated > 4T.
• Resource utilization — CPU, memory, disk I/O, network, database connections, thread pools. Saturation indicates bottlenecks.
• Queue times — Time waiting for a worker/thread connection. Growing queues without increased throughput are a red flag.
• Garbage collection (GC) behavior — For managed runtimes (JVM, .NET): long stop-the-world pauses increase tail latency.
• Cache behavior — Hit rate and eviction patterns. Cold cache vs warm cache significantly affects results; measure both.
• Open vs closed workload models — Closed: fixed users with think time. Open: requests arrive at a set rate regardless of in-flight work. Real traffic is closer to open, and it exposes queueing effects earlier.

Example: If p95 latency climbs from 250 ms to 900 ms while CPU remains at 45% but DB connections hit the limit, you’ve likely found a pool bottleneck or slow queries blocking connections—not a CPU bound issue.

Test data and workload modeling

Good performance tests mirror reality. The fastest way to get wrong answers is to test the wrong workload.

• User journeys — Map end-to-end flows: browsing, searching, adding to cart, and checkout. Assign realistic ratios (e.g., 60% browse, 30% search, 10% checkout).
• Think time and pacing — Human behavior includes pauses. Without think time, concurrency is overstated and results skew pessimistic. But when modeling APIs, an open model with arrival rates may be more accurate.
• Data variability — Use different products, users, and query parameters to avoid cache-only results. Include cold start behavior and cache warm-up phases.
• Seasonality and peaks — Include known peaks (e.g., Monday 9 a.m. login surge) and cross-time-zone effects.
• Third-party dependencies — Stub or virtualize external services, but also test with them enabled to capture latency and rate limits. Be careful not to violate partner SLAs during tests.
• Production-like datasets — Copy structure and scale, not necessarily raw PII. Use synthetic data at similar volume, index sizes, and cardinality.

Environments and tools

Perfect fidelity to production is rare, but you can get close.

• Environment parity — Mirror instance types, autoscaling rules, network paths, and feature flags. If you can’t match scale, match per-node limits and extrapolate.
• Isolation — Run tests in a dedicated environment to avoid cross-traffic. Otherwise, you’ll chase phantom bottlenecks or throttle real users.
• Generating load — Popular open-source tools include JMeter, Gatling, k6, Locust, and Artillery. Managed/cloud options and enterprise tools exist if you need orchestration at scale.
• Observability — Pair every test with metrics, logs, and traces. APM and distributed tracing (e.g., OpenTelemetry) help pinpoint slow spans, N+1 queries, and dependency latencies.
• Network realism — Use realistic client locations and latencies if user geography matters. Cloud-based load generators can help simulate this.

Common bottlenecks and anti-patterns

• N+1 queries — Repeated small queries per item instead of a single batched query.
• Chatty APIs — Multiple calls for a single page render; combine or cache.
• Unbounded concurrency — Unlimited goroutines/threads/futures compete for shared resources; implement backpressure.
• Small connection pools — DB or HTTP pools that cap throughput; tune cautiously and measure saturation.
• Hot locks — Contended mutexes or synchronized blocks serialize parallel work.
• GC thrashing — Excess allocations causing frequent or long garbage collection pauses.
• Missing indexes or inefficient queries — Full table scans, poor selectivity, or stale statistics at scale.
• Overly aggressive retries/timeouts — Retries can amplify incidents; add jitter and circuit breakers.
• Cache stampede — Many clients rebuilding the same item after expiration; use request coalescing or staggered TTLs.

Best solution:

The best approach is practical and repeatable. It aligns tests with business goals, automates what you can, and feeds results back into engineering and operational decisions. Use this workflow.

1) Define measurable goals and guardrails

• Translate business needs into Service Level Objectives (SLOs): “p95 API latency ≤ 300 ms and error rate < 1% at 1,500 RPS.”
• Set performance budgets per feature: “Adding recommendations can cost up to 50 ms p95 on product pages.”
• Identify must-haves vs nice-to-haves and define pass/fail criteria per test.

2) Model realistic workloads

• Pick user journeys and arrival rates that mirror production.
• Include think time, data variability, cold/warm cache phases, and third-party latency.
• Document assumptions so results are reproducible and explainable.

3) Choose tools and instrumentation

• Pick one primary load tool your team can maintain (e.g., JMeter, Gatling, k6, Locust, or Artillery).
• Ensure full observability: application metrics, infrastructure metrics, logs, and distributed traces. Enable span attributes that tie latency to query IDs, endpoints, or user segments.

4) Prepare a production-like environment

• Replicate instance sizes, autoscaling policies, connection pool settings, and feature flags. Never test only “dev-sized” nodes if production uses larger instances.
• Populate synthetic data at production scale. Warm caches when needed, then also test cold-start behavior.

5) Start with a baseline test

• Run a moderate load (e.g., 30–50% of expected peak) to validate test scripts, data, TLS handshakes, and observability.
• Record baseline p50/p95/p99 latency, throughput ceilings, and resource usage as your “known good” reference.

6) Execute load, then stress, then soak

• Load test up to expected peak. Verify you meet SLOs with healthy headroom.
• Stress test past peak. Identify the first point of failure and the failure mode (timeouts, throttling, 500s, resource saturation).
• Soak test at realistic peak for hours to uncover leaks, drift, and periodic jobs that cause spikes.
• Spike test to ensure the system recovers quickly and autoscaling policies are effective.

7) Analyze results with a bottleneck-first mindset

• Correlate latency percentiles with resource saturation and queue lengths. Tail latency matters more than averages.
• Use traces to locate slow spans (DB queries, external calls). Evaluate N+1 patterns and serialization overhead.
• Check connection/thread pool saturation, slow GC cycles, and lock contention. Increase limits only when justified by evidence.

8) Optimize, then re-test

• Quick wins: add missing indexes, adjust query plans, tune timeouts/retries, increase key connection pool sizes, and cache expensive calls.
• Structural fixes: batch operations, reduce chattiness, implement backpressure, introduce circuit breakers, and precompute hot data.
• Re-run the same tests with identical parameters to validate improvements and prevent “moving goalposts.”

9) Automate and guard your pipeline

• Include a fast performance smoke test in CI for critical endpoints with strict budgets.
• Run heavier tests on a schedule or before major releases. Gate merges when budgets are exceeded.
• Track trends across builds; watch for slow creep in p95/p99 latency.

10) Operate with feedback loops

• Monitor in production with dashboards aligned to your test metrics. Alert on SLO burn rates.
• Use canary releases and feature flags to limit blast radius while you observe real-world performance.
• Feed production incidents back into test scenarios. If a cache stampede happened once, codify it in your spike test.

Practical example: Planning for an ecommerce sale

Goal: Maintain p95 ≤ 350 ms and error rate < 1% at 1,500 RPS; scale to 2,000 RPS with graceful degradation (return cached recommendations if backend is slow).

1. Workload: 60% browsing, 30% search, 10% checkout; open model arrival rate. Include think time for browse flows and omit it for backend APIs.
2. Baseline: At 800 RPS, p95 = 240 ms, p99 = 480 ms, error rate = 0.2%. CPU 55%, DB connections 70% used, cache hit rate 90%.
3. Load to 1,500 RPS: p95 rises to 320 ms, p99 to 700 ms, errors 0.8%. DB connection pool hits 95% and queue time increases on checkout.
4. Stress to 2,200 RPS: p95 600 ms, p99 1.8 s, errors 3%. Traces show checkout queries with sequential scans. Connection pool saturation triggers retries at the gateway, amplifying load.
5. Fixes: Add index to orders (user_id, created_at), increase DB pool from 100 to 150 with queueing, add jittered retries with caps, enable cached recommendations fallback.
6. Re-test: At 1,500 RPS, p95 = 280 ms, p99 = 520 ms, errors 0.4%. At 2,000 RPS, p95 = 340 ms, p99 = 900 ms, errors 0.9% with occasional fallbacks—meets objectives.
7. Soak: 6-hour run at 1,500 RPS reveals memory creep in the search service. Heap dump points to a cache not honoring TTL. Fix and validate with another soak.

Interpreting results: a quick triage guide

• High latency, low CPU: Likely I/O bound—database, network calls, or lock contention. Check connection pools and slow queries first.
• High CPU, increasing tail latency: CPU bound or GC overhead. Optimize allocations, reduce serialization, or scale up/out.
• Flat throughput, rising queue times: A hard limit (thread pool, DB pool, rate limit). Increase capacity or add backpressure.
• High error rate during spikes: Timeouts and retries compounding. Tune retry policies, implement circuit breakers, and fast-fail when upstreams are degraded.

Optimization tactics that pay off

• Focus on p95/p99: Tail latency hurts user experience. Optimize hot paths and reduce variance.
• Batch and cache: Batch N small calls into one; cache idempotent results with coherent invalidation.
• Control concurrency: Limit in-flight work with semaphores; apply backpressure when queues grow.
• Right-size connection/thread pools: Measure saturation and queueing. Bigger isn’t always better; you can overwhelm the DB.
• Reduce payloads: Compress and trim large JSON; paginate heavy lists.
• Tune GC and memory: Reduce allocations; choose GC settings aligned to your latency targets.

Governance without red tape

• Publish SLOs for key services and pages. Keep them visible on team dashboards.
• Define performance budgets for new features and enforce them in code review and CI.
• Keep a living playbook of bottlenecks found, fixes applied, and lessons learned. Reuse scenarios across teams.

Common mistakes to avoid

• Testing the wrong workload: A neat, unrealistic script is worse than none. Base models on production logs when possible.
• Chasing averages: Median looks fine while p99 burns. Always report percentiles.
• Ignoring dependencies: If third-party latency defines your SLO, model it.
• One-and-done testing: Performance is a regression risk. Automate and re-run on every significant change.
• Assuming autoscaling solves everything: It helps capacity, not necessarily tail latency or noisy neighbors. Measure and tune.

Quick checklist

• Clear goals and SLOs defined
• Realistic workloads with proper data variance
• Baseline, load, stress, spike, and soak tests planned
• Full observability: metrics, logs, traces
• Bottlenecks identified and fixed iteratively
• Automation in CI with performance budgets
• Production monitoring aligned to test metrics

In short, performance testing isn’t a one-off gate—it’s a continuous practice that blends measurement, modeling, and engineering judgment. With clear objectives, realistic scenarios, and disciplined analysis, you’ll not only keep your app fast under pressure—you’ll understand precisely why it’s fast, how far it can scale, and what it costs to stay that way.

Some books about performance:

These are Amazon affiliate links, so I make a small percentage if you buy the book. Thanks.

• Systems Performance (Addison-Wesley Professional Computing Series) (Buy from Amazon, #ad)
• Software Performance Testing: Concepts, Design, and Analysis (Buy from Amazon, #ad)
• The Art of Application Performance Testing: From Strategy to Tools (Buy from Amazon, #ad)

Overview on Performance Testing

What is Performance Testing?

Explain the concept of Spooling and Buffering?

Concept of Spooling

- In the field of computer science, the ‘simultaneous peripheral operations on – line’ has been shortened down to the acronym ‘spool’. 

- A SPOOL software such as that of the IBM’s ‘SPOOL system’ was used by the computer systems in the time period from late 1950 to early 1960. 

- From one medium to another, files could be copied using this software. For example:

1. From tape to punch card
2. From punch card to tape
3. From tape to printer
4. From one card to another card

- IBM released less expensive software called the IBM 1401 that from some time brought down the application of the spool software.

- The print spooling is the most common application of this concept.

- The documents to be printed are formatted and stored at an area of the disk and retrieved when the print command is given.

- The printer prints out these documents at its defined rate. 

- Typically, at a time only one document can be printed by a printer and for doing so it takes a few minutes or seconds depending up on how fast it is. 

- Spooling speeds up this process, but how? 

- With a spool software many documents can be written to the print queue by the multiple processes without having to wait. 

- As soon as the process wrote its document in the spooling device, it was free to carry out the other tasks. 

- At the same time another process would handle the printing of the document. 

- If there was no spooling, the processor would not be able to continue until and unless the pending process is finished. 

- This would lead to long waits during processing and thus making the paradigm inefficient.

Concept of Buffering

- The physical memory storage has a region where it temporarily stores the data when it is being sent to another location.

- Typically whenever data is taken from some input device such as a keyboard or a mouse, it is stored in the buffer before sending it to the processor or output device. 

- Buffers can be implemented either through some virtual data buffer or in a fixed memory location.

- In majority of the cases, implementation of buffers is done with software that point to some location in the physical memory and use faster RAM. 

- The data access from buffers is quite fast when compared to that of the hard disk drives. 

- Buffers are used wherever a difference occurs between the rate of receiving data and rate of processing it.

- It also occurs if the two data rates are variable such as in online video streaming, printer spooler and so on. 

- The timing in a buffer is adjusted with the implementation of a FIFO algorithm or we can say a queue in the memory. 

- This would allow at the same time to write the data at the one end and read it from another end and both being done at different rates.

- Buffers are used along with I/O to hardware like in transmitting and receiving data in a network, disk drives, playing some song on the speakers etc.

- Buffers used in telecommunication are called the telecommunication buffers and make use of a storage medium or buffer routine.

- This routine compensates for the two different rates while receiving and sending data. 

- Buffers are also used in making interconnections between digital circuits working at different rates, for making timing corrections, delaying transmission time and so on. 

Explain IBM Rational Automation Framework?

What is Rational Automation Framework?

- Rational automation frame work is a tool developed by IBM using which control can be gained over the middle-ware environments.
- It is also used for the automation of the deployment tasks and complex administration.
- This automation frame work is highly customizable.
- Using it, one can obtain automated build – outs.
- Using it, one can even deploy a number of applications and manage the configuration of the application.
- It has been recorded that with the use of rational automation frame work, you can cut down the operational costs by huge margins and production can be improved.
- This automation frame work can be extended.
- The rational automation frame work provides a rich automation support for the following:
1. Web sphere middleware
2. JBoss application server
3. Web logic application server

Features of Rational Automation Framework

The following are features of the rational automation frame work:
1. Increases the productivity while reducing the staffing needs of the routine tasks. The routine tasks included are:
a) Automation of the manual operations
b) Error prone tasks
c) Freeing up the admin resources which are scarce.
All these tasks help in focusing up on strategic projects.

2. It helps in the improvement of application’s quality, consistency and speed. All these three factors are used to deliver applications that are business critical with the help of process which possesses the following three qualities namely accuracy, consistency and repetition.

3. It helps in the reduction of the cost of compliance, IT governance and disaster recovery. It improves the following 3 things without causing any overheads:
a) Governance
b) Disaster recovery planning and
c) Automated documentation for compliance

4. It automates the below mentioned things:
a) Environment build – outs
b) Configuration management
c) Application deployment tasks
For the following portfolio:
a) Web sphere foundation
b) Web sphere BPM suite
c) Web sphere portal

5. It is a great means for extending the automation benefits as well as qualities of services to the following:
a) Web sphere connectivity (web sphere message broker and MQ)
b) Red hat JBoss application server
c) Oracle web logic application server
This it does via the MidVision extensions to IBM RAF.

6. Helps in facilitating team – based administration with the help of a robust automation engine with improved reliability and performance.

7. Makes sure that the virtual patterns are efficiently managed with rapid provisioning with web sphere cloud burst appliance.

8. Enhances the control and workflow management in data center environments by integrating it with LDAP directories, source control tools, and rational asset manager.

This product comes with extensions that assist in the management of the additional middle-ware environments such as WMB, MQ, Jboss and web logic etc. These environments are managed with the same QoS and automation platform. The web sphere cloud burst appliance of the rational application developer helps in speeding up the virtualization environments with hyper-visor images.

We shall now state some of the features and their benefits:
1. It is a data driven and centralized automation frame work: it helps in ensuring that the appropriate data is being associated with the appropriate application and in the right environment every time.
2. It has got a rich user interface. The middle-ware configuration data can be designed, edited and managed using this frame work. New configurations can be added to a cell.
3. It is also an environment generation wizard that can also be used for specifying the criteria for a particular environment.
4. This product comes with self – documentation feature which ensures that the appropriate deployment information is captured and artifacts are properly managed.
5. Agent less technology
6. Customizable
7. Deployment artifacts are separated from the deployment process.

What are other Silk products? Explain in brief each product?

The silk products of the Borland have created quite a buzz in the field of test automation. They have proved to be of great help when it comes to automating the test scripts and performing other tasks related to testing. 

One example of a popular silk product is the Borland silk test. The silk products over the time have been known to provide specific solutions for specific problems as well as specific needs. Silk products are even available for mobile operating systems such as the iOS, android, blackberry OS and windows. 

Silk products for mobile are used for carrying out the following tests:

1. Functional testing
2. Performance testing
3. Test management and so on.

About Silk Products

- These products ensure that a better software is delivered every time the development takes place no matter what platform is being used by the user’s device. 

- With the new platforms coming in to picture, a different approach is required. - But the silk products always ensure that consistent high quality is delivered for the mobile applications and software both in the terms of performance as well as functionality. 

- Silk products can also be used with SAP. 

- The silk products for use with SAP ensure that your SAP implementation fits your business very well.

- These help in the fast delivery of the SAP projects by providing a ‘complete solution manager driven life cycle’ which actually tailors the silk products to the SAP environment defined by the user. 

- The silk products come with simple to understand and use tools, thus ensuring that money is saved and there is a match between the functionality and the requirements. 

Types of Silk Products

Now we shall discuss about some silk products one by one:

1. Silk test: This silk product is for producing the quality software in the most appropriate way. It is actually a test automation tool and automates the following tests:

a)    Functional tests and

b)    Regression tests

Till now the silk test is considered to be the leading product in terms of the following qualities:

     a)    Speed - fastest

     b)    Reliability – most reliable

     c)    Efficiency- most efficient

     d)    Scalable test automation development solution

     e)    Quality

     f)     Business teams

     g)    Delivery of quality software

The silk test is the ideal tool for mastering the automation technology for automating the most critical applications.

2. Silk Performer: 

- This silk product facilitates the application performance testing. 

- This silk product ensures that your application software meets even the most critical performance expectations as well as the service level requirements in a most cost effective and efficient way. 

- It comes with a feature called cloud integration using which massive loads can be quickly simulated without any requirement of the investments in the load testing set up and hardware. 

- Over the time, it has proven to guarantee the customer satisfaction by making high performing and reliable applications.

3. Silk Central: 

- This silk product is used for collaborative test management. 

- It controls as well prioritizes all the aspects of the test management and test by an automated collaboration across the organization, thus ensuring that only the high quality software is delivered. 

- This product also enables collaboration as well as increases the visibility in the all the testing phases.

4. Silk test Partner: 

- This silk product is also used for test automation apart from the silk test. 

- Here, the older scripting approach is replaced with a visual and non technical approach.

5. Silk QALoad: 

- This silk product guarantees performance by performing stress tests on associated networks and enterprise systems by simulation of 1000s of users performing different operations but at the same instant of time.

What are the main attributes of test automation?

Test automation is nowadays counted among the best software development aids that we have today. It is a great testing aid that seeks to resolve the drudgery of the testers. Test automation has become so common nowadays that every one of us knows quite a lot about it.

What does Test Automation do?

- Test automation actually controls the execution of the test cases by using an automated process. 

- Also, the comparison of the actual and the predicted outcome takes place in the same and "take it easy" manner.  

- One thing that should be noted is that only those manual processes can be automated which have deployed a formalized testing process. 

- In the test automation process, the user actions are recorded and the checkpoints are introduced in to the testing script so that playing it back from a particular point is made easy when you have to perform regression tests. 

- The manual tests that passed can be automated and is mostly used in the testing methodologies like:

1. Data driven testing
2. Regression testing
3. Performance testing and so on.

Attributes of Test Automation

By attributes, we mean the characteristics of the test automation process. It has got quite a lot of positive attributes. So let us what all attributes we can state for test automation:

1. Repeatability:

Automation supports repeated execution of a test case several times again and again. When you need to execute the same test case again and again the test automation comes as a big win for you.

2. Programmability: 

The test cases can be programmed to be executed on a number of different machines whereas the manual tests have to be executed in a sequential way one after the other.

3. Reliability: 

You can rely on test automation for repeat-ability and accuracy.

4. Impact

5. Criticality

6. Maintainability: 

The maintenance is just that you have to update the test automation suites for every new release of the software system or application.

7. Flexibility: 

With test automation it becomes quite easy for you to run automated tests that frequently change according to the regressions at particular time intervals and also the tests can be run in mainstream scenarios.

8. Efficiency: 

The ratio of total cost to the required effort need is reasonable.

9. Portability: 

The automated tests can be executed in different environments unlike manual test cases.

10.Robustness: 

The automated tests are quite effective for the software systems or applications that are quite unstable or change rapidly.

11. Usability: 

The automated tests can be used to a large extent by different types of users.

12. Speed

13. Accuracy

14. Relentlessness: 

The automated test generator as well as the process never gets tired generating and running test cases.

There are some tests like exploratory testing and usability which cannot be automated because of their free style. Testers involved in a testing team support diverse software systems and applications that are quite unrelated to each other. 

- If the projects that demands implementation of a unique testing strategy, then the testers involved in the whole will appear more to be a hindrance rather than being a help. 

- The testers will require tie to get adjusted to the new environment which unfortunately they cannot get and thus lowering the level of their productivity. 

- We cannot waste time on re- engineering the development frame works but we can surely harness test automation power for every new application that we need to develop. 

- The application can be continuously improved since the test automation has got so many positive attributes that can surely benefit the whole testing process. 

What is meant by project velocity?

The project velocity is one of the terms that you come across while discussing about the iteration planning and release planning! The project velocity has a got a very important and  not to be ignored part to play in these two mentioned planning processes but still most of us are not aware of its importance. 

This article is centred on the project velocity and has been discussed in detail. Like the normal physics velocity, the project velocity gives the speed of the development of a software project. 

In other words, the project velocity gives the amount of work being and efforts being spent on the software project. 

About Project Velocity

- The project is simply the summation of all the estimates of the user stories that were involved in the iteration. 

- For the release planning, you add up the estimates of the user stories and for the iteration planning the estimates of the programming tasks are added up. 

- But anyway, both the factors can employed for determining the project velocity in the case of the iteration planning. 

- In the iteration planning meeting, the number of the user stories chosen by the customer is same as it was in the previous iteration. 

- There is a rule that the project velocity of the consecutive iterations must not exceed their preceding iterations. 

- These programming tasks are nothing but a broken down or divided version of the user stories. 

- The development team is supposed to take up or sign up for only the same number of tasks that were present in the previous iteration. 

- Such an arrangement proves to be a great help to the developers when they stuck in a sticky situation and need to recover and clean up from it and thus getting the average for the estimates. 

- The project velocity is suppose to rise when the developers are allowed to question the customers for other user stories when they have already finished their work and tasks like cleaning up are also accomplished.

Please do not think that you will get the project velocity consistent throughout the development cycle! It is expected to follow through some ups and downs. 

- But if a dramatic change is observed in the project velocity, then it is an issue of concern. 

- But there is no need to worry since all this can be kept in check by re- estimation and re- negotiation of the release plan. 

- It is not just in this case that the project velocity may change! 

- Even when the system is put under production for the maintenance tasks, again the project velocity is subjected to changes. 

- Division of the project velocity by the length of the iteration or the number of people involved. 

- Furthermore, the number of the people involved in the iteration is not an appropriate way for making comparisons between the productivity of two products. 

- This is so because each and every team has got its own different criteria for estimating the user stories and so we get some high estimation and some low estimation. 

- Important is to keep a track of the amount of work being done on the project so that a steady project velocity for the development can be maintained that can also be easily predicted.

The problem comes while making the first estimation! 

- At least for the following iterations you will have a clue that what project velocity is required. 

- If this measure is used properly you may be able to detect a major fault in your project much before the time at which you would have known with the help of the traditional development methods. 

What are the problems of a C compiler?

Every programming language has some advantages and disadvantages which are not present in the other languages. Some languages are capable of solving some problems better as compared to other languages. But the point is that most of the problems have similar needs, requirements and logic, so the point where languages differ from each other is the efficiency with which they solve the problem.

Some provide more efficient and fluent solutions while others don’t. As we all know C is a basic programming language which was developed to solve problems and develop programs relating to kernels of the operating systems, compilers and graphical user interfaces. C compiler though being fast is not so efficient. It provides many downsides for a large number of problems. Many of us think that C is the fastest language but this is not true.

C++ compiles most of the C programs at the same speed as C++ does. Some of the features of C language like virtual function calls result in over heads. C is not object oriented. This in turn makes it more inconvenient to implement some programs. It is not able to force object orientation everywhere. C makes some programs that require object oriented programming more error prone. C has got a weak typing system as compared to other programming languages. This leads to many programming errors after compilation of the program.

A bigger standard library C++ allows the full use of the C standard library. This is very important of course, as the C standard library is an invaluable resource when writing real world programs.
- C++ has a library called the Standard Template Library.
- This standard library contains a number of templates that can be used while developing programs almost of any kind.
- It also includes many common data structures which are very useful like data lists, maps, data sets, etc. the standard library routines and its data structures are tailored to the specific needs of the programmer.
- Though standard library is no gold knife, still it does gives a great help in many programs for solving general purpose related problems. Many tasks like implementing a linked list in C take a lot of time.
- Though the compilation is fast but, who has got that much time to write those lengthy codes. That time you will feel the need for a better compiler which provides a shorter and effective code for implementing lists and other sorts of data structures in array form.

Even though C language was standardized long back in 1998, but till date we don’t have any good compilers for this language. It’s a very complex language and so requires a heavy compiler like itself to compile it. Another problem related to C compiling is that being a big and complex language, many few people have its correct knowledge of usage. A lot depends on the programmer also. If you are typing in the wrong code you are sure to get bad results.
Today also most of the programs are written in C. a need is felt to convert them to another programming language for better compilation. But the conversion is no good solution. Conversion of a C language program code is often ended up in rewriting almost the entire content of the program.

Programs written in C will always have 2 major problems. Firstly their code will be unusually lengthy and time consuming. Secondly, the program execution will be slower even though the compilation time is very less. The C program codes require more time to read, write and understand. C compiler being ineffective can crash any time. There’s a lack of high level routines in C compiler.

What are different characteristics of design patterns?

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
- It is a proven solution to problems that keep recurring.
- They are reusable solutions to common problems.
- Design patterns are not frameworks.
- Design patterns are more abstract than frameworks.
- Design pattern cannot be directly implemented.
- Design patterns are more primitive than a framework.
- A design pattern cannot incorporate a framework.
- Patterns may be documented using one of several alternative templates.
- Design patterns can speed up the development process by providing tested, proven development paradigms.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Patterns allow developers to communicate using well-known, well understood names for software interactions.

A pattern description includes the following elements:
- name of the pattern should be meaningful.
- context of the pattern represents the circumstances or preconditions.
- Problem description that pattern addresses should be provided.
- Solution is a description of the static and dynamic relationships amongthe components of the pattern.
The use of design patterns requires careful analysis of the problem that is to be
addressed and the context in which it occurs.

Overview of Performance Testing and types of performance testing

Performance Testing finds out the speed and efficiency of the system, computer, product or device. Performance testing is testing that is performed, to determine how fast some aspect of a system performs under a particular workload. A software related performance problem can easily get identified through performance testing.
Performance testing demonstrate that the system meets performance criteria. It can compare two systems to find which performs better. It can also measure what parts of the system or workload causes the system to perform badly.

Types of Performance Testing

1.Load Testing : A load test is usually conducted to understand the behavior of the application under a specific expected load. Examples of load testing include:
- Downloading a series of large files from the Internet.
- Running multiple applications on a computer or server simultaneously.
- Assigning many jobs to a printer in a queue.

2.Stress Testing: It determines the load under which a system fails, and how it fails. There are various varieties of Stress Tests, including spike, stepped and gradual ramp-up tests.
3.Volume Testing: It test what happens if huge amounts of data are handled.
4.Soak Testing: The system is runm at high levels of load for prolonged periods of time.
5.Configuration Testing: The process of testing a system with each of the configurations of software and hardware that are supported.
7.Timing testing: It evaluates response times and time to perform an action.

Performance Issues of Tertiary storage

There are three aspects of tertiary-storage performance :
- Speed : There are two aspects of speed in tertiary storage are bandwidth and
latency.
Bandwidth is measured in bytes per second.
* Sustained bandwidth – average data rate during a large transfer; # of bytes/transfer time.Data rate when the data stream is actually flowing.
* Effective bandwidth – average over the entire I/O time, including seek or locate, and cartridge switching. It drive’s overall data rate.

Access latency is the amount of time needed to locate data.
* Access time for a disk – It moves the arm to the selected cylinder and wait for the rotational latency; < 35 milliseconds.
* Access on tape requires winding the tape reels until the selected block reaches the tape head; tens or hundreds of seconds.
* Generally say that random access within a tape cartridge is about a thousand times slower than random access on disk.
The low cost of tertiary storage is a result of having many cheap cartridges share a few expensive drives. A removable library is best devoted to the storage of infrequently used data, because the library can only satisfy a relatively small number of I/O requests per hour.

- Reliability : A fixed disk drive is likely to be more reliable than a removable
disk or tape drive. An optical cartridge is likely to be more reliable than a
magnetic disk or tape. A head crash in a fixed hard disk generally destroys the data, whereas the failure of a tape drive or optical disk drive often leaves the data cartridge unharmed.

- Cost : The main memory is much more expensive than disk storage. The cost per megabyte of hard disk storage is competitive with magnetic tape if only one tape is used per drive. The cheapest tape drives and the cheapest disk drives have
had about the same storage capacity over the years. Tertiary storage gives a cost savings only when the number of cartridges is considerably larger than the number of drives.