SQA

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.

Feb 18 2009   10:02AM GMT

Dear Product Manager don’t cheat your customer by bypassing final ‘testing’ of the product before launch

Posted by: Jaideep
Project Management, Software Project, SQA, QC, Quality Assurance, Software Quality Control, SQC, QA, product development, product manager

When work pressures are too high, deadlines are on head, we tend to bypass our own standards, procedures and policies. A product manager if affords to skip testing for that purpose, that means he is committing a crime which is quite serious offense. Any management supporting this idea becomes part of the crime. Testing on ‘wish’ of a person (the product manager), depending on time availability or delay in development clearly states there are no plans in reality. If development of the product is delayed, the implementation can be delayed, whatever be the pressure from customer. If customer is befooled by declaring that the product is ready to launch (which has in actual not been tested properly, and customer is unaware of this), that means the customer is being cheated.

The whole scenario calls for a delay or failure, but who cares – there is no discipline being followed and the confidence is – “we will handle any situation”. Had the product launch been delayed by clearly stating to the customer (or to the top management, if pressure if from there) that the testing and fixing of bugs will take some more days, the customer (or top management) would have always welcomed the decision and would surely have understood your compassion (and passion) towards product, organization and the customer. Definitely it is a call for troubles during launch and implementation stage if the ‘testing’ has been bypassed.

If this is so, we still are the same as we were, have learnt nothing from the past and are betting for failure in success. That also means that QA is being displayed as a ‘showpiece’ to customer or to top management.

Endnote – if you have an opinion that ‘testing’ or QC of the product is a useless activity, if you believe most of the bugs reported by the testers are useless, you are as right as your highest level commitment towards the product, development, yourself, your customer and your organization.

Feb 2 2009   9:51AM GMT

A Note for budding stars – the testers! And a tip to QA Head

Posted by: Jaideep
tester, testing, software, QA, QC, SQC, SQA, developer, quality head, quality manager, software quality

The young inexperienced or short experienced budding testers are the one who will determine the future of testing. This is the prime thing that the QA head has to keep in mind while grooming and mentoring them. The testers have to have a firm belief that the future of testing is going to be brighter than today and that is why the QA Manager and the testers have to deliver their best efforts to all their endeavors. They have to exert their utmost efforts, contributing to the building of a software product (built by developers, being tested by QC team thereby delivering the best of it!) that properly reflects your spirit and drive in testing.

The key aspect is not to compromise with your fundamental values of Testing, such as clear Testing Mission, Policy, Plan, Procedure etc.

Testers have undoubtedly a strong affinity towards testing that makes them close to the product, development team with a joint mission to deliver a bug-free product.

Dec 24 2008   10:04AM GMT

Software Quality – Overlooked or Underestimated – both are dangerous!

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, QA, software quality, SQA, Quality Assurance, SDLC, software qa, Project Lifecycle, ChangeManagement, Project Development, QC, Development Manager

The goal of any software organization is to develop software applications in-house, or co-develop with an external agency, that meet and exceed internationally accepted quality standards. Every one knows it, that the key role in this is of QA department. With this intention, a dedicated QA department is structured in the organization, for the purpose. But most of the time, the move towards the objective mentioned above is limited or missing at all. Although the development managers too agree that in the software development business software quality is the key to their success.

In view of the above, the development managers need to revisit this area which mostly has not received all the necessary attention it deserves and which is something so crucial that the organization can ill afford to overlook.

Mostly, even if QA is in existence in the organization, it is used to test poorly designed and developed software. The reasons for this are well known, and the major one is that the QC is misconstrued to be a mere testing activity rather than looking at QC from a more holistic perspective. To this extent, the QA/QC department needs to be invited and involved at all stages of the software development lifecycle (SDLC).

To fulfill organization’s expectations and business goal in this regard, the development managers need to have a fresh discussion with QC/QA head to prepare a charter on how they plan to achieve it.