customer specification

Sep 16 2009   12:00PM GMT

Five ways to workout ‘testing effort”

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

User Acceptance Testing (UAT)

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.