Aug 10 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
software testing,
quality control,
QA,
QC,
functionality,
new feature,
Application development,
quality,
application quality,
functional testing
There is no end to an application. It always asks for a new feature, alter in functionality, addition/ change of business rule etc. With any change in the existing application running in a live environment, the change needs to be tested for all aspects of quality before putting it live. The question comes what should be the scope of testing in this case. Should tester test only for the change part or the complete application?
A change in application small or big is always going to mark an impact on the whole application. Even if not on the whole application, to some extent at various places in the application. Sometimes it could be beyond the knowledge of developer.
Therefore, in my opinion, it is wise to test to whole application even if it going to take more time and efforts to minimize the risk of impact of ‘change’ in the application.
Jul 17 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
Project Management,
people management,
HR,
QA,
QC,
Q-tag,
developer,
quality,
quality control,
quality culture,
quality building,
product,
stakeholder,
business analyst,
project manager,
project team,
development team,
testing team,
implementation team,
product build
People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.
Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:
Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.
Jul 15 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Q-tag,
quality control,
Software Project,
Project Management,
stakeholder,
project methodology,
project management framework,
project implementation,
software build,
software implementation,
product approval,
Quality-tag,
project team,
development team,
implementation team,
testing team,
team,
QC,
QA,
business analyst,
re-testing,
testing,
Bug,
bugs report,
test report
In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.
If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.
Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?
Jul 6 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software tester,
software testing,
Project Planning,
Test Plan,
test case,
product analysis,
customer requirement analysis,
product functionality,
software functionality,
software documentation,
software document,
test result,
test performance,
software performance,
testing process,
quality analyst,
QC,
QA,
quality control,
load testing,
performance testing,
functional testing,
security testing,
test coverage,
software build,
software,
analysis,
functionality
A software tester evaluates software based on certain parameters. These parameters are set as per product, customer and organization requirements. Testing could be just of functional features or include load, performance and security. For any parameters a tester has to work as quality analyst to understand requirements, features and accordingly build test cases and perform test. This is the quality control part. On quality assurance front the quality team has to build standards for requirement freezing, planning, development, implementation and post implementation phases of a project.
A software tester at various stages of a project gets on to the job of a Quality Analyst by performing following tasks:
Analysis of customer requirements: The first and foremost analysis required is that of the customer requirements to ascertain if it is complete, detailed and free from any confusions, ambiguities or equivocalness. Any flaw in requirements will certainly lead to a big disaster at a later stage. Unclear requirements are not difficult to build, but are difficult to manage. Every requirement should be in black and white. Each line should be very clearly documented such there should be nothing hidden between the lines.
Analysis of Product Functionality: Requirements documented and product built has to go hand in hand. It should not happen that requirements and product speak differently even a single line. Usually while testing functionality of a product, tester forgets to refer to requirements documented, or asks developer about the functionality. The developer will certainly explain him the functionality he has built not what exactly has been mentioned in the requirements document. If this happens, it will certainly cause a big blast at implementation or acceptance stage.
Analysis of Product related documents: There are many documents prepared during the project. Some are meant for internal use, some are prepared for customer. All these documents need to be inspected thoroughly and neatly.
Analysis of test results: Test cases are built to perform tests resulting in bugs report or test results report. A thorough scan is must to ensure complete coverage and thorough testing. The report should be detailed in all respects in terms of clarity and coverage.
Analysis of Testing Process: The testing process once establishes need to be revisited again and again to improve further at every go. Once established does not mean it is ultimate and best. Improvement has always a scope howsoever best your process or product is.
Mar 23 2009 10:30AM GMT
Posted by: Jaideep
Quality Assurance,
project manager,
Project Management,
recession,
Software Project,
scarcity of business,
win-win situation,
smart weapon,
software organization,
software business,
experience,
knowledge,
wisdom,
quality,
QA,
QC,
quality control,
quality manager,
product quality,
product and quality,
software team,
project team,
Project Plan,
quality issue,
product knowledge,
quality strength,
quality dependence,
thinking,
innovation,
brainstorming,
linchpin,
cornerstone,
team management,
team culture,
ascending approach,
organizational interest,
best result
Due to recession, there is scarcity of business and projects for software organizations. In such a situation, the projects in hand (and the forthcoming ones) have to be handled very carefully for a win-win situation. To attain that, there are certain smart weapons that a project manager needs to be equipped with which will not only make him and his organization a winner but would definitely have an edge over the competitors to acquire more projects. The weapons are well tested based on experience, knowledge and wisdom.
The 20 most powerful and smart weapons can be listed as:
1. Place importance on Quality
2. Be Sincere and frank in your meetings of all levels
3. Maintain and demonstrate a sense of mission
4. Work hand in hand with your peers – quality manager, development manager etc.
5. Be convinced of the trust between your product and quality
6. Let your team feel the weight of responsibility
7. Plan your course of action on all issues to avoid a crisis
8. Listened attentively to every word of your customer demonstrating great sincerity towards product and customer
9. Have strong interest in quality issues
10. Be highly knowledgeable about your product
11. Your Product and Quality (with your technological prowess and their quality strengths) must work together
12. Higher is the rate of dependence on Quality, higher is the success rate
13. To avoid major problems never leave a problem unresolved for tomorrow
14. Thinking, Innovation, Brainstorming are good tools if used regularly
15. Always have common awareness of all issues, so that your discussions are of highly substantive in nature
16. Be a linchpin (A central cohesive source of support and stability)
17. Consider customer requirements as “cornerstone” throughout the project. (The fundamental assumptions from which something is begun or developed or calculated or explained)
18. Build a culture of putting fullest sincere effort by everyone in the team(s) (vertical and horizontal).
19. Maintain a continuous gently-ascending approach (act of changing in an upward direction)
20. As a bearer of the highest level of responsibility reaffirm your determination to safeguard the organizational interest and ensure the best of the results
Feb 18 2009 10:02AM GMT
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
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
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.
