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 3 2009 10:00AM GMT
Posted by: Jaideep
pareto principle,
software testing,
software,
time management,
task management,
life management,
quality,
QC,
QA,
quality control,
programmer,
tester,
developer bug,
business application,
Software application
Pareto Principle or Pareto Rule is quite fascinating in managing personal and professional life, time management, task management, self motivation etc. Crux is if you focus few vital issues in life you manage major part of your life better. The same applies in profession, organization, department function, and activity too. Only thing is it is to be applied objectively, and smartly.
Let us see how it can work in terms of software testing and quality control:
80% of software quality is maintained by 20% of programmers
80% of bugs in an application are written by 20% of developers
80% of bugs are fixed in 20% of time
20% of a business application accounts for 80% of bugs
Sep 1 2009 10:00AM GMT
Posted by: Jaideep
80/20 rule,
Software Project,
Project Management,
software coding,
Software application,
Software developer,
Bug,
bug-free,
software
The 80-20 Rule or most commonly known as “Pareto Principle” was first formulated by the famous Italian economist Vilfredo Pareto in 1895. The principle was named after him and still holds good almost in all the aspects of life. Vilfredo Pareto found that 80% of Italy’s wealth was with 20% of people. The crux of the principle is that most things in life are not distributed evenly. That may imply that in an organization 80% of decisions are taken by 20% of people. In a manufacturing unit 80% of production is done by 20% of workers. In an class of 100 students 80% of intellect lies with 20% of students. And so on…
In a software project management, based on 80/20 rule, it may be concluded that:
20% of code manages 80% of business in a business application
80% of developers write 20% of code in a team of developers responsible for writing a business application
20% of total productivity of a software developer produces 80% of results
20% of core business requirements, if focused and built well in an application, account for 80% of customer satisfaction
20% of bugs fixed make 80% of software bug-free
And so on…
Aug 7 2009 10:00AM GMT
Posted by: Jaideep
Software developer,
software development,
Application development,
Software application,
software testing,
bug-free,
Bug,
software,
application,
bug identification,
application building,
code writing,
application performance,
business requirements,
Business Rules,
code validation,
business process,
process owner,
end user,
collaboration,
tester,
application functionality,
software functionality,
software performance,
quality,
customer experience,
software build,
bug fixing
Lot of efforts can be saved in terms of time and money if we reach to a stage of ‘first time right’ in application development. It has been proven largely that no good application can be built and released without extensive testing. Testing is not developers’ ball game – this is also a well proven fact. Reasons are many as far as it is concerned that why developers can’t build a bug-free application, or why can’t they test on their own. We are not going to discuss those reasons here. Focus here would be on what developers should keep in mind while building an application that it requires minimum efforts and time in all testing stages. As we all know the cost of bug fixing goes manifold, depending on how much distance (in terms of time and project stages) it has covered after development for bug identification. The bugs identified at a later stage, say during UAT cost more significantly as compared to the bug identified by the developer himself immediately after writing a code. Few qualities if a developer acquires and keeps in his mind while writing codes would not only benefit him but the organization he is working for and their customer also for whom the product is being built.
1. Commitment to application performance should be kept in mind while writing a code.
2. Clarity of business requirements and rules/ validations that are being translated into the application with real aptitude of business and not a developer. Don’t imagine and build. If there is some lack in clarity – discuss, record and build.
3. Treat yourself as the business process owner and end user – and build the application accordingly as if you have to use it. Don’t think yourself as a bartender, think as if you are preparing the drink for yourself.
4. Collaborate and build – rather than building in isolation- collaborate with other developers working on the application, the end user, and the testers.
5. Optimize your code – don’t just write it. There are n numbers of optimizers almost in all technologies. Use them and build a strong application in terms of functionality and performance. Be quality focused. Don’t do efforts that call for more efforts later.
6. Be focused. Don’t work on various applications development at the same time unless it is too mission critical.
7. Gain customer experience after launch of your application. It will certainly help you in your future builds. Build a customer satisfaction metrics.
8. Don’t take short cuts in fixing bugs – whatever stage they are identified. That way you will build more bugs while fixing identified bugs.
9. Work like a champion. There is a difference between playing a shot and playing an accurate shot.
10. Be loyal to yourself, your organization and your work.
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.
Apr 8 2009 10:18AM GMT
Posted by: Jaideep
Software application,
software development,
software testing,
application testing,
risk,
risk perception,
risk identification,
risk assessment,
Risk analysis,
impact analysis,
risk classification,
Risk Plan,
risk plan analysis,
risk plan execution,
risk closure
A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.
Let us understand the different stages of risk in software application development and testing phase:
1. Risk perception
2. Risk identification
3. Risk Assessment
4. Risk Analysis
5. Impact Analysis
6. Risk Classification
7. Risk Plan
8. Risk Plan Analysis
9. Risk Plan Execution
10. Risk Closure
Apr 6 2009 10:29AM GMT
Posted by: Jaideep
SDLC,
software project management,
Risk lifecycle,
Risk Management,
risk identification,
risk assessment,
risk impact,
impact analysis,
countermeasure,
fool-proofing,
risk severity,
Project Lifecycle,
Software application
Similar to SDLC (software development lifecycle management), there is RLC or Risk lifecycle management in a software application in which there are different stages involved. The different stages could be risk identification, risk assessment, impact analysis, countermeasure identification, countermeasure assessment, risk plan etc. There are certain facts about Risk:
1. All Risks identified or perceived in a software application do not necessarily happen in real application usage scenario: This is a proven fact that all risks identified or perceived from an application during its pre-launch stage do not happen during post launch real-life usage stage. Some risks perceived may not happen ever. And some unidentified risks may appear later. Whatever is the case, it is always good to identify the risks that may occur during its usage, the more realistic the better. It is not important that they happen in real scenario, more important is to plan how to cope up if at all they happen.
2. All risks have an impact: All risks have an impact – large, medium or small, but they have. It is the impact that makes its severity high, medium or low and accordingly a plan is prepared to handle the risk, when it happens.
3. Same risk in different circumstances will have different impact: The same risk will vary in terms of its severity under different circumstances of usage, user base, geographic location, type of application etc.
4. No application is 100% risk free, whatsoever countermeasures are taken for it, and only thing that gets done with the countermeasures is lowering of risk: A risk plan to countermeasure a risk never fool-proofs a risk’s impact, only it helps in lowering its impact to a certain level.
5. Risk Impact Cost vs. Countermeasure cost: It is very important to have an analysis of both before deciding on the plan. Some risk may be very severe but its countermeasure cost could be unaffordable.
6. The biggest risk in any application is identification of wrong risks, impact, and plan: Identification of wrong risk with right estimation of impact and countermeasure is useless. Equally useless is identification of right risk with wrong impact analysis (thereby underestimating or overestimating the impact) and arriving at a wrong countermeasure. Right risk identification with right impact analysis but with wrong countermeasure also is a waste of efforts.
