Sep 29 2009 11:00AM GMT
Posted by: Jaideep
Progressive approach,
incremental approach,
performance testing,
testing,
quality control,
Software application,
bottleneck,
bottleneck identification,
application server,
multiple sessions,
multiple users,
multiple logins,
application workflow,
application module,
report,
batch processing,
processing,
load testing,
load test,
performance test
No. I don’t think so. If you have to identify the bottlenecks in your newly built software application, you are bound to adhere to this approach. Use a progressive bottleneck identification approach for performance testing of the application. The testing approach should be to apply holistic load on the application server. There could be multiple aspects for users working simultaneously on the application in real scenario:
Multiple users would be accessing different workflows of modules of the application.
Multiple users would be accessing the same module of the application
Multiple users running different reports
Multiple users running same report
Multiple users running different batch processing
Multiple users running same batch processing
Multiple users logging in
Multiple users running multiple sessions
Etc.
Now to find out the peak performance point of the application beyond which the application does not behave normal, an incremental or progressive load approach need to be applied while performance testing. Testing would be carried out to identify the impact of various performance parameters on the application. Application would be tested under a concurrent user load and the transactions response time for critical transactions is reported back with their response time. As the load of users, or sessions is increased on the application, the behavior of the response time is studied to ascertain the optimum users or sessions permissible in the application under a pre-defined set of hardware environment.
Sep 16 2009 12:00PM GMT
Posted by: Jaideep
Software Project,
software product,
software development,
QC,
quality control,
QC head,
customer requirement,
testing effort,
testing effort estimation,
customer specification,
development plan,
testing plan,
business rule,
business specification,
test case,
performance testing,
load testing,
functional testing,
test effort,
team size,
Test Plan,
development phase,
testing phase,
tester
A new project, a new product development – as a QC head how do you estimate your testing effort?
Well, some quick steps for this:
1. Customer requirements: Customer specifications or requirements captured at the time of initial study period would be a quick reference guide for estimating testing effort. One word of caution is that incomplete or non-documented requirements may lead to wrong estimations for both – development and testing.
2. Business Specifications: Like customer requirements, there are some business rules and specifications that are well defined by the customer representatives that need to be built in the software. Building test cases and performing tests will depend on such requirements and hence the estimation.
3. Testing Scope: What is the overall scope of testing? Performance, Load, Functional, or all will help you in estimating your testing effort, team size, and test plan
4. Development Plan: Development will definitely go in phases. Plan testing accordingly and estimate testing effort in that manner to accommodate parallel or phased testing so that all load of testing does not fall at the end of development phase.
5. Test team size: Testers availability will be major criteria in estimating your test effort.
Jul 30 2009 10:00AM GMT
Posted by: Jaideep
load testing,
Software application,
test goals,
testing
1. Purpose: The main purpose of the application for which it is built need to be defined.
2. Load Test goals: Identify what you want to achieve by load testing, what are your primary goals to go for load testing. Define all your goals. One example could be – login time for 100 concurrent users should be less than 2 seconds.
3. Architecture: The major concerns in the overall architecture about achieving these goals
4. Simulations: Think of all possible scenarios in which the end user will be working when application is put live. This could include some batch processing, some different client types etc.
5. Past experience: don’t forget your past experience with load testing solutions. The results, the shortcomings, bottlenecks – all could lead to a new learning.
6. Topology: Define all infrastructure components and the network which links them.
Jul 28 2009 10:00AM GMT
Posted by: Jaideep
technical,
load testing,
testing,
software product,
framework,
Software application,
.Net,
J2EE,
server,
server application,
presentation server,
application server,
database server,
MS SQL Server,
Oracle,
Apache,
Websphere,
IIS,
OS,
operating system,
hardware configuration,
RAM,
processor,
harddisk,
LAN,
dial-up
1. Framework: What is the framework being used in the application? For example it may be .Net or J2EE or any other.
2. Servers: What all server services you are using to run/ use this application? What standard server applications are used for Presentation, Application and Database level? Some examples could be MS SQL Server, Oracle, Apache, Websphere, IIS etc.
3. Number of machines: Are these servers running on same machine or different machines. If different machines how many machines and what servers specfically on which machine.
4. Details of these machines: The details of the machines running all these server applications or server services. Details would include Operating System, Hardware configuation – like Hard disks, RAM, processors etc.
5. Access details: Last but not the least important point is how the users will be accessing the application – via LAN, through dial-up, through internet, through some specific port and third party tool etc.
Jul 24 2009 10:00AM GMT
Posted by: Jaideep
load testing,
testing,
quality,
software product,
server,
Test Server,
production server,
Staging Server,
server configuration,
n-tier,
2-tier,
3-tier,
Software application,
n-tier application,
application,
browser,
browser version,
architecture,
performance,
protocol
Which Server: Where is the load testing intended to be performed? Is it the test server, production server or staging server where load testing is to be performed? If it is being performed on Production Server, it is ok. Otherwise if it is to be performed on test or staging server, be careful that it is as near to production server in terms of configuration and setup as possible. It may give wrong projections if there is a wide gap in environment which is to be used in real versus the environment on which the test is performed.
How many Tiers: It is very important to understand how many tier application is, on which the load testing is to be performed. The n-tier count should include the client also.
What Browsers: Be very clear and specific on defining what all browsers are meant to be used for running this application (if this is a web application). The browser and its version is very important to conduct the load testing as each browser behavior, architecture and performance varies. Even between the different versions of the same browser.
What Protocols: Whether this is a client server application, web based application or n-tier application – identifying what protocols you are using to run the application is very important.
Jul 13 2009 10:00AM GMT
Posted by: Jaideep
performance testing,
software testing,
testing,
quality control,
bottleneck,
execution,
Project Lifecycle,
Software Project,
testing lifecycle,
testing phase,
testing tool,
testing parameter,
testing component,
load testing,
volume testing,
stress testing,
Test Plan,
test strategy,
load modeling,
scripting,
test script,
testing script,
benchmarking,
test case,
test execution,
test report,
testing report
As in a software project, the complete project lifecycle comprises of different phases. Similarly the performance testing lifecycle also comprises of various phases. Performance testing is usually, as the name suggests, is done to evaluate or examine the performance of the software product with the help of some tools and certain parameters. The performance testing may include components based on the requirements that include – load, volume, stress etc.
Five prominent phases of performance testing can be:
Phase 1:
a) Test Plan
b) Test strategy
Phase 2:
a) Load Modeling
b) Scripting
c) Benchmarking criteria
Phase 3:
a) Benchmark execution
b) Other executions
c) Reports generation
d) Reports Analysis
Phase 4:
a) Reports reconciliation
b) Reports compilation
c) Final Test Report
d) Bottlenecks identification
e) Recommendations
Phase 5:
a) Execution of recommendations
Jul 6 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software tester,
software testing,
Project Planning,
Test Plan,
test case,
product analysis,
customer requirement analysis,
product functionality,
software functionality,
software documentation,
software document,
test result,
test performance,
software performance,
testing process,
quality analyst,
QC,
QA,
quality control,
load testing,
performance testing,
functional testing,
security testing,
test coverage,
software build,
software,
analysis,
functionality
A software tester evaluates software based on certain parameters. These parameters are set as per product, customer and organization requirements. Testing could be just of functional features or include load, performance and security. For any parameters a tester has to work as quality analyst to understand requirements, features and accordingly build test cases and perform test. This is the quality control part. On quality assurance front the quality team has to build standards for requirement freezing, planning, development, implementation and post implementation phases of a project.
A software tester at various stages of a project gets on to the job of a Quality Analyst by performing following tasks:
Analysis of customer requirements: The first and foremost analysis required is that of the customer requirements to ascertain if it is complete, detailed and free from any confusions, ambiguities or equivocalness. Any flaw in requirements will certainly lead to a big disaster at a later stage. Unclear requirements are not difficult to build, but are difficult to manage. Every requirement should be in black and white. Each line should be very clearly documented such there should be nothing hidden between the lines.
Analysis of Product Functionality: Requirements documented and product built has to go hand in hand. It should not happen that requirements and product speak differently even a single line. Usually while testing functionality of a product, tester forgets to refer to requirements documented, or asks developer about the functionality. The developer will certainly explain him the functionality he has built not what exactly has been mentioned in the requirements document. If this happens, it will certainly cause a big blast at implementation or acceptance stage.
Analysis of Product related documents: There are many documents prepared during the project. Some are meant for internal use, some are prepared for customer. All these documents need to be inspected thoroughly and neatly.
Analysis of test results: Test cases are built to perform tests resulting in bugs report or test results report. A thorough scan is must to ensure complete coverage and thorough testing. The report should be detailed in all respects in terms of clarity and coverage.
Analysis of Testing Process: The testing process once establishes need to be revisited again and again to improve further at every go. Once established does not mean it is ultimate and best. Improvement has always a scope howsoever best your process or product is.
Nov 24 2008 10:14AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
SOA,
software quality,
functional testing,
Quality Assurance,
performance testing,
Software testers,
load testing,
RIA,
software qa,
AJAX,
.OST files,
Software testing methodologies,
Bug Control Management,
Open Source Testing Tools,
Traditional Testing Tools,
Web2.0,
Selenium,
HTMLUnit,
TestGen4Web,
PushToTest,
volume testing,
testingtool,
testing tools
In today’s scenario when the schedules are tight, budgets are low and different technologies being used, software developers and testers are having great challenges of building/testing/releasing bug-free software by meeting all criterions. The question arises here is – how to cover all the development/testing requirements that to in such a short span of time with high rate of accuracy in development and testing. In such a scenario, the best option would be to use Open Source Test (OST) tools. And why not, when Open Source Test (OST) tools provide most economical solution and on top of it they are more flexible as compared to labeled vendor test tools (or traditional testing tools). So many big corporate organizations these days are using Open Source Test (OST) tools such as Ford, AMD and many more.
Many of the open-source testing tools support most of the technologies being used in development these days. Be it AJAX development or rich internet application (RIA) i.e. Web 2.0 on service oriented architecture (SOA), or any other web/server based application.
Some of the Open Source Test (OST) tools are – PushToTest, HTMLUnit, TestGen4Web, Selenium etc. that take care of functional testing, performance testing, load testing and volume testing. If you see all these testing are not possible to conduct manually and using a traditional testing tool would be never be a cost effective solution.
