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 22 2009 10:00AM GMT
Posted by: Jaideep
tester,
testing,
quality,
software,
QC
A love for music - if you can move to music, you can dance: Same applies to testing also. If you have love for testing, and you can move to its music, you can be a good tester.
A sense of rhythm: If you understand the product well and move along well, in a right rhythm, you win the game.
Willingness to give it a go: A true willingness is a must for a tester to be successful.
A bit of natural ability doesn’t go astray: Don’t forget that anybody can not be a good tester. There is a natural ability that gives you an extra edge than others to be a good tester. Only you need is to catch this ability in you and keep polishing it.
Work hard enough: Hours of hard work and dedication is a must to be a good tester.
Jul 20 2009 10:00AM GMT
Posted by: Jaideep
tester,
Development,
Software Project,
software product,
Project Management,
customer requirement,
test case,
testing report,
test report,
bugs report,
quality control,
QC,
quality,
product quality,
software quality,
developer,
development team,
code writing,
coding
The responsibility of a tester is to ensure the peace of mind of the end users who are going to use the software product. Another target should be to safeguard customer’s investment in the product. In order to discharge this responsibility, the tester should focus all his skills on understanding customer requirements and measures to map it with product built by writing appropriately comprehensive test cases, performing test and preparing a detailed self-explanatory test report. Complex business requirements will require extraordinary level of understanding. Keep in mind the budget and time constraint for performing testing without compromising with the coverage or quality.
The overall impact of testing should be clearly visible on the product built. The bugs reported should bring a sense of belonging with the developers and customer users. Clarity of bugs in testing report should not only help developer to fix defects properly but guide him not to repeat the same type of issues in future releases. This may happen slowly but gradually should help in increasing developer’s performance and quality of code writing. After all the development team should start taking testers as their best friends and well wishers instead of someone who is trying to find out the weakness in code writing.
Jul 17 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
Project Management,
people management,
HR,
QA,
QC,
Q-tag,
developer,
quality,
quality control,
quality culture,
quality building,
product,
stakeholder,
business analyst,
project manager,
project team,
development team,
testing team,
implementation team,
product build
People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.
Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:
Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.
Jul 15 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Q-tag,
quality control,
Software Project,
Project Management,
stakeholder,
project methodology,
project management framework,
project implementation,
software build,
software implementation,
product approval,
Quality-tag,
project team,
development team,
implementation team,
testing team,
team,
QC,
QA,
business analyst,
re-testing,
testing,
Bug,
bugs report,
test report
In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.
If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.
Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?
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 10 2009 10:00AM GMT
Posted by: Jaideep
change management,
Project Management,
project timelines,
Software Project,
software build,
test phase,
testing,
software,
customer requirement,
business requirement,
product delay,
product launch,
project phase,
development phase,
software development,
software testing
In my June 15 2009 post – “Do’s (+) and Don’ts (X) in Project Management” http://itknowledgeexchange.techtarget.co…), I got a query and am posting it here as it is - As mentioned by you in one of your post “Single constant in business is Change”. But often software vendors are too bound by the requirement documents that they fail to gauge the change in the underlying business need that they are trying to cater to. I understand that there are time and cost considerations, but many a times the attitude is not conducive. Could you throw some light on this in your writings…?
First of all let us be clear – we can not just record requirements and seal it. And then stay isolated from customer in building the software. One fine morning communicate to the customer that the product is ready and you are reaching customer site for product launch. If you feel that during the conceptualization, build and test phase customer has no role to play – you are wrong. If the customer thinks just by giving the requirements they will get a good product meeting all their expectations – customer is wrong. Both have to be in tune during the product development. If vendor fails to gauge the change in underlying business need that they are trying to cater to and think if they do so, it will increase their cost and time – again the vendor is wrong. By not doing so – they call for more time and cost. By not doing so – they surely call for more discrepancies, ambiguities, delays and failures. A small investment of time and cost during the build phase to involve customer and take his consent at every step will definitely lead to later on investments, time delays etc.
If attitude is not conducive, it has to be. Customer has to realize that. And customer has to realize the importance of getting involved in each phase of the project rather than assuming that it is vendor’s call and everything will go fine.
The requirements keep changing, as the business. Only thing that varies is the pace of change in requirements. Overlooking changes happening in the business process at customer end after freezing requirements will result only in undesirable product. Both customer and vendor have to understand this and keep overseeing the changes rather than overlooking.
If changes are not recorded and incorporated in time, customer is always going to blame the vendor and may be vendor gets exchanged with another vendor for the same project.
Jul 8 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
project manager,
project team,
project monitoring,
Project Plan,
Project Planning,
Project Development,
project implementation,
Software Project,
software development planning,
software product
At the birth (inception) of a new software project the project manager is puzzled and confused just trying to gather and understand customer requirements. He starts like a wanderer in the dark islands of customer for collecting various requirements and understanding their business norms. The moment he is able to collect this information, he aggregates to get the stock of ‘total requirements’. Understanding this makes him getting into ‘catching the rhythm’. Now comes his planning phase where he has large ‘in depth’ discussion with his development teams. By identifying different milestones for various project stages, he prepares a project plan. At this stage he is supposed to discuss this plan with customer and get ‘in sync’ with him. Once approved from customer, he breaks this plan into different stages plans to hand over respective plans to their ‘stage owners’. Development plan goes to development manager. Quality plan goes to QC head. Implementation plan goes to implementation head (himself mostly). Accordingly each stage milestones are identified which might be more than overall project milestones shared with the customer.
Then starts the actual war phase – the development phase. Meetings, discussions, brainstorming, logs, monitoring are all the weapons of this war phase. A product gets birth during this phase which gets vetted by quality control team. Documentations are also integral part of this phase.
Various test phases occur during and post development or build phase. Smoke testing, Unit testing, module testing, performance testing, security testing, load testing, functional testing… to name a few.
Now the baby has started walking. So baby is dressed well to take it to the grand function taking place at customer site. The function is ‘Implementation’. This is a long function, comprising of baby show, meetings, discussions, demonstrations, recordings, UAT, training etc. Once the baby is able to walk neatly in front of all the guests at the function, all praises fall on baby. The ceremony closing takes place. Project manager adds one more bullet of ‘confidence’ in his gun.
And starts over again for a new project.
