Oct 14 2009 10:00AM GMT
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
Sep 14 2009 1:00PM GMT
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 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 19 2009 11:00AM GMT
Posted by: Jaideep
Software developer,
software development,
unit testing,
tester,
Bug,
product testing,
software testing
If a person who develops software is software developer, why not the same person developing bugs in the software be called bugs developer. How many developers ethically perform the unit testing after completing development of a unit? It could be - None, a few of them, some of them, most of them or all of them. Some of them might be under the impression that they perform unit testing after completing a unit but the way they do it might not be really helpful in finding bugs. It might be just to satisfy them what they do and call it as unit testing.
If developers really perform unit testing, find out the bugs and fix them, in actual, then when testing is being performed by the testers why they have to perform unit testing again? Why can’t the testers skip it and save lot of money and time of the organization.
Aug 14 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
reliability,
quality,
software quality,
testing,
Bug,
project manager
If you, as a project manager, are fond of thunderstorms, volcano eruptions, etc. it is ok howsoever you drive a project. Otherwise look below at six indicators mentioned below. Even if one of the reason prevails in your project’s lifecycle, manage it, get rid of it, immediately, before a small wound becomes a big septic.
Irregular releases – when plan or commitment varies from actual delivery inconsistently. Some plans finish in time, some with small variation and some with huge variation. It means there may be a volcanic surprise.
Drop in quality or inconsistent quality of product built: Testing is happening, bugs are being reported but if the product coverage is incomplete while testing, or volume of low quality bugs reported is higher as compared to some severe bugs skipped in reporting, there is a mishap going to happen for sure.
Wrong cycle time estimations: if your estimations are going haywired, you plan milestones and achieving them itself if becomes a project, and go beyond control for achievement – there is a mess, in a big way.
Unplanned expenditure like overheads, delays: all these estimates going wrong, will call for extra time for team members and extrapolation of deadlines – a clear indication of a thunderstorm coming on the way.
Predictability: if your team members lose their commitment level, your predictability will become a big question mark for your management and for the customer.
Reliability: your team members’ reliability will invariably start decreasing the moment all this starts happening – and so will be yours.
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 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?
Jan 30 2009 10:03AM GMT
Posted by: Jaideep
• TDD,
Test Driven Development,
developer,
coding,
software,
testing,
tester,
software logic,
unit testing,
acceptance testing,
Bug
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.
Jan 28 2009 10:00AM GMT
Posted by: Jaideep
developer,
tester,
bug-free product,
Bug,
testing,
software
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.
