Jul 13 2009 10:00AM GMT
Posted by: Jaideep
performance testing,
software testing,
testing,
quality control,
bottleneck,
execution,
Project Lifecycle,
Software Project,
testing lifecycle,
testing phase,
testing tool,
testing parameter,
testing component,
load testing,
volume testing,
stress testing,
Test Plan,
test strategy,
load modeling,
scripting,
test script,
testing script,
benchmarking,
test case,
test execution,
test report,
testing report
As in a software project, the complete project lifecycle comprises of different phases. Similarly the performance testing lifecycle also comprises of various phases. Performance testing is usually, as the name suggests, is done to evaluate or examine the performance of the software product with the help of some tools and certain parameters. The performance testing may include components based on the requirements that include – load, volume, stress etc.
Five prominent phases of performance testing can be:
Phase 1:
a) Test Plan
b) Test strategy
Phase 2:
a) Load Modeling
b) Scripting
c) Benchmarking criteria
Phase 3:
a) Benchmark execution
b) Other executions
c) Reports generation
d) Reports Analysis
Phase 4:
a) Reports reconciliation
b) Reports compilation
c) Final Test Report
d) Bottlenecks identification
e) Recommendations
Phase 5:
a) Execution of recommendations
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 6 2009 9:42AM GMT
Posted by: Jaideep
software testing effort estimation,
software testing,
testing effort,
functional specifications finalization,
functional specifications,
sizing of software testing effort,
test case,
testing time-line,
testing timeline,
testcase,
quality standards,
tester,
testing,
Test Plan,
testing plan,
test result,
test report,
development team,
developer,
software development,
bug report,
bugs report,
testing guidelines,
test plan guidelines,
test estimation guidelines,
testing knowledge,
business rule,
business process,
functional coverage,
bug-proofing
If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.
To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.
Mar 4 2009 10:03AM GMT
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 27 2009 9:54AM GMT
Posted by: Jaideep
software quality,
project quality,
quality standards,
quality measures,
quality metrics,
software metrics,
Project Management,
Software Project,
customer requirements,
software product,
software design,
business requirements,
functional requirements,
software delivery,
Project Delivery,
project execution,
project initiation,
Project Development,
project implementation,
software strategy,
test strategy,
test case,
Test Plan,
test scenarios,
test results,
fixing of bugs,
project close-out,
post implementation phase of project
The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
