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.
Aug 5 2009 10:00AM GMT
Posted by: Jaideep
UAT,
user acceptance test,
testing lifecycle,
software testing,
product testing,
software product,
software development,
customer specification,
interfacing,
functional testing,
functional requirement,
functional specification,
business rule,
business process,
integration test,
software build,
validation testing,
defect fixing,
bug fixing,
software defect,
software bug,
appearance testing
UAT or user acceptance testing comes as the last exercise in software testing lifecycle. It is probably the first phase or beginning of customer preparing to takeover the charge of the product. Actually this is a sort of test drive by a perspective buyer who has studied well about a car, has made up his mind to buy it but wants to satisfy himself by actually sitting in the car and driving it. Even if you have made up your mind to buy a particular model and after sitting in the car or after having the test drive, something does not suit you, the decision can take 180 degrees turn.
The same usually does not happen in UAT because the unlike car the software has been built as per customer specifications. UAT usually includes interfacing (if any), look and feel, ease of usage, functional requirements, integration test etc.
Like a car test drive, here also use runs the complete software to assess if the software is meeting their requirements completely or not. It is the last place where the user gets to determine whether or not the software meets his or her requirements. But one thing is very clear – whatever defects occur during UAT, their fixing cost goes manifold as compared to the same defects occurring during the initial building of software.
Main difference between the earlier testing done at development place by testers is that here the business process and validations built in the software will be checked by a business process owner with real data.
Probably in this busy world, if the end user, by any chance is available during the development and testing phase to do appearance, functional, process and validations testing, it would save a big amount of time and money.
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.
Nov 24 2008 10:14AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
SOA,
software quality,
functional testing,
Quality Assurance,
performance testing,
Software testers,
load testing,
RIA,
software qa,
AJAX,
.OST files,
Software testing methodologies,
Bug Control Management,
Open Source Testing Tools,
Traditional Testing Tools,
Web2.0,
Selenium,
HTMLUnit,
TestGen4Web,
PushToTest,
volume testing,
testingtool,
testing tools
In today’s scenario when the schedules are tight, budgets are low and different technologies being used, software developers and testers are having great challenges of building/testing/releasing bug-free software by meeting all criterions. The question arises here is – how to cover all the development/testing requirements that to in such a short span of time with high rate of accuracy in development and testing. In such a scenario, the best option would be to use Open Source Test (OST) tools. And why not, when Open Source Test (OST) tools provide most economical solution and on top of it they are more flexible as compared to labeled vendor test tools (or traditional testing tools). So many big corporate organizations these days are using Open Source Test (OST) tools such as Ford, AMD and many more.
Many of the open-source testing tools support most of the technologies being used in development these days. Be it AJAX development or rich internet application (RIA) i.e. Web 2.0 on service oriented architecture (SOA), or any other web/server based application.
Some of the Open Source Test (OST) tools are – PushToTest, HTMLUnit, TestGen4Web, Selenium etc. that take care of functional testing, performance testing, load testing and volume testing. If you see all these testing are not possible to conduct manually and using a traditional testing tool would be never be a cost effective solution.
