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 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 29 2009 11:00AM GMT
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
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.
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
Aug 21 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
software testing,
testing,
software project management,
outsourcing,
Project Development
On LinkedIn an IT projects guy posted a question about plus and minus of outsourcing software testing for his software project. After getting 12 replies from various experts he posted his intention behind this question. The intention was to outsource development and testing to two different vendors (‘slicing’ in his terms) so that they maintain a self-check on their performance and resultant.
My next post immediately after his last post regarding his intention was that if he had clarified this right in the beginning at the time of posting his question, he would have got better replies rather than experts posting their views on pros and cons on outsourcing ‘testing’ or not.
Well my last post said there the same. And I added – “if you are slicing – then make 10, 20 or more slices and distribute it among all your vendors. This will also call for more self-checks”
What is your take on this?
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.
Jul 30 2009 10:00AM GMT
Posted by: Jaideep
load testing,
Software application,
test goals,
testing
1. Purpose: The main purpose of the application for which it is built need to be defined.
2. Load Test goals: Identify what you want to achieve by load testing, what are your primary goals to go for load testing. Define all your goals. One example could be – login time for 100 concurrent users should be less than 2 seconds.
3. Architecture: The major concerns in the overall architecture about achieving these goals
4. Simulations: Think of all possible scenarios in which the end user will be working when application is put live. This could include some batch processing, some different client types etc.
5. Past experience: don’t forget your past experience with load testing solutions. The results, the shortcomings, bottlenecks – all could lead to a new learning.
6. Topology: Define all infrastructure components and the network which links them.
