development plan

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.

Mar 4 2009   10:03AM GMT

10 top “Do this if you want blunders!” in Software Development and Software Testing

Posted by: Jaideep
software development, software testing, Project Management, Software Project, Quality Goals, software quality, SQA, SQC, product development, project documentation, organizational goals, time to test, development plan, Project Plan, Test Plan, test case, implementation plan, project close-out, top management requirements, requirements analysis, business requirements, change management, Risk Plan, Risk Management, Software Repository, Code library, Code repository, test case repository, project standards, project methodologies, software development standards, software development methodologies, test standards

1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.