test case repository

Mar 9 2009   10:28AM GMT

20 points for organizational self evaluation to check where it stands in Software Project Management

Posted by: Jaideep
1. organizational self evaluation, software project management, Project Management Methodology, project metrics, customer expectations, organizational goals, continuous improvement, software development, software testing, software bug, product release, process integration, project management evaluation checklist, customer feedback, customer request, innovation process, software implementation, project implementation, post implementation, project manager, project team, roles and responsibilities, on-site project, off-site project, project overrun, Risk analysis, Risk Plan, empowerment, Code repository, test case repository

1. Does a formal Project Management Methodology exist in your organization?
2. Are you using some metrics to check if this is the right methodology?
3. What is the degree of improvement required in your current methodology to meet your customer expectations?
4. What are your organization’s primary and secondary goals?
5. Do you agree that there is always a scope for continuous improvement in everything we do – be it process, method or skills?
6. Do you agree that a product developed without any pre-defined procedure has varying chances of success?
7. Do you have a culture of performing development and testing as separate activities?
8. Do you assure a bug-free product at the time of its release?
9. Do you see all your processes integrated going hand in hand?
10. Do you get your payments from customer in time?
11. Do you have a process to capture customer feedback and request?
12. Do you have an innovation process in place?
13. Do you have a post implementation review in place?
14. Are your project managers and their teams aware of their roles and responsibilities – on-site and off-site?
15. Do you have project overruns often?
16. Do you have a risk analysis and planning process in place?
17. Are your employees delighted in doing whatever they are asked for?
18. Do you have empowerment process in place?
19. Are you certain about success in your projects or is it by chance/ by luck?
20. Do you have a repository of code, test cases etc. for re-use?

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.

Mar 2 2009   9:59AM GMT

10 golden rules for Requirements Based Testing

Posted by: Jaideep
business knowledge, software, tester, test case, test coverage, unit testing, integration testing, change management, test case repository, test metrics

10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.

9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.

8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.

7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.

6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.

5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.

4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.

3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so atleast the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).

2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.

1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.