Oct 19 2009 10:00AM GMT
Posted by: Jaideep
code,
coding,
programmer,
programming,
tester,
testing,
Project,
Project Management,
Software Project,
Bug,
bug report
You have a programmer who is writing codes for years that comes to you for testing. The programmer might be coding for a number of projects simultaneously or sequentially. Similar would be the case with you. You would be testing a number of projects simultaneously or one after the other. By now your subconscious mind knows the pattern of bug writing while coding by each of the programmer. But since these patterns are not recorded or analyzed you can not predict the probable number of bugs in the next set of a code from a programmer.
You can do that with the help of your bug reports so far you have submitted back to the programmer or development team. Just pull out your last ten bugs reports produced from the code written by the same programmer. Check for a specific number of lines of code how many bugs were found. Based on this one report’s bugs were from how many lines of code. Do the same exercise for all other reports. Take an average for all ten reports.
Based on the number of lines of code, this way you can easily predict the number of bugs that will be there in the fresh set of code submitted by the programmer for testing.
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
Oct 9 2009 6:29AM GMT
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
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 23 2009 10:00AM GMT
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
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
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 3 2009 10:00AM GMT
Posted by: Jaideep
pareto principle,
software testing,
software,
time management,
task management,
life management,
quality,
QC,
QA,
quality control,
programmer,
tester,
developer bug,
business application,
Software application
Pareto Principle or Pareto Rule is quite fascinating in managing personal and professional life, time management, task management, self motivation etc. Crux is if you focus few vital issues in life you manage major part of your life better. The same applies in profession, organization, department function, and activity too. Only thing is it is to be applied objectively, and smartly.
Let us see how it can work in terms of software testing and quality control:
80% of software quality is maintained by 20% of programmers
80% of bugs in an application are written by 20% of developers
80% of bugs are fixed in 20% of time
20% of a business application accounts for 80% of bugs
Aug 24 2009 10:00AM GMT
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
