September, 2009

Sep 30 2009   10:00AM GMT

Load Modeling in performance testing

Posted by: Jaideep
Quality Assurance, load modeling, performance testing, top management, load testing, Project Management, Software application, application performance

Load modeling is the first phase of the performance testing in which certain specific tasks are performed such as conducting performance requirement gathering workshop: This usually is conducted with the top level management to understand their perception regarding number of users, critical scenarios (may be top 10, top 5) for the application catering to the business. Top management definitely have their own understanding on the critical areas which need more focus while load and performance testing. This might vary from the focus areas defined by the end users or project members.

A load test environment need to be prepared based on the above requirements, which include populating database for appropriate values, setting up proper monitoring instances etc.

This all has to be managed by a team comprising of performance analysts, performance engineers, business users, management representatives etc. The performance engineers are supposed to prepare scripts on application with the help of some toolset.

Sep 29 2009   11:00AM GMT

Can you do without Progressive approach in Performance Testing

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 25 2009   10:00AM GMT

What is the ‘unit to measure’ your project progress?

Posted by: Jaideep
Project Management, project progress, Software Project, project initiation, project closure, project feedback, project execution, Project Planning, project team, project milestone, project phase, Development, testing, UAT, QC, quality control, test report, sign-off, implementation, live run, project task

A project starts with initiation phase and ends up with project closure report. Then afterwards there is post project feedback (after a considerable amount of time given to the customer to get conversant with the product) and warranty support followed by support contracts over a period of time. Let us begin our story with the project initiation and proposal approval from customer. The real ball-game starts from here.

Now planning starts, teams are formed, milestones are set and teams move into execution phase.

Execution phase comprises of development, customization, configuration, testing, training, reporting, sign-offs, monitoring upto implementation, parallel run, live run etc.

And then comes the project completion phase with Project sign off.

During all the phases of project initiation, planning, execution… are the milestones broken into tasks and tasks further into sub-tasks unto the smallest measurable, achievable ‘hour’ unit. Or it is measured in days, weeks or months where it loses its continuity and rhythm. If everyday something is declared done, finished, achieved that is visible to the project team, stakeholders including customer, it carries out a satisfaction, rhythm, confidence and regular progress.

Sep 23 2009   10:00AM GMT

Quality of documents says it all about the health of the project

Posted by: Jaideep
Project Management, project manager, Software Project, business analyst, coder, programmer, tester, quality

A software project has to undergo various stages before reaching the final stage of customer sign off. At each stage of the project there are certain set of documents that are maintained by the project team for internal or external purposes.

These documents are prepared by various team members – by business analysts, by coders, by project manager, by testers and by other managers.

The Quality and maturity of documents straightaway tell about the health of the project, the team, the management, the product and the progress. It tells clearly about the intentions behind the documentation – that if it is merely a formality or it is really meant for helping the project progress.

And it is not difficult to ascertain the intentions after going through the documents maintained or being maintained during the project.

Sep 22 2009   10:00AM GMT

Why is Change opposed?

Posted by: Jaideep
change management, tester, programmer, coder, project manager, Project Management

A coder or programmer when told that he is not writing his code, by way of presenting him with a list of bugs, he is being told to CHANGE.

A tester when is told by his superior that he lacks business depth for testing the product, he is being told to CHANGE.

A project manger when told that he has to improve his way of managing a project, he is being told that the current methodology does not suffice the purpose. It requires a CHANGE.

A management when consistently fails to deliver its commitments to its employees and customers, means it needs to introspect and CHANGE.

When a person, department, team or country stops delivering, or starts giving indications of failure in one aspect of other, it asks for CHANGE.

Change is powerful.
Change is inevitable.
Change does not challenge your knowledge.
Change does not indicate that you are incapable. Rather when one is being told to change, someone has confidence in his capability to CHANGE and PERFORM better.
Change does not mean that you are wrong, it means that there is a scope of improvement.

But

Change is often opposed as a natural tendency because it is taken as an indication that you are not performing well and what you are doing is not doing well.

Sep 16 2009   12:00PM GMT

Five ways to workout ‘testing effort”

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.

Sep 14 2009   1:00PM GMT

Ten facts (or myths) about developers and testers

Posted by: Jaideep
software testing, Software tester, Bug, coding, software code, software, developer, code, customer requirement, business requirement, business needs

We all know developers and testers both have a tough job all the time. Developers have a key role in developing the software as per customer requirements embedding customer’s business needs into it. Similarly testers have to put all their efforts in ensuring that the software is matching customer specifications flawlessly and is bugs free. In a nutshell both developers and testers have a common goal of ensuring a superior product delivery at customer end. If that is so why there is a never-ending tussle between testers and developers. Why developers feel testers are unnecessarily trying to poke their nose into their affair. Why testers feel that out all the bugs found out by them, most of the bugs would have been already handled by developers if they had done their job more seriously.
All this leads to certain questions about testers and developers which they only can reply to:
1. Testers are not supreme and so are developers. If developers can build so many bugs while writing the code, testers are also bound to leave certain loopholes in their testing. This is universal and never ending story.
2. Most of the testers around the world who test software do not understand very well the purpose behind the testing. They keep oscillating between their role as policing, controlling quality and excessive reporting.
3. Both developers and testers carry a single goal of ensuring good quality of software at the end of the day but still keep blaming each other for the shortfalls.
4. If developers are kept for writing code, it is well understood that they are being paid for writing good code and not bad code. Then why bugs at all? If a developer has been hired for coding, is it wrong at organization level to expect a 100% bug free coding from developers. If they are permitted to write code with bugs, why not every other function in the organization is allowed to perform their daily tasks with errors. Can’t we have perfect coders?
5. If testers find out the bugs, instead of being thankful to them, why developers start finding out reasons of cornering them. Developers are hurt when testers find out bugs in their code, and instead of going into a thanks mode for testers they start going into another mode where they themselves start losing their respect. In turn they start finding out weaknesses in tester’s capabilities, testing criteria or bug reporting process.
6. It is a well proven fact that while fixing reported bugs developers are bound to generate new bugs. Does it not make them circling them around the same product?
7. Testers sometimes have an understanding that if they report less bugs will mean a question mark on their job, which forces them to report many a times non-quality bugs thereby increasing gap between developer and tester.
8. Developers, once they know that the product has to undergo testing, write code so foolishly that they generate lot of unexpected bugs.
9. If testers are hired for finding out bugs, is it not their lack of depth of knowledge that leads to bug explosions at the later stages? Are testers involved in coding, or business study or implementation?
10. If developer’s after reading so many books on development write codes with bugs, I don’t think a good tester criteria should be if he has read a book on testing or not.

Sep 11 2009   10:00AM GMT

10 innovative ways to become a “lousy” project manager

Posted by: Jaideep
Project Management, project manager

Project Management is not simple. It requires lot of skills (and learning and experience) to become a good project manager. A good project manager is the one who plans and executes well – all the stages of a project. Finally if project finishes in time with a SMILE ON CUSTOMER FACE, the project can be treated as successful. It is the option of a project manager to label himself as “lousy” project manager or “successful project manager” depending on how he/she manages the show throughout.

To become a “lousy” project manager, following steps can be followed which are quite simple in nature and easily adoptable. Vice versa of these steps can help you in becoming a “successful” project manager, but following that will require some smart efforts and a “fire in the belly”.

The steps are:
10. Don’t own the project: You can easily pass on the buck to anyone engaged in the project. Keep yourself focused on the minutest of the failures and find out the right guy to be blamed for it. With smart reasoning you can easily convince the management and other stakeholders about the failure, its reasons and justification for delays in the project.

9. Assure insufficient customer requirement gathering: To achieve your target, ensure that the customer requirements are not gathered in the proper fashion. Ask irrelevant questions to customer and that to the irrelevant persons for gathering customer requirements. This will surely give you a good reason to convince customer later that it is because of their fault in specifying proper requirements that the product built in not meeting their requirements and you will have another stack of ‘months’ in your kitty to linger on the project.

8. Build a thick wall: Between your management and customer, build a thick wall so that all communication never gets transparent. This will help you in moulding the things in your way as and when required. Similarly build a thick wall between various sub-teams in your project like testers and developers, developers and implementers etc.

7. Build inappropriate teams: For managing your different phases of project, inject inadequate number of persons in your various teams responsible for different phases of the project. Also ensure that that most of the team members are “dumb” enough in knowledge and smartness so that you can easily place the “failure” hat on anyone’s head at any rough moment of the project.

6. Ambiguous documentation: Ensure that the documentation is not at all crisp clear at any phase of the project. Let it be as ambiguous as possible, but in a smarter way, so that nobody is able to figure out the objectionable part.

5. Stay unfocused: Find out some other critical issues not related to project but that can easily make you reasonably justified for not able to devote proper time on the management of project.

4. No Reporting: Let each member enjoy. Make no provision of timely reporting about the progress of project.

3. Dearth of technical knowledge: Don’t develop your technical knowledge required for your project. Let your technical people befooling you in their own way. Ignorance is always bliss.

2. Be Political: Keep on taking your customer on a different track by telling them wrong stories about your management and product in process. Also keep informing your management about customer’s lack of knowledge, involvement, providing of sufficient key users etc. that will become your strong ammunition for shielding you.

1. Repeat everyday: All points above have to be read repeatedly everyday so that you end in becoming a “perfect loser” at the end of the day.

Sep 9 2009   10:00AM GMT

How do you do your project sizing?

Posted by: Jaideep
business application, Software Project, UAT, software product, Project Management

Next month is a marriage in your close relation. You plan to buy an expensive suit length and get it stitched by the best tailor in the city. You buy the best cloth, go to the best tailor, he takes your measurement and gives you a trial date suitable to you. You go on that date, find minor or no change in the stitched suit, tell him the alterations required and get your fully perfect suit after 2 days, a week before the function date.

Your customer decides to go for a business application, decides on you to build it and implement it, gives you an order, you take the measurement (understand business rules and customer requirements), you give them the tentative date for trial (UAT)… but UAT goes down flip flop. You are not able to deliver the product on promised date.

Your tailor delivered the suit, with your complete satisfaction, on the promised date.

Where is the difference? Something went perfectly between measurement and trial date for your suit that your tailor had to deliver to you but not for your product that you had to deliver to your customer.

This is called product sizing and team sizing i.e. project sizing.

Sep 7 2009   11:00AM GMT

Top 5 reasons of Project Manager getting fired

Posted by: Jaideep
Software Project, project manager, Project Management, business knowledge, project team, team member, software product, product meeting, project meeting, customer meeting, technical depth, technical knowledge, project feedback, team feedback, customer feedback, project failure

Project Failure: First failure will downgrade the level of next project to be given to the project manager. Not only this, but it will also trigger hidden cameras in the organization that start monitoring each and every step of project manager. These hidden cameras could be top management or some selected down the line people working with project manager.
Customer Feedback: Organizations are taking customer feedback very seriously. A remark by a customer regarding a project manager – “I want this project manager to manager all my future projects ordered to you. Infact if you don’t depute this person as project manager, you don’t accept our orders” triggered such a magic that it immediately presented the project manager with an out-of-turn hefty increment. On the other hand a customer CEO sent a confidential email message to the CEO of projects organization stating – “We don’t want the current project manager to be seen in out campus with immediate effect” put a very big question mark on project manager’s capabilities.
Project Team Feedback: Sometimes even if Project fails project manager is able to survive if project team and customer give a positive feedback. Then the reasons are different which are beyond the control of project manager. But if project fails and feedback is also not very positive, all axes will fall on project manager’s neck.
Lack of Technical Depth: A shallow or artificial demonstration of technical depth will not help for long. Although project manager has not to do technical activities on his own but his depth of knowledge will definitely help in driving the project in right direction and meeting targets.
Lack of business knowledge: Sometimes smart team members manage many a weaknesses of their project manager if he has demonstrated his strength in certain areas. But the lack of business knowledge is something that will certainly affect the product built, customer confidence in product and project manager’s knowledge. And if project manager is not clear about the business concepts of the customer, his presence in project, product and customer meetings will not be as effective as it is supposed to be.