Oct 23 2009 10:00AM GMT
Posted by: Jaideep
business analysis,
Project Management,
Software Project,
software,
business process,
business rule,
customer requirement,
software requirement,
quality,
process,
Development
Business Analyst is a quite powerful role forming the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer.
For a software company having various new development projects a business analyst has to understand the existing business processes, methodology, rules etc. of the customer, document it (which itself is a specialized task) and hand it over to development team to embed the customer requirements into the software to be built.
For a software (or IT) sales company a business analyst has to sit behind the sales/ business development teams – understanding their current process of acquiring new business or sustaining current business and bring out a better approach, methodology, process to enhance business in terms of new business and holding current business.
For a manufacturing company a business analyst has to understand the process, re-engineer it to enhance the production, product yield, thereby increasing customer satisfaction and reducing defects or rejections.
A business analyst ‘s various caps thus include – business process analyst, business strategy analyst, business methodology analyst thereby becoming a backbone to business process managers, sales teams, management, development teams , product teams, quality teams etc.
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.
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.
Mar 6 2009 9:42AM GMT
Posted by: Jaideep
software testing effort estimation,
software testing,
testing effort,
functional specifications finalization,
functional specifications,
sizing of software testing effort,
test case,
testing time-line,
testing timeline,
testcase,
quality standards,
tester,
testing,
Test Plan,
testing plan,
test result,
test report,
development team,
developer,
software development,
bug report,
bugs report,
testing guidelines,
test plan guidelines,
test estimation guidelines,
testing knowledge,
business rule,
business process,
functional coverage,
bug-proofing
If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.
To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.
