developer

Oct 14 2009   10:00AM GMT

20 gems for project managers

Posted by: Jaideep
Software Project, project manager, tester, quality control, testing, software, quality, Development, developer, coding, coder, programmer, programming, technical knowledge, Bug, bug report

1. A project manager is always right
2. Quality is seriously maintained by developers while developing software
3. A separate set of people (quality control or testers) is not required to take care of the software produced or developed
4. Testers don’t do any substantial value addition in product development
5. Testers lack business knowledge
6. Testers lack technical knowledge
7. Testers lack essential skills to test software
8. Testers don’t understand product requirements well
9. All developments and implementations are prone to extensions because of change in customer requirements or other customer constraints
10. All delays in development and implementation are due to customer
11. Testers have a very little role to play in product development
12. Testers need less than 1% of project time for testing and reporting bugs
13. Testers should be able to test the product well even if substantial knowledge related to product has not been shared with them
14. Testers are the biggest misleading agents
15. Developers and programmers are not testers and thus are not supposed to test what they develop
16. Testers are de-motivators to programmers and developers
17. Testers are project delayers
18. Customers blame development and implementation teams just to hide their own shortcomings
19. Customers don’t know to explain their processes and business rules well
20. Customers are always interested in delaying the project

Oct 9 2009   6:29AM GMT

Project Lifecycle – 2012

Posted by: Jaideep
Project Lifecycle, Software Project, project team, project phase, tester, developer, software development, software testing, implementation, software product

Phase I: There is nothing called ‘off the shelf” product. It is all ‘made-to-fit’ technique. You specify your requirements and that too at a broader level. For micro level leave a red-mark at areas that need to be looked into at the time of building of software. The more red-marks will mean less precise plan and deadlines. The sooner we are able to convert these red-marks (not clearly known ones) to the clearly defied requirements, the better plan we can submit.

Phase II: The requirements will go to a team of developers who will build the outline or prototype of what is required by the customer, will get is approved from them and then will build the business requirements in it. Once they are through with it, the product will go to phase III.

Phase III: The product is handed over to a team of testers. These testers are technically stronger than the team that built the product. So this team will take the total ownership of the product from the team responsible for phase II. This team will find out the bugs, remove the bugs, fine tune the bugs and will hand over the final product to the implementation team.

Phase IV: The implementation team will interact with phase III team for any shortfalls in the product. Any new requirements will go to phase II team. Post implementation support also will be with the same team.

Oct 5 2009   10:36AM GMT

Yu-ai = developer-tester

Posted by: Jaideep
developer, tester, Project Management, Software Project, testing, Development, programming

Yu-ai in Japanese means fraternity means people engaged in a particular occupation. It corresponds to “you and I” in English. Any software project does not shape well without the exhaustive contributions of developers and testers engaged in that project. Both communities are singular pieces of a jig-saw puzzle that becomes complete only if they are organized, arranged and sequenced in a proper manner.

Both manage CHANGE. One fulfils the requirement, another checks it and verifies it. Developer’s efforts are once synchronized with the testers efforts result in a good product.

Coalition of both - the developers and testers making a strong bond with a common motive of producing a customer focused product. Their combined efforts are meant to overcome the dissatisfaction of customer and ineffectiveness of the product. If they do not gel together, their efforts fail to address the various issues in the software that burst out at the time of product facing the customer.

The ultimate goal is to overcome differences, respect each other and provide mutual support to each other during the product development

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.

Aug 24 2009   10:00AM GMT

If SaaS is acceptable, why not give birth to QaaS?

Posted by: Jaideep
software development, testing, Development, software, tester, developer, Software developer

A software division in an IT company is considered to be a profit center whereas the Testing division is considered as cost center. A set of developers develop software, get it tested by a set of testers, sell it in the market and earn profits. The credits and benefits on success of the software never come near to testers.

Let us look at a model where testing is offered as a service that costs. Developers claim their software to be ‘fit’ for market after they develop it and do some testing at their end. If testers now test the software and find out meaningful bugs that could have created a ‘sorry’ situation at customer end, then for each of this ‘meaningful’ bug, some amount should be debited from development division’s earnings statement and should get credited to testing division’s earning statement. And the real cost of product is development cost + bug finding cost + bug fixing cost

Aug 17 2009   1:00PM GMT

Dear software developer – what is your mileage?

Posted by: Jaideep
developer, software development, documentation, planning, software requirement, software testing

I have two sets of developers. Both bunches contain quite considerable number of developers. Let us call it first set of developers and second set of developers. Both sets have their own unique way of functioning and performing.

First set of developers work randomly with no documentation, no fixed plan in place. The requirements come invariably from different directions and as soon as a new requirement comes, the developer changes the priority of his tasks based on the influence of the requirement generator. In this manner after sometime the developer loses his track of what elements he has addressed or fixed and which are pending as there is no systematic way of recording requirements and their completion track.

Second set of developers works absolutely in different manner. They record all the requirements in one place, prioritize them, maintain software version control, mark each requirement as completed only after their satisfaction and testing and reassess their requirements at each day end. This way they never lose control and are absolutely clear on what is balance and estimated time required.

Surprisingly first set of developers spend more time at work place but product less result as compared to second set of developers.

Let us compare this with two similar cars with their fuel tank full. First car is driven randomly on road for whole day without any specific purpose and exhausts its fuel at the end of the day. Second car driver is sensible in planning his route before starting his journey, reaching back early in the evening, finishing more tasks with still some considerable fuel left in his tank.

Jul 20 2009   10:00AM GMT

Responsibility of a tester - a different perspective

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

Why hit the people? Hit the process if there is a failure in a software project

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.

Jun 10 2009   10:00AM GMT

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

Posted by: Jaideep
Project Management, Software Project, change management, project organization, developer, project sponsor, project director, project manager, key user, implementer, technical lead, business requirement study, business analyst, business analysis, requirement analysis, requirement gathering, implementation phase, project phase

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.

Mar 16 2009   11:07AM GMT

A wonderful powerhouse gifted to a project manager – his Team

Posted by: Jaideep
project manager, project team project leader, module leader, functional consultant, technical consultant, Database architectures, Project Management, system designer, developer, programmer, tester, team performance

All project managers depend on their teams working on the project and in turn the persons who form the team. Teams could comprise of project leader, module leaders, functional consultants, technical consultants, database architecture, system designers, developers, programmers, testers etc. To keep working towards excellence a project manager has to focus continuously on people management, grooming of teams and team members.

If project manager’s has this as one of the top priority in his list then his performance, the results related to his project, and his team’s momentum are always improving. The top management and the project manager have to clearly understand that what it makes to run a company and project successfully is not anything else but the people constituting various teams.