FAQ3

Stress Test your Web Application from the Cloud. Unlimited Load. Competitive Price.
Software QA and Testing Less-Frequently-Asked-Questions

This section of Softwareqatest.com is for those who have some experience in the software development world and already have a grasp of QA and testing basics. (For information on QA and Testing basics, see Softwareqatest.com sections FAQ 1 and FAQ 2).

Items in this section address some 'beyond-the-basics' questions, along with some discussion of possible answers.

Some of the questions have no definitive answers, some are questions more often dealt with by upper management (if they are dealt with at all), and some have more to do with psychology than technology. For these reasons they tend to be questions that are less frequently asked, even though they are important questions.

Additional items will be added over time. Some of the questions shown were submitted previously by readers; suggestions for additional topics are welcome.

* Why is it often hard for organizations to get serious about quality assurance?
* Who is responsible for risk management?
* Who should decide when software is ready to be released?
* What can be done if requirements are changing continuously?
* What if the application has functionality that wasn't in the requirements?
* How can QA processes be implemented without reducing productivity?
* What if an organization is growing so fast that fixed QA processes are impossible?
* Will automated testing tools make testing easier?
* What's the best way to choose a test automation tool?
* How can it be determined if a test environment is appropriate?
* What's the best approach to software test estimation?

Why is it often hard for organizations to get serious about quality assurance?
Solving problems is a high-visibility process; preventing problems is low-visibility. This is illustrated by an old parable:
In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied,
"I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords."
"My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors."
"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."
This is a problem in any business, but it's a particularly difficult problem in the software industry. Software quality problems are often not as readily apparent as they might be in the case of an industry with more physical products, such as auto manufacturing or home construction.

Additionally: Many organizations are able to determine who is skilled at fixing problems, and then reward such people. However, determining who has a talent for preventing problems in the first place, and figuring out how to incentivize such behavior, is a significant challenge.

Return to top of this page's FAQ list

Who is responsible for risk management?
Risk management means the actions taken to avoid things going wrong on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a 'buck stops here' person who can consider the relevant tradeoffs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities.

It is not unusual for the term 'risk management' to never come up at all in a software organization or project. If it does come up, it's often assumed to be the responsibility of QA or test personnel. Or there may be a 'risks' or 'issues' section of a project, QA, or test plan, and it's assumed that this means that risk management has taken place.

The issues here are similar to those for the LFAQ question "Who should decide when software is ready to be released?" It's generally NOT a good idea for a test lead, test manager, or QA manager to be the 'buck stops here' person for risk management. Typically QA/Test personnel or managers are not managers of developers, analysts, designers and many other project personnel, and so it would be difficult for them to ensure that everyone on a project is handling their risk management responsibilities. Additionally, knowledge of all the considerations that go into risk management mitigation and tradeoff decisions is rarely the province of QA/Test personnel or managers. Based on these factors, the project manager is usually the most appropriate 'buck stops here' risk management person. QA/Test personnel can, however, provide input to the project manager. Such input could include analysis of quality-related risks, risk monitoring, process adherence reporting, defect reporting, and other information.

Return to top of this page's FAQ list

Who should decide when software is ready to be released?
In many projects this depends on the release criteria for the software. Such criteria are often in turn based on the decision to end testing, discussed in FAQ #2 item "How can it be known when to stop testing?" Unfortunately, for any but the simplest software projects, it is nearly impossible to adequately specify useful criteria without a significant amount of assumptions and subjectivity. For example, if the release criteria is based on passing a certain set of tests, there is likely an assumption that the tests have adequately addressed all appropriate software risks. For most software projects, this would of course be impossible without enormous expense, so this assumption would be a large leap of faith. Additionally, since most software projects involve a balance of quality, timeliness, and cost, testing alone cannot address how to balance all three of these competing factors when release decisions are needed.

A typical approach is for a lead tester or QA or Test manager to be the release decision maker. This again involves significant assumptions - such as an assumption that the test manager understands the spectrum of considerations that are important in determining whether software quality is 'sufficient' for release, or the assumption that quality does not have to be balanced with timeliness and cost. In many organizations, 'sufficient quality' is not well defined, is extremely subjective, may have never been usefully discussed, or may vary from project to project or even from day to day.

Release criteria considerations can include deadlines, sales goals, business/market/competitive considerations, business segment quality norms, legal requirements, technical and programming considerations, end-user expectations, internal budgets, impacts on other organization projects or goals, and a variety of other factors. Knowledge of all these factors is often shared among a number of personnel in a large organization, such as the project manager, director, customer service manager, technical lead or manager, marketing manager, QA manager, etc. In smaller organizations or projects it may be appropriate for one person to be knowledgeable in all these areas, but that person is typically a project manager, not a test lead or QA manager.

For these reasons, it's generally not a good idea for a test lead, test manager, or QA manager to decide when software is ready to be released. Their responsibility should be to provide input to the appropriate person or group that makes a release decision. For small organizations and projects that person could be a product manager, a project manager, or similar manager. For larger organizations and projects, release decisions might be made by a committee of personnel with sufficient collective knowledge of the relevant considerations.

Return to top of this page's FAQ list

What can be done if requirements are changing continuously?
This is a common problem for organizations where there are expectations that requirements can be pre-determined and remain stable. If these expectations are reasonable, here are some approaches:

* Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
* It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
* If the code is well-commented and well-documented this makes changes easier for the developers.
* Use some type of rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
* The project's initial schedule should allow for some extra time commensurate with the possibility of changes.
* Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version.
* Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
* Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job.
* Balance the effort put into setting up automated testing with the expected effort required to refactor them to deal with changes.
* Try to design some flexibility into automated test scripts.
* Focus initial automated testing on application aspects that are most likely to remain unchanged.
* Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
* Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
* Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

If this is a continuing problem, and the expectation that requirements can be pre-determined and remain stable is NOT reasonable, it may be a good idea to figure out why the expectations are not aligned with reality, and to refactor an organization's or project's software development process to take this into account. It may be appropriate to consider agile development approaches.

Also see What is Extreme Programming and what's it got to do with testing? in FAQ #2.

Return to top of this page's FAQ list

What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it could indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. (If the functionality is minor and low risk then no action may be necessary.) If not removed, information will be needed to determine risks and to determine any added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality.

This problem is a standard aspect of projects that include COTS (Commercial Off-The-Shelf) software or modified COTS software. The COTS part of the project will typically have a large amount of functionality that is not included in project requirements, or may be simply undetermined. Depending on the situation, it may be appropriate to perform in-depth analysis of the COTS software and work closely with the end user to determine which pre-existing COTS functionality is important and which functionality may interact with or be affected by the non-COTS aspects of the project. A significant regression testing effort may be needed (again, depending on the situation), and automated regression testing may be useful.

Return to top of this page's FAQ list

How can Software QA processes be implemented without reducing productivity?
By implementing QA processes slowly over time, using consensus to reach agreement on processes, focusing on processes that align tightly with organizational goals, and adjusting/experimenting/refactoring as an organization matures, productivity can be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, avoid a 'Process Police' mentality, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureaucracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning, reviews, and inspections will be needed, but less time will be required for late-night bug-fixing and handling of irate customers.

Other possibilities include incremental self-managed team approaches such as 'Kaizen' methods of continuous process improvement, the Deming-Shewhart Plan-Do-Check-Act cycle, and others.

(See the Softwareqatest.com Bookstore section's 'Software QA', 'Software Engineering', and 'Project Management' categories for useful books with more information.)

Return to top of this page's FAQ list

What if an organization is growing so fast that fixed QA processes are impossible?
This is a common problem in the software industry, especially in new technology areas. There is generally no easy solution in this situation. One approach is:

* Hire good people
* Management should 'ruthlessly prioritize' quality issues and maintain focus on the customer
* Everyone in the organization should be clear on what 'quality' means to the customer

Depending on the growth rate, it is possible that incremental self-managed team approaches may be applicable, such as 'Kaizen' methods of continuous process improvement, or the Deming-Shewhart Plan-Do-Check-Act cycle, and others.

Return to top of this page's FAQ list

Will automated testing tools make testing easier?

* Possibly. For small projects, the time needed to learn and implement them may not be worth it unless personnel are already familiar with the tools. For larger projects, or on-going long-term projects they can be valuable.
* A common type of automated tool is the 'record/playback' type. For example, a tester could click through all combinations of menu choices, dialog box choices, buttons, etc. in an application GUI and have them 'recorded' and the results logged by a tool. The 'recording' is typically in the form of text based on a scripting language that is interpretable by the testing tool. Usually the recorded script is manually modified and enhanced. If new buttons are added, or some underlying code in the application is changed, etc. the application might then be retested by just 'playing back' the 'recorded' actions, and comparing the logging results to check effects of the changes. The problem with such tools is that if there are continual changes to the system being tested, the 'recordings' may have to be changed so much that it becomes very time-consuming to continuously update the scripts. Additionally, interpretation and analysis of results (screens, data, logs, etc.) can be a difficult task. Note that there are record/playback tools for text-based interfaces also, and for all types of platforms.
* Another common type of approach for automation of functional testing is 'data-driven' or 'keyword-driven' automated testing, in which the test drivers are separated from the data and/or actions utilized in testing (an 'action' would be something like 'enter a value in a text box'). Test drivers can be in the form of automated test tools or custom-written testing software. The data and actions can be more easily maintained - such as via a spreadsheet - since they are separate from the test drivers. The test drivers 'read' the data/action information to perform specified tests. This approach can enable more efficient control, development, documentation, and maintenance of automated tests/test cases.
* Other automated tools can include:

code analyzers - monitor code complexity, adherence to
standards, etc.

coverage analyzers - these tools check which parts of the
code have been exercised by a test, and may
be oriented to code statement coverage,
condition coverage, path coverage, etc.

memory analyzers - such as bounds-checkers and leak detectors.

load/performance test tools - for testing client/server
and web applications under various load
levels.

web test tools - to check that links are valid, HTML code
usage is correct, client-side and
server-side programs work, a web site's
interactions are secure.

other tools - for test case management, documentation
management, bug reporting, and configuration
management, file and database comparisons, screen
captures, security testing, macro recorders, etc.

Test automation is, of course, possible without COTS tools. Many successful automation efforts utilize custom automation software that is targeted for specific projects, specific software applications, or a specific organization's software development environment. In test-driven agile software development environments, automated tests are often built into the software during (or preceding) coding of the application.

See the Automation section of the 'Other Resources' page for other resources on test automation.

See the Softwareqatest.com Bookstore section on Software Test Automation for useful books with more information.

See the 'Tools' section for test tool listings and the 'Web Tools' section for web site testing tools.

Return to top of this page's FAQ list

What's the best way to choose a test automation tool?
It's easy to get caught up in enthusiasm for the 'silver bullet' of test automation, where the dream is that a single mouse click can initialize thorough unattended testing of an entire software application, bugs will be automatically reported, and easy-to-understand summary reports will be waiting in the manager's in-box in the morning.

Although that may in fact be possible in some situations, it is not the way things generally play out.
In manual testing, the test engineer exercises software functionality to determine if the software is behaving in an expected way. This means that the tester must be able to judge what the expected outcome of a test should be, such as expected data outputs, screen messages, changes in the appearance of a User Interface, XML files, database changes, etc. In an automated test, the computer does not have human-like 'judgement' capabilities to determine whether or not a test outcome was correct. This means there must be a mechanism by which the computer can do an automatic comparison between actual and expected results for every automated test scenario and unambiguously make a pass or fail determination. This factor may require a significant change in the entire approach to testing, since in manual testing a human is involved and can:

* make mental adjustments to expected test results based on variations in the pre-test state of the software system
* often make on-the-fly adjustments, if needed, to data used in the test
* make pass/fail judgements about results of each test
* make quick judgements and adjustments for changes to requirements.
* make a wide variety of other types of judgements and adjustments as needed.

For those new to test automation, it might be a good idea to do some reading or training first. There are a variety of ways to go about doing this; some example approaches are:

* Read through information on the web about test automation such as general information available on some test tool vendor sites or some of the automated testing articles listed in the 'Other Resources' Automation section.
* Read some books on test automation such as those listed in the Softwareqatest.com Bookstore
* Obtain some test tool trial versions or low cost or open source test tools and experiment with them
* Attend software testing conferences or training courses related to test automation

As in anything else, proper planning and analysis are critical to success in choosing and utilizing an automated test tool. Choosing a test tool just for the purpose of 'automating testing' is not useful; useful purposes might include: testing more thoroughly, testing in ways that were not previously feasible via manual methods (such as load testing), testing faster, or reducing excessively tedious manual testing. Automated testing rarely enables savings in the cost of testing, although it may result in software lifecycle savings (or increased sales) just as with any other quality-related initiative.

With the proper background and understanding of test automation, the following considerations can be helpful in choosing a test tool (automated testing will not necessarily resolve them, they are only considerations for automation potential):

* Analyze the current non-automated testing situation to determine where testing is not being done or does not appear to be sufficient
* Where is current testing excessively time-consuming?
* Where is current testing excessively tedious?
* What kinds of problems are repeatedly missed with current testing?
* What testing procedures are carried out repeatedly (such as regression testing or security testing)?
* What testing procedures are not being carried out repeatedly but should be?
* What test tracking and management processes can be implemented or made more effective through the use of an automated test tool?

Taking into account the testing needs determined by analysis of these considerations and other appropriate factors, the types of desired test tools can be determined. For each type of test tool (such as functional test tool, load test tool, etc.) the choices can be further narrowed based on the characteristics of the software application. The relevant characteristics will depend, of course, on the situation and the type of test tool and other factors. Such characteristics could include the operating system, GUI components, development languages, web server type, etc. Other factors affecting a choice could include experience level and capabilities of test personnel, advantages/disadvantages in developing a custom automated test tool, tool costs, tool quality and ease of use, usefulness of the tool on other projects, etc.

Once a short list of potential test tools is selected, several can be utilized on a trial basis for a final determination. Any expensive test tool should be thoroughly analyzed during its trial period to ensure that it is appropriate and that it's capabilities and limitations are well understood. This may require significant time or training, but the alternative is to take a major risk of a mistaken investment.

Return to top of this page's FAQ list

How can it be determined if a test environment is appropriate?
This is a difficult question in that it typically involves tradeoffs between 'better' test environments and cost. The ultimate situation would be a collection of test environments that mimic exactly all possible hardware, software, network, data, and usage characteristics of the expected live environments in which the software will be used. For many software applications, this would involve a nearly infinite number of variations, and would clearly be impossible. And for new software applications, it may also be impossible to predict all the variations in environments in which the application will run. For very large, complex systems, duplication of a 'live' type of environment may be prohibitively expensive.

In reality judgements must be made as to which characteristics of a software application environment are important, and test environments can be selected on that basis after taking into account time, budget, and logistical constraints. Such judgements are preferably made by those who have the most appropriate technical knowledge and experience, along with an understanding of risks and constraints.

For smaller or low risk projects, an informal approach is common, but for larger or higher risk projects (in terms of money, property, or lives) a more formalized process involving multiple personnel and significant effort and expense may be appropriate.

In some situations it may be possible to mitigate the need for maintenance of large numbers of varied test environments. One approach might be to coordinate internal testing with beta testing efforts. Another possible mitigation approach is to provide built-in automated tests that run automatically upon installation of the application by end-users. These tests might then automatically report back information, via the internet, about the application environment and problems encountered. Another possibility is the use of virtual environments instead of physical test environments, using such tools as VMWare or VirtualBox.

Return to top of this page's FAQ list

What's the best approach to software test estimation?
There is no simple answer for this. The 'best approach' is highly dependent on the particular organization and project and the experience of the personnel involved.

For example, given two software projects of similar complexity and size, the appropriate test effort for one project might be very large if it was for life-critical medical equipment software, but might be much smaller for the other project if it was for a low-cost computer game. A test estimation approach that only considered size and complexity might be appropriate for one project but not for the other.

Following are some approaches to consider:

Implicit Risk Context Approach:
A typical approach to test estimation is for a project manager or QA manager to implicitly use risk context, in combination with past personal experiences in the organization, to choose a level of resources to allocate to testing. In many organizations, the 'risk context' is assumed to be similar from one project to the next, so there is no explicit consideration of risk context. (Risk context might include factors such as the organization's typical software quality levels, the software's intended use, the experience level of developers and testers, etc.) This is essentially an intuitive guess based on experience.

Metrics-Based Approach:
A useful approach is to track past experience of an organization's various projects and the associated test effort that worked well for projects. Once there is a set of data covering characteristics for a reasonable number of projects, then this 'past experience' information can be used for future test project planning. (Determining and collecting useful project metrics over time can be an extremely difficult task.) For each particular new project, the 'expected' required test time can be adjusted based on whatever metrics or other information is available, such as function point count, number of external system interfaces, unit testing done by developers, risk levels of the project, etc. In the end, this is essentially 'judgement based on documented experience', and is not easy to do successfully.

Test Work Breakdown Approach:
Another common approach is to decompose the expected testing tasks into a collection of small tasks for which estimates can, at least in theory, be made with reasonable accuracy. This of course assumes that an accurate and predictable breakdown of testing tasks and their estimated effort is feasible. In many large projects, this is not the case. For example, if a large number of bugs are being found in a project, this will add to the time required for testing, retesting, bug analysis and reporting. It will also add to the time required for development, and if development schedules and efforts do not go as planned, this will further impact testing.

Iterative Approach:
In this approach for large test efforts, an initial rough testing estimate is made. Once testing begins, a more refined estimate is made after a small percentage (eg, 1%) of the first estimate's work is done. At this point testers have obtained additional test project knowledge and a better understanding of issues, general software quality, and risk. Test plans and schedules can be refactored if necessary and a new estimate provided. Then a yet-more-refined estimate is made after a somewhat larger percentage (eg, 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate.

Percentage-of-Development Approach:
Some organizations utilize a quick estimation method for testing based on the estimated programming effort. For example, if a project is estimated to require 1000 hours of programming effort, and the organization normally finds that a 40% ratio for testing is appropriate, then an estimate of 400 hours for testing would be used. This approach may or may not be useful depending on the project-to-project variations in risk, personnel, types of applications, levels of complexity, etc.

Successful test estimation is a challenge for most organizations, since few can accurately estimate software project development efforts, much less the testing effort of a project. It is also difficult to attempt testing estimates without first having detailed information about a project, including detailed requirements, the organization's experience with similar projects in the past, and an understanding of what should be included in a 'testing' estimation for a project (functional testing? unit testing? reviews? inspections? load testing? security testing?)

With agile software development approaches, test effort estimations may be unnecessary if pure test-driven development is utilized. However, it is not uncommon to have a mix of some automated positive-type unit tests, along with some type of separate manual or automated functional testing. In general, agile-based projects by their nature will not be heavily dependent on large one-shot testing efforts, since they emphasize the construction of releasable software in very short iteration cycles. These smaller multiple test effort estimates may not be as difficult to estimate and the impact of inaccurate estimates will be less severe.

For an interesting view of the problem of test estimation, see the comments on Martin Fowler's web site indicating that, for many large systems, "testing and debugging is impossible to schedule".

FAQ

FAQ1 - Software QA and Testing Frequently-Asked-Questions Part 1

* What is 'Software Quality Assurance'?
* What is 'Software Testing'?
* What are some recent major computer system failures caused by software bugs?
* Does every software project need testers?
* Why does software have bugs?
* How can new Software QA processes be introduced in an existing organization?
* What is verification? validation?
* What is a 'walkthrough'?
* What's an 'inspection'?
* What kinds of testing should be considered?
* What are 5 common problems in the software development process?
* What are 5 common solutions to software development problems?
* What is software 'quality'?
* What is 'good code'?
* What is 'good design'?
* What is SEI? CMM? CMMI? ISO? Will it help?
* What is the 'software life cycle'?

FAQ2 - Software QA and Testing Frequently-Asked-Questions Part 2

* What makes a good Software Test engineer?
* What makes a good Software QA engineer?
* What makes a good QA or Test manager?
* What's the role of documentation in QA?
* What's the big deal about 'requirements'?
* What steps are needed to develop and run software tests?
* What's a 'test plan'?
* What's a 'test case'?
* What should be done after a bug is found?
* What is 'configuration management'?
* What if the software is so buggy it can't really be tested at all?
* How can it be known when to stop testing?
* What if there isn't enough time for thorough testing?
* What if the project isn't big enough to justify extensive testing?
* How does a client/server environment affect testing?
* How can World Wide Web sites be tested?
* How is testing affected by object-oriented designs?
* What is Extreme Programming and what's it got to do with testing?

LFAQ - Software QA and Testing Less-Frequently-Asked-Questions

* Why is it often hard for organizations to get serious about quality assurance?
* Who is responsible for risk management?
* Who should decide when software is ready to be released?
* What can be done if requirements are changing continuously?
* What if the application has functionality that wasn't in the requirements?
* How can QA processes be implemented without reducing productivity?
* What if an organization is growing so fast that fixed QA processes are impossible?
* Will automated testing tools make testing easier?
* What's the best way to choose a test automation tool?
* How can it be determined if a test environment is appropriate?
* What's the best approach to software test estimation?

Resources - Other Software QA and Testing Resources

* Top Resources
* Software QA and Testing-related Organizations/Certifications/Conferences
* Links to QA and Testing-related Magazines/Publications
* General Software QA and Testing Resources
* Agile and XP Testing Resources
* Test Automation Resources
* Web QA and Testing Resources
* Web Security Testing Resources
* Web Usability Resources

Tools - Software QA and Test Tools

* Test tools
* CM tools and PM tools
* Web site test and management tools

Web Tools - Web Site Test Tools and Site Management Tools

* Load and performance test tools
* Java test tools
* HTML Validators
* Link Checkers
* Free On-the-Web HTML Validators and Link Checkers
* PERL and C Programs for Validating and Checking
* Web Functional/Regression Test Tools
* Web Site Security Test Tools
* External Site Monitoring Services
* Web Site Management Tools
* Log Analysis Tools
* Other Web Test Tools

Jobs & News - Jobs and News

* Web Job Boards useful to QA and Test Engineers
* Latest News Headlines -- Technology, Software Development, Computer Security, Tech Stocks, more...

Bookstore - Software QA and Testing Bookstore

* Software Testing Books
* Software Test Automation Books
* Software Quality Assurance Books
* Software Requirements Engineering Books
* Software Metrics Books
* Configuration Management Books
* Software Risk Management Books
* Software Engineering Books
* Software Project Management Books
* Technical Background Basics Books
* Other Books

Q4U Software Technologies

Training Organization

Q4U Software Technologies is overpoweringly dedicated to a globe free of defects by providing our customers with methods and tools to convey spotless software. To make an eternal input to the software engineering society in the way software defects are sensed.

Our Vision

To be recognized as a leader in providing IT solutions by extending quality software services on cutting edge technologies.

Our Mission

We dream… to earn an eternal customer.
We strive… to serve and satisfy our customers by enhancing the value of offered services and software thereby increasing benefits for all concerned.
We succeed… by ascertaining that we exceed your expectations.

For the past many years we have successfully taken up the challenge of providing our clients with software solutions and support systems to service their globe-spanning businesses.

Our strength lie in the quality of our work and our people. Our working consultants are the cream of the talent crop, skimmed from some of the world's best universities and institutions. We provide an environment that encourages imagination and innovation among team members.

For us partnering is more than a business policy. We believe that it is the seed of a secure and bright future. Since relationship building is important to us we seek to provide customer satisfaction in terms of quality and cost effectiveness of our products and services.

About us

Q4U Software Technologies identifies itself as University of Software Testing. It was established in 2002 with corporate office in Bangalore. We are very passionate about testing and regard testing as a scientific bug hunting activity that delivers clean software and optimizes business results for our customers.

The courses have been designed by leading professionals and industry experts. A comprehensive learning module addresses the requisites of software testing fraternity and hence is complete in approach. Courses offered by Testing Bess add value in terms of serving as a facilitation tool for software certifications. Reputed experts disseminate knowledge and which helps the software test professionals to acquire clear industry recognized software certifications. Q4U Software Technologies’ courses are flexible enough to match the curriculum to other certifications recognized in the industry.

Our test services and solutions cater to the QA needs of startups to established companies. These courses range from entry level to advanced level and cater to QA staff, developers and managers. Our resourcing division caters to the resource augmentation needs of software companies.

Our people are proficient specialists who understand the nuances, intricacies and technicalities of software testing having done it themselves. They deliver insights in an engaging and supportive manner. Our knowledge bank is updated continuously and skill sets constantly honed to ensure that the latest techniques, methodologies and processes are brought to your notice.

Highlights

• More than 125 corporate trainings conducted till date.
• Students work on real time projects.
• Courses conducted by professionals with extensive experience in software testing.
• Wide variety of software testing programs.
• Customized training programs to suit your needs.

Q4U Software Technologies Advantage


Q4U Software Technologies believes software testing is more than just cutting cost. It is concerning in creating industry ethics for clients. At Q4U Software Technologies we merge the discipline approach to software testing process, highest ability of people to assist our clients profit betterment delivery confidence, conventional time for shipment, lesser total cost of possession, and complete towering place in the market.

Q4U Software Technologies is committed to enable companies to achieve the highest value from their software. Towards this, we would be glad to be your strategic partner in delivering excellence to your customers.
Q4U Software Technologies certainty – assurance, time-tested methodologies, release, and business approach – ensures that we convey spotless software to our clients.

How Q4U Software Technologies add value to you?

“Validness of test cases”
"Are the test cases adequate?"
"We are not sure our software product is ready for release?"
"How much testing is sufficient?"
"We cannot invest in additional resources."
"We have invested in testing tool, but we are not sure the results are optimized."

Most companies are troubled by the above questions. We not only have answers for the above questions, but time tested and proven solution! We strongly believe in engineering tests and we apply formal techniques to design test cases to detect bugs. Our test strategy is goal-driven - that focus on pattern of possible defect types, how and when these may be detected cost effectively.

'Quality' cannot be, guaranteed if formal techniques structured process, appropriate automation and critical measurements are not in place.

Engineering tests is all about knowing what types of defects may be probable in a given system, what technique may uncover cost effectively, at what stage of the SDLC to apply and how to measure quality objectively.

We apply specification-based techniques that result in scenarios/cases and traced to requirements and to potential defects. Our test process is incremental - use objective metrics to assess product quality index, process effectiveness, and test progress. Finally, our approach to test automation is framework based and business-driven to maximize the ROI for our customers.

Our techniques are tried and tested over the years, in various projects across range of business domains. We have seen great success in using engineering techniques that are deployed, pragmatically over different projects and customers. Defect escapes are the true measure of quality of testing. Our defect escapes have been low!

Our test engineering model guarantee quality by use of techniques for test design, goal driven test strategy, objective measures for quality and progress tracking and framework based test automation architecture. In addition, backed up by a team that is creative and highly passionate about the work they do.

Strategy and process consulting

Quality and testing objectives must align with business objectives while maximizing return on testing investment. These goals can range from greater customer satisfaction or more predictable release dates to higher quality software. We will help you refine your objectives, align them with business vision, and help your organization to maximize test efficiency with the latest, most effective tools and methodologies, including building or optimizing a test automation program. Streamlining testing and quality processes is essential to compete in today's global marketplace.

In the past few years, Q4U Software Technologies has become increasingly involved with helping organizations optimally blend their domestic testing resources with offshore solutions.

Whatever your outsourcing needs, Q4U Software Technologies can:

• Augment your existing QA staff
• Provide a complete outsourced testing solution
• Deliver expertise as you're building a new product or quality assurance group
• Design and implement your test automation framework with guaranteed return-on-testing-investment
• Run load, performance and stress tests for your product today
• Extend your quality assurance capabilities, specifically in localization development efforts

You might be...

• Re-thinking or re-architecting your test and quality engineering program
• Assessing your current test and quality engineering state-of-the-practice
• Looking for training for your staff
• Forming a group for the first time
• Expanding your pre-existing quality engineering organization
• Deploying a new project utilizing the latest technologies
• Improving your existing test methods and techniques
• Looking to standardize or formalize the test process
• Adding, increasing or optimizing your test automation program
• Augmenting your test resources by outsourcing domestically or offshore
• Troubleshooting a test or quality engineering problem



Solutions can include...

• Establishing quality objectives
• Formulating the product development life cycle, release and testing processes
• Building correct infrastructure or optimizing current test resources
• Establishing the most effective balance of onshore/offshore testing
• Maximizing offshore resources
• Establishing a metrics program to gauge product stability and process efficiency
• Fixing quality process problems
• Establishing proper team sizing and project estimation.
• Assessing automation program possibilities
• Designing and deploying Web-based problem tracking and management process
• Streamlining guidelines for project planning, test plans, test reports, and other test related documentation
• Building an end-to-end quality strategy
• Developing new product-specific or technology-specific test methodologies
• Maximizing test automation return on investment

Objectives of testing as a discipline

Software testing is an essential and integral part of software development and runs parallel with the development activity to ensure that the product released is of highest quality. Software testing is not an ad-hoc process! There is science and engineering behind testing techniques.

It is NOT merely about learning tools, manual or automated testing. It is about understanding the concepts, techniques, process, and tools to enable you to discover defects effectively, and ensuring quality.


A GOOD test engineer should:


Be well-versed with test terminologies.

Be skilled in application of test techniques.

Understand the scope of different levels of testing.

Know how to conduct different types of tests.

Understand the process of testing.

Understand effective use of tools.

Know how to apply metrics and interpret them.

At Q4U Software Technologies, the emphasis is on laying this strong foundation in test engineering - Techniques, Disciplined process, Test types, and Tools - Our objective is to transform talented engineers into industry-ready test professionals.




Service Offering

As a QA associate we contribute and help our clients with a wide range of services at any stage of SDLC. It is guaranteed for One-Stop for entire range of testing activities.

Types of Testing:

• Functional Testing
• Load/stress Testing
• Performance Testing
• Volume Testing
• GUI Testing
• Reliability Testing
• Configuration Testing
• Compatibility Testing
• Usability Testing
• Interface Testing
• Beta Testing

Test Automation

It is important to realize that it doesn’t make sense to automate some/fewer tests. Overly complex tests are often more trouble than they are worth to automate. Hence we concentrate on automating the majority of our tests, which are probably fairly straightforward. Our software testing outsourcing services are uniquely designed to meet your needs. We don't require you to adapt to our QA testing approach; our approach adapts to you. You can place the highest degree of confidence in our proven test automation tools and methodologies, and in the expert staff who implement them. We'll leave no stone unturned in the search for bugs that could interfere with your software and harm your company's reputation. In fact, you can count on our refined skill and process to catch bugs earlier rather than later, saving you considerable expense.

We follow seven steps for Automation success:

Improve the Testing Process
Define Requirements
Prove the Concept
Champion Product Testability
Design for Sustainability
Plan for Deployment
Face the Challenges of Success

We have expertise in using the following tools in our projects:

[WinRunner] [QTP] [Test Complete] [Junit] [Astra Load Test] [Load Runner] [Bugzilla] [Mantis] [Zeno] [Test Director] [CVS] [VSS]


LSPS testing service

Our test lab is fully equipped to perform certain specialized non-functional tests that are critical and mandatory before software release but cannot be performed manually. Load / Stress / Performance / Scalability testing, and others like Volume testing, Reliability testing and assessment, Installation testing, Usability testing, Configuration / compatibility testing, Internalization testing.

Risk Analysis

The risk is measured by applying Risk analysis techniques for duration / low budget / low resources project, risk can be deduced by simply: -

Measuring Test Coverage.
Number of test cycles.
Number of high priority bugs.

Consulting

Our value addition is not limited to service level but can be extended to organization as a whole or at department level. Companies have institutionalized our practices/techniques and derived significant benefits. We would be glad to extend our expertise in implementing good test practices. To derive effective validation strategy, aiding in test tool selection and its effective use, building suitable escape model and deployment of efficient, practical, effective and measurable test process.

Recently Recruited Speaks

Vinutha Says:

Q4U Soft Tech is a company that anyone can surely rely on. I was placed in one of their many clients - "Testingczars Inc.," immediately after I started the training with them.

Vanitha Says:

A good management with rich experienced team has helped me in getting placed immediately.

Mahesh Says:

A fast response in placement has really astonished me and surely I am asking all my contacts to join Q4U Soft Tech. Very professional and trust worthy company I can think of.

Praveen Says:

No need to say any word regarding Q4U Soft Tech. Almost everyone in the software testing field knows him. Go join the course, worth every penny those, who want to make a career in Software testing.

Preeti Says:

I got to know a lot of things about software testing during the training, even though I was working as test engineer in a software company. Go join Q4U Soft Tech for a good career in your life.

Sharath Says:

This institution is good!! I studied in this institute and I am working in a good software company with a good package. Lab & faculties are also too good !!

New Batch started shortly on Manual Testing & Test Automation

Introductory offer (Span of 8 weeks)

We would not be charging any fee for the first week of our program, its all FREE , and if satisfied with our training aspirants can you continue for the rest of the program for a nominal fee of INR 10000/-

Course offered :

Course 1: Duration 60 Days (Entry Level for Software Testing to the industry)

I Software Testing I Configuration Management Tool VSS I Defect Management (BugZilla) I Test Automation QTP 9.2 & Autoczar I Trained On Live Application I Professional Services I

ABOUT TRAINER:

Training Program is conducted by a Certified Software Quality Professional, who comes with 12 years of experience in Software Verification and Validation. She/he has worked on various testing projects and has handled more than 144 corporate trainings for clients like SAP, Oracle, IBM, HP, GE, WIPRO, CTS, INFOSYS, PEROT, NOVELL, IFLEX, ACCENTURE, Soft Brand, Intel, Infosys, Wipro, Siemens, Symphony, and many more including Govt. of India and State Govt. undertakings. She/he has trained over 1800 Software Testing aspirants. She/he is well conversant with ISO and CMM standards and Software Testing Concepts and Test Automation.

Note: 100% fees will be refunded if you are not satisfied with the program! Topics covered are as per the standards.

For more details Contact:

#55,1st Block, 3rd phase, BSK 3rd stage, Kathariguppa, Bangalore – 85
080-41434962 / 9742440104 / 9620985333.

New Batch Started on Load Runner

Learn,
Performance Engineering & Load Runner.
From a Performance Testing Guru!!!

Duration: 16 full days (only on weekends)

Start Date: 19th June 2010

Timings: 10 am to 4 pm

Venue: Q4U Software Technologies

About Trainer:

Training program conducted by a CERTIFIED software quality professional in their own domain (Ex: ISTQB, Rational, Certified mercury product specialists in Win runner, QTP and Load runner).Our trainers worked on various kinds of projects and handled so many corporate trainings and he is having more than 6 years of experience.

Note: 100% fees will be refunded if you are not satisfied with the program! Topics covered are as per the standards.

For more details Contact:

#55,1st Block, 3rd phase, BSK 3rd stage, Kathariguppa, Bangalore – 85
080-41434962 / 9742440104 / 9620985333.

PROGRAMS OFFERED

Course 1: Duration 60 Days (Entry Level for Software Testing to the industry)

I Software Testing I Configuration Management Tool VSS I Defect Management (BugZilla) I Test Automation QTP 9.2 & Autoczar I Trained On Live Application I Professional Services I


Course 2: Duration 60 Days (Entry Level for Software Development to the industry)

I Software Development I C, C++ I Dot Net I JAVA, Core Java I


Course 3: Duration 15 Days (Advanced Tool Programs for working professionals & Also after Course 1)


I QTP 9.2 I Quality Center I Load Runner I Silk Test I Selenium I
Rational Robot I Test complete I Autoczar I


COURSE 4: Duration 180 Days (100 % Job Guarantee Program)

I Software Testing I Configuration Management Tool VSS I Defect Management (BugZilla) I Test Automation QTP 9.2 & Autoczar I Trained On Live Application I Professional Services I 8 hrs working on Assignments I Resume Building I