Oct 12 2009 10:00AM GMT
Posted by: Jaideep
software product,
Software Project,
customer requirement,
business requirement,
code,
software,
change management,
software implementation
One customer type focuses on current requirement, rightly built, with more flexibility towards the business requirements built-in in the database rather than in the code. They believe that if the software meets their current requirements well, the future requirements will be built in at the need of the hour. The reason for this is that nobody at the moment is sure about the future requirements and when the change will be required. The change could be required one day after the current implementation or after five years. The changes required could be insignificant, small or not so much effort consuming.
Another type of customer is who is more worried about tomorrow without focusing more on the current built. The future requirements which are not too clear at the moment, are guessed by the customer and forced to be built in the product without really understanding if these requirements will ever be used, or if the requirements built are correct as per future needs as nobody can define them correctly at the moment.
Probably if requirement handling is managed more at database level than in the code, it gives more flexibility to the product.
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 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 9 2009 10:00AM GMT
Posted by: Jaideep
business application,
Software Project,
UAT,
software product,
Project Management
Next month is a marriage in your close relation. You plan to buy an expensive suit length and get it stitched by the best tailor in the city. You buy the best cloth, go to the best tailor, he takes your measurement and gives you a trial date suitable to you. You go on that date, find minor or no change in the stitched suit, tell him the alterations required and get your fully perfect suit after 2 days, a week before the function date.
Your customer decides to go for a business application, decides on you to build it and implement it, gives you an order, you take the measurement (understand business rules and customer requirements), you give them the tentative date for trial (UAT)… but UAT goes down flip flop. You are not able to deliver the product on promised date.
Your tailor delivered the suit, with your complete satisfaction, on the promised date.
Where is the difference? Something went perfectly between measurement and trial date for your suit that your tailor had to deliver to you but not for your product that you had to deliver to your customer.
This is called product sizing and team sizing i.e. project sizing.
Sep 7 2009 11:00AM GMT
Posted by: Jaideep
Software Project,
project manager,
Project Management,
business knowledge,
project team,
team member,
software product,
product meeting,
project meeting,
customer meeting,
technical depth,
technical knowledge,
project feedback,
team feedback,
customer feedback,
project failure
Project Failure: First failure will downgrade the level of next project to be given to the project manager. Not only this, but it will also trigger hidden cameras in the organization that start monitoring each and every step of project manager. These hidden cameras could be top management or some selected down the line people working with project manager.
Customer Feedback: Organizations are taking customer feedback very seriously. A remark by a customer regarding a project manager – “I want this project manager to manager all my future projects ordered to you. Infact if you don’t depute this person as project manager, you don’t accept our orders” triggered such a magic that it immediately presented the project manager with an out-of-turn hefty increment. On the other hand a customer CEO sent a confidential email message to the CEO of projects organization stating – “We don’t want the current project manager to be seen in out campus with immediate effect” put a very big question mark on project manager’s capabilities.
Project Team Feedback: Sometimes even if Project fails project manager is able to survive if project team and customer give a positive feedback. Then the reasons are different which are beyond the control of project manager. But if project fails and feedback is also not very positive, all axes will fall on project manager’s neck.
Lack of Technical Depth: A shallow or artificial demonstration of technical depth will not help for long. Although project manager has not to do technical activities on his own but his depth of knowledge will definitely help in driving the project in right direction and meeting targets.
Lack of business knowledge: Sometimes smart team members manage many a weaknesses of their project manager if he has demonstrated his strength in certain areas. But the lack of business knowledge is something that will certainly affect the product built, customer confidence in product and project manager’s knowledge. And if project manager is not clear about the business concepts of the customer, his presence in project, product and customer meetings will not be as effective as it is supposed to be.
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.
Jul 28 2009 10:00AM GMT
Posted by: Jaideep
technical,
load testing,
testing,
software product,
framework,
Software application,
.Net,
J2EE,
server,
server application,
presentation server,
application server,
database server,
MS SQL Server,
Oracle,
Apache,
Websphere,
IIS,
OS,
operating system,
hardware configuration,
RAM,
processor,
harddisk,
LAN,
dial-up
1. Framework: What is the framework being used in the application? For example it may be .Net or J2EE or any other.
2. Servers: What all server services you are using to run/ use this application? What standard server applications are used for Presentation, Application and Database level? Some examples could be MS SQL Server, Oracle, Apache, Websphere, IIS etc.
3. Number of machines: Are these servers running on same machine or different machines. If different machines how many machines and what servers specfically on which machine.
4. Details of these machines: The details of the machines running all these server applications or server services. Details would include Operating System, Hardware configuation – like Hard disks, RAM, processors etc.
5. Access details: Last but not the least important point is how the users will be accessing the application – via LAN, through dial-up, through internet, through some specific port and third party tool etc.
Jul 24 2009 10:00AM GMT
Posted by: Jaideep
load testing,
testing,
quality,
software product,
server,
Test Server,
production server,
Staging Server,
server configuration,
n-tier,
2-tier,
3-tier,
Software application,
n-tier application,
application,
browser,
browser version,
architecture,
performance,
protocol
Which Server: Where is the load testing intended to be performed? Is it the test server, production server or staging server where load testing is to be performed? If it is being performed on Production Server, it is ok. Otherwise if it is to be performed on test or staging server, be careful that it is as near to production server in terms of configuration and setup as possible. It may give wrong projections if there is a wide gap in environment which is to be used in real versus the environment on which the test is performed.
How many Tiers: It is very important to understand how many tier application is, on which the load testing is to be performed. The n-tier count should include the client also.
What Browsers: Be very clear and specific on defining what all browsers are meant to be used for running this application (if this is a web application). The browser and its version is very important to conduct the load testing as each browser behavior, architecture and performance varies. Even between the different versions of the same browser.
What Protocols: Whether this is a client server application, web based application or n-tier application – identifying what protocols you are using to run the application is very important.
Jul 20 2009 10:00AM GMT
Posted by: Jaideep
tester,
Development,
Software Project,
software product,
Project Management,
customer requirement,
test case,
testing report,
test report,
bugs report,
quality control,
QC,
quality,
product quality,
software quality,
developer,
development team,
code writing,
coding
The responsibility of a tester is to ensure the peace of mind of the end users who are going to use the software product. Another target should be to safeguard customer’s investment in the product. In order to discharge this responsibility, the tester should focus all his skills on understanding customer requirements and measures to map it with product built by writing appropriately comprehensive test cases, performing test and preparing a detailed self-explanatory test report. Complex business requirements will require extraordinary level of understanding. Keep in mind the budget and time constraint for performing testing without compromising with the coverage or quality.
The overall impact of testing should be clearly visible on the product built. The bugs reported should bring a sense of belonging with the developers and customer users. Clarity of bugs in testing report should not only help developer to fix defects properly but guide him not to repeat the same type of issues in future releases. This may happen slowly but gradually should help in increasing developer’s performance and quality of code writing. After all the development team should start taking testers as their best friends and well wishers instead of someone who is trying to find out the weakness in code writing.
