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.
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 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 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 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 17 2009 1:00PM GMT
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.
Aug 10 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
software testing,
quality control,
QA,
QC,
functionality,
new feature,
Application development,
quality,
application quality,
functional testing
There is no end to an application. It always asks for a new feature, alter in functionality, addition/ change of business rule etc. With any change in the existing application running in a live environment, the change needs to be tested for all aspects of quality before putting it live. The question comes what should be the scope of testing in this case. Should tester test only for the change part or the complete application?
A change in application small or big is always going to mark an impact on the whole application. Even if not on the whole application, to some extent at various places in the application. Sometimes it could be beyond the knowledge of developer.
Therefore, in my opinion, it is wise to test to whole application even if it going to take more time and efforts to minimize the risk of impact of ‘change’ in the application.
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.
Aug 5 2009 10:00AM GMT
Posted by: Jaideep
UAT,
user acceptance test,
testing lifecycle,
software testing,
product testing,
software product,
software development,
customer specification,
interfacing,
functional testing,
functional requirement,
functional specification,
business rule,
business process,
integration test,
software build,
validation testing,
defect fixing,
bug fixing,
software defect,
software bug,
appearance testing
UAT or user acceptance testing comes as the last exercise in software testing lifecycle. It is probably the first phase or beginning of customer preparing to takeover the charge of the product. Actually this is a sort of test drive by a perspective buyer who has studied well about a car, has made up his mind to buy it but wants to satisfy himself by actually sitting in the car and driving it. Even if you have made up your mind to buy a particular model and after sitting in the car or after having the test drive, something does not suit you, the decision can take 180 degrees turn.
The same usually does not happen in UAT because the unlike car the software has been built as per customer specifications. UAT usually includes interfacing (if any), look and feel, ease of usage, functional requirements, integration test etc.
Like a car test drive, here also use runs the complete software to assess if the software is meeting their requirements completely or not. It is the last place where the user gets to determine whether or not the software meets his or her requirements. But one thing is very clear – whatever defects occur during UAT, their fixing cost goes manifold as compared to the same defects occurring during the initial building of software.
Main difference between the earlier testing done at development place by testers is that here the business process and validations built in the software will be checked by a business process owner with real data.
Probably in this busy world, if the end user, by any chance is available during the development and testing phase to do appearance, functional, process and validations testing, it would save a big amount of time and money.
