January, 2009

TDD requires an extra punch of coding

TDD is test driven development in which the developers coding efforts become manifold. It is not only the development coding that developer has to write. Along with the requirements coding, the developer has to write code for the testing of each of the logic he has built in the product. It is more or less a unit testing where each small unit is tested individually by the developer as soon as he completes writing the code for it. All this is not easy to perform. It requires a different mindset to perform TDD. The developer has to be in a different frame of mind to accept first the extra work required from him. There is no extra technical skill set required in the developer, it is the mental preparedness that matters more. They have to overcome the resistance from within to do some extra efforts in coding. Although this could be a little painful but only in the beginning, afterwards, when the results start speaking loudly in lieu of the extra efforts done, it gives a different level of satisfaction to the developers.

The extra effort done by the developer in return saves a lot of time that is required for testing later since in TDD, the bugs reduce tremendously in such a manner that once matured, the later stage testing can be totally avoided.

TDD can be compared to Japanese companies environment as on-line QC in sub-assembly production instead of having QC of the product in the finished stage.

Developer and tester have to dance arm in arm on the dance floor

Sync is very important between a developer and a tester. The confidence and ease of the both has to complement each other and ultimately create a bug-free product. The prime goal is same for the whole organization – to deliver the customer what he is expecting – a totally bug free product. Both have to perform well in their respective areas to achieve the common goal.

Small breaks in-between can do wonders during the high work loads. An open platform where each member from development and testing share their current tasks with the status will cover two areas – update each one about others, and keep them synchronized.

Sometimes it is good to be a little casual and the tester can go straight to the developer with a problem and get it resolved even without waiting for a formal meeting for the purpose.

If developer = developer + tester then tester = 0

On the lighter side the equation goes like this:
Let us assume that the developer is developing in such a manner that there is no bug in the software, that means developer is actually developer and tester both.
The equation would look like: developer = developer + tester.
Which can be written as developer – developer = tester
Hence tester = 0.
__________________________________________________________________________________
But the serious aspect is that this is a purely hypothetical state. Tester’s existence evolved only because developer was working only as a developer with less quality embedded in the software. That is why tester has to evaluate the developed product on all quality fronts.

Is testing merely a Bug filtering process?

In an organization engaged in software development, usually each software goes through testing process by a separate set of team in the organization know as Testers meant exclusively for the purpose of testing. It matters most what this process is being thought as by the development team, project leads and the management (and also the customer). Testers are taken for granted as Bug Filters and testing as bug filtering process. If that is so, the management is at mistake, more so, if testers or QC department also thinks the same. This sort of culture is good for testing purposes, but is not so for the purpose of improvisation in the development process. Testers are safe as they are able to dig out a good amount of bugs every time. Bug removal time is substantial. Even the targets of product hand over to customer are met.

Isn’t the testing team’s result decrease every time even after increased efforts! That means the development team in maturing with each round of testing and development. This can happen only in case testing is not merely thought as the bug filtering process.

Bugs are invincible, developers have to be convincible

Bugs are often invincible during development, especially in large projects when multiple sub-teams of developers are working on development of different sub-modules of the project. The software developed (or during development) will always appear innocent and bug-free to the team of developers. It is the tester’s tough task to puncture the software and find out the hidden bugs. If bugs during testing phase are not found completely, it may lead to disastrous consequences, depending on the severity of unfound bugs. That is why, for developers and testers it is very important to understand the complete flow, sequence, modules, sub-modules, functional sequence to build accurately by developers and verification by testers.

Testers have to exercise the testing process and they have to ensure that they are following the right process to identify as many bugs as possible.

Understand customer requirements and make your customer understand

You not only have to understand the customer but sometimes you have to make customer understand what exactly he requires to enhance his business. Many a times, a customer is not able to chalk out clearly what business requirements he wants to get embedded in the software. He is not clear about what exactly he should get embedded in the software to get the optimum out of the software and business mix. He might be having a broad idea about what he wants to see as a final product, but may not be able to define what the core components of this product are. Customer would say the team to study their business as they are doing it, without getting involved in it. This could be serious and the seriousness if not understood rightly in time (emphasize on ‘understood’, rightly’ and ‘in time’), would lead to disastrous results.

Customer is not for experimentation. Clear and crisp ‘Requirement freezing’ is the right start. Customer may be required to be educated on what business, requirements and rules can be built in the software. A simulations or scenario generation is important to make customer understand how the software will work once completed. Customer needs to understand very clearly at the initial phases - What ease or comfort will the software bring out to business processes by giving out certain set of business results. Customer has to understand very clearly the other part of the story too. The software definitely will require certain extra skill sets, enhancements, or extra efforts once it is completed and implemented at customer site.

Digging the 10 precious ‘Experience’ Treasures

Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management

Top 5 Quality killers in a software product

In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.

4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.

3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.

2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.

1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.

Top 10 reasons to prove software development is an easiest job

Software development is the easiest task and requires no development or quality standards, provided you are ready to manufacture software which:
- Is full of bugs
- Has no buyer
- Is never ready to launch
- Has success-failure ratio as 0:100
- Is ready for unlimited budget inflow
- Is only for the purpose of keeping teams busy

Top 10 reasons to prove that software development is the easiest task on this earth provided you are ready to follow the guidelines mentioned as below:
10. Develop the software with no requirements in mind
9. Follow no standards
8. Keep the customer away during development and testing
7. Don’t select a good team of developers and testers
6. No follow meetings
5. Keep your developers on their toes. Let them not stick to their work. Keep giving them new work in between, or moving them from one sub-module to another before they completion
4. Involve testing team only in the end that too with too little time in hand
3. Keep top management happy by reporting to them about the happy state of development
2. Don’t divide the work proportionately among developers. Let them chose what they want to do
1. No owners of the product

Reference Model in Software Development – a boon for Project Manager

A reference model is a non-arbitrary model of software that is to be referred to when a new software requirement comes from a customer. The reference model will suit and fit most of the requirements given by the customer. The model is the most ideal scenario befitting the technical and functional requirements. Although the new architecture built may not (and will never) match point to point with the reference model but still it has to be as near to it as possible. Infact the reference model has to be capable to address all technical issues that may arise during the software development. During the development if a new problem is encountered, it becomes the part of reference model too. For development also the different components of the repository of the reference model are picked and absorbed wherever found suitable. So the various components are picked and fixed as it is in the software or are reworked with minor changes keeping requirements in mind.

This process not only shortens the development timeframe but also brings in more accuracy and stability in the product. It also helps the project manager to present the near to exact time and cost estimations. The reference model acts as a block of utilities or functions meant for the software being built. The best suitable blocks are selected and placed as it is. The most suitable blocks are selected and placed with a little modification. This increases the reusability as well. Reference model works as an outline sketch of the new product being developed.