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.
Jun 22 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
User Manual,
Project Management,
Software Project,
project manager,
stakeholder,
project team,
project quality,
quality,
project walkthrough,
build phase,
project phase,
quality control
As already has been discussed, User Manuals play a crucial role in any software project and are the solid bonding between product, users, customer management and vendor project team. The stronger this bond is the more comfortable and happy each stakeholder will be. Each player has to play a crucial role during the game of building of User Manuals. Both Project Management teams have to work hand in hand for that.
The quality of User Manuals has also been discussed in my earlier blog (Six Pack User Manual – how to build).
Let us discuss below the role to be played by the respective project managers in this regard:
Vendor Project Manager has to ensure that the user manuals are built along with the product development and are vetted/ approved by their QC team via a walkthrough. If need be they should as for draft manuals in build phase. If there is a foreign language issue, the Project Manager should also ensure that the user manuals are required in their local country language.
Customer Project Manager has to check that user manuals are complete in all respects, and checked thoroughly before handing it over to the respective key users
Jun 8 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
software development,
Project Management,
project organization,
project team,
project delay,
project completion,
on-site development,
testing,
tester,
QC,
quality control,
project implementation,
software implementation,
functional lead,
technical lead,
quality,
software quality,
project quality
Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.
So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:
5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.
4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.
3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.
2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
level.
1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.
All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.
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.
Jan 19 2009 10:14AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
software,
software quality,
Quality Assurance,
Software testers,
Bug,
software development,
developer,
tester,
Bug Management,
Bug Control Management,
QC
Bugs are often invincible during development, especially in large projects when multiple sub-teams of developers are working on development of different sub-modules of the project. The software developed (or during development) will always appear innocent and bug-free to the team of developers. It is the tester’s tough task to puncture the software and find out the hidden bugs. If bugs during testing phase are not found completely, it may lead to disastrous consequences, depending on the severity of unfound bugs. That is why, for developers and testers it is very important to understand the complete flow, sequence, modules, sub-modules, functional sequence to build accurately by developers and verification by testers.
Testers have to exercise the testing process and they have to ensure that they are following the right process to identify as many bugs as possible.
