Softwaretestinggenius.com: reliable source for getting helpful Software Testing study materials

Softwaretestinggenius.com is a reliable source for getting excellent tutorial, self assessment quizzes, question papers, certification information and online help to qualify the ISTQB CTFL exam. This had been established with a motive to help aspirants in polishing their Software Testing skills and quality assurance by providing comprehensive information of Software Testing under one place.

Our every tutorial is designed to keep the students in mind so that they can easily understand the concept in an accurate manner.  Our experts keep themselves updated with all the latest changes in the IT field to provide right and helpful study materials.  We are also a reliable source for getting a high quality interview preparation questions and comprehensive tutorials for HP QTP and QC, HP Load Runner and IBM RFT Certification Exam.

You can not only get information, but also share the valuable information with your friends absolutely free of cost. You can download our study materials anytime you want. Our website is very user-friendly and allows you to access your required study materials in a quick manner. To help aspirants in starting a bright career as a software tester is our main goal.

To know more about us and our excellent services, you can call our experts or visit our website http://www.softwaretestinggenius.com anytime you want.

Want QTP and ISTQB Certification? Get Proven Study Material at Software Testing Genius

Do you want to be QTP certified professional? Are you preparing for QTP? Are you looking for the complete guide and proven study material that ensure sure shot success? There is a one stop destination where each and every individual can look forward. Such destination is "Software Testing Genius". Since the opportunities are immense both in national and international market for software testing professional, reap the benefits by creaking the examination for QTP Certification.

We are counted amongst the leading and trusted players in the industry publishing self learn content in line with the current syllabus covered under the examination. We are offering learning material and online training on QTP. We are also providing the free download facility to get our world class study material which is easy to learn and practice. Likewise the QTP, individuals possessing ISTQB Certification also have immense opportunity to grow in the software testing market. We are also offering self learn & practice papers that help in getting the ISTQB Certification.

We are committed to provide help to those want to gain the lucrative opportunities that the Software Testing industry offer today. There is a team of experts working for hours to design and develop the study material available at our website. To help our students to have a better future to be a software tester is the prime concern of the “Software Testing Genius”. The online tutorial we are providing comprises of help through you gain the knowledge and skills essential to face every day challenges in software testing. The online self test examination also available at website, you can prepare yourself to face the real examinations. To avail such industry specific courses, you can contact us at softwaretestinggenius.com.

How does Software Testing Fits in an Organization

Software testing is an activity that is always done in an organization, and it can be anchored in many different ways in an organization. It can in fact be anchored in several places during the course of a development project and the subsequent maintenance period for the product running in production.

Let’s first take a look at the different organizational units involved in Software Testing.

They can, for example, be:

# Product management
# Project management
# Quality assurance department
# Development department
# Development team
# Internal test department or test team
# External Software testing organization
# Internal or internal consultants
# Sales / marketing department
# Support organization
# Internal IT-department
# The customer
# Present and future end users
# Subcontractor(s)
# Process or method department

Distributing the responsibility for all the Software testing activities for the appropriate testing levels and the defined testing roles over organizational units is a three-dimensional jigsaw.

Following guidelines are generally observed in the Software testing organizations:

# Testing requires one or more Software testing teams - We can for example have a test team for component and integration testing, and another team for system testing.

# Test teams are composed of a number of roles - All the roles must be covered for the entire test task for a project, but it could be that the component testing does not require a test environment responsible or a domain expert.

# A role can be filled by one or more people - This depends on the size of the Software testing team. We may for example need one responsible for the test, a number of test designers, and an even greater number of test executors for a large test task.

# One person can fill one or more roles - Again this depends on the size.

# The test designer can for example also be the test executor. Here it is important to remember that less than 25% assignment to a role is as good as zero.

# People may come from different organizations - The developers could be test designers and executors for the component testing; people from an independent Software testing department could fill these roles for system testing; and customer representatives could fill them for acceptance testing.

The distribution of the roles must be done with great care and documented explicitly and precisely in the test plan and/or other relevant plans.

How to Take the Decision-Build or Buy a Software Testing Tool

After the software testing manager has completed his/her evaluation of the commercial market, it can be found that there are no tools that meet the requirements within all constraints. It is worth considering whether it might be better to build their own (or wait for the market to catch up with you).

If you build your own tool:

#It will be most suitable for your own needs;

#You may be able to compensate in the tool itself for a lack of testability in the software under test;

#The software testing tool may be able to assume knowledge of your own applications, thereby reducing the work necessary to implement automated tests;

#It will probably not be very well supported in terms of documentation, help, and training;

#It may suffer from 'image' problems ('something developed by Joe in the next office can't possibly be as good as the tool described in this glossy color brochure from a tool vendor');

#The user interface may leave something to be desired (a software testing tool developed by technical people often considers ease of use to be unimportant).

If you buy a commercially available tool:

# It will probably be considerably cheaper to achieve a given level of features and quality (such as usability) than the cost of developing the software testing tool yourself (the cost of commercial tool development is spread over a large number of users; you have to bear all of that cost yourself if you develop your own);

# It should be well supported in terms of documentation, help, training, etc.

@ It is often seen as 'attractive' - something people want to be involved with;

@You will not entirely avoid building your own even if your basic engine is a commercial tool; you will still need to build support for your test automation regime.

If you do build your own, do not attempt to produce a Software Testing tool on the same scale as the commercial tools. Remember in most cases they have been under development for many years, funded by numerous users in many organizations. Build the smallest and simplest software testing tools that will give you immediate and real benefit. You might start by building some filters to use with your existing comparison tools, for example. You could collect information about any existing tools or utilities that different people or groups in your organization have already developed to meet some need within their own scope; these starting points can often be developed at minimal cost to give more general benefits to the organization.

Important Activities involved in Organizing the Test Procedures

The low-level test cases should now be organized and assembled in test procedures and / or test scripts.

The term “procedure” is mostly used by the software testing engineers when they are prepared for manual test execution, while the term “script” is mostly used for automatically executable procedures.

The degree of detail in the procedures depends on who will be executing the test. They should therefore always be written with the intended audience in mind. Experienced software testing engineers and people with domain knowledge and knowledge about how the system works will need far less details than “ignorant” software testing engineers. What we need to specify here is the actual sequence in which the test cases should be executed.

The documentation of a test procedure must at least include:    

#Unique identification
# Description
# References to high-level test cases and/or to test conditions and/or directly to basis documentation to be covered by the procedure
# An explicit description of the preconditions to be fulfilled before the actual test execution can start
# Included low-level test cases

Intelligent software testing engineers organize their test procedures in such a way that the execution of one test procedure sets up the prerequisites for the following. It must, however, also be possible to execute a test procedure in isolation for the purpose of confirmation testing and regression testing. The prerequisites for a test procedure must therefore always be described explicitly.

Test procedures may be hierarchical, that is “call others,” for example, generic test cases.

The test groups and the specification of their test procedures must be revisited to ensure that they are organized to give a natural flow in the test execution. Remember that the production of the test specification is an iterative process. We need to keep on designing and organizing test cases, test procedures, and test groups until everything falls into place and we think we have achieved the required coverage.

The organization in test procedures could be looked at as the execution schedule. It could be fixed, but it could also be dynamic. For specific purposes, especially for regression testing, some of the test procedures may be selected and reorganized in other execution schedules that fit the specific software testing purpose. A test procedure should not include too many or too few test cases - a maximum of 20 test cases and a minimum of 2 to 4 test cases is a good rule of thumb.

The test procedure may also include facilities for logging the actual execution of the procedure.

There are many ways to lay out the specification of test procedures and test cases. It is a good idea to set up a template in the Software Testing and development organization.

Problems Faced by Software Testing Engineers in implementation of test tools

The implementation of development tools tends to be planned when it should be, at the start of a project. Unfortunately, this is not always the case for software testing tools. This presents some additional problems.

Interfaces to other tools and systems:

The software testing tools may need to work with or interface to other tools that are already in place, such as configuration management, development tools, or project management tools.

The software testing tools will also have to interface to the software under test. There can be significant problems in synchronizing tests with the software, which may or may not be easy to overcome.

Time for the learning curve:

The learning time for a software testing tool seems to be more critical from a psychological point of view than the same learning time for a development tool.

Although a week of training near the end of a project takes the same amount of time as a week of training at the beginning of a project, somehow it seems longer. Actually this is one of the many reasons why a test automation tool should never be introduced to a critical project that is running late.

In a maintenance environment:

It is in maintenance that the greatest benefits can be gained from test automation, by automating regression tests that can then be run every time the system is changed. However, if the starting point is a completely manual test environment, where should testers start to automate?

Benefits can be achieved by automating only a small proportion of the tests - for example, the current regression test bottlenecks or those tests which are the most tedious or error prone to run manually, the bug fixes, or just the most critical core business functions.

Software Testing engineers need to be careful & need not to automate everything - in fact, it can not be. Aim for a gradual build-up of tests over time, with the tests being automated giving the greatest benefit for the least effort.

Over time, testers will become better and better at building automated tests, particularly in a maintenance environment. This should lead to a cycle of continuous improvement in the test automation regime.

Understanding of Improvements in Software Testing Process

Maturity is as important for software development as it is for people. When we are immature we can easily find ourselves in a situation where we lose control and are unable to solve the problems - problems we might even have created ourselves.

The demands on the software testing & development industry are growing as pervasive software thunders ahead. More and more products include software, and both embedded software and pure software products are becoming more and more complex. The potential number of faults in the software is hence increasing and so is the cost of finding and removing them through specialized software testing effort - not least keeping in mind that the cost of fault correction increases by a factor 10 for each phase the faults “survive” in the work products.

The solution to the growing demands is more professional development with focus on the entire product and hence the entire development process. The development needs to be able to stay in control, foresee problems, and prevent them or mitigate them in a mature way. Software development needs to grow up, improve, and thereby become a mature industry - and so does the software testing.

Process improvement is based on the understanding that software development is a process and that processes can be managed, measured, and continuously improved.

An important assumption is that the quality of the software produced using a specific process is closely related to the quality of the process. This does not mean that it is impossible to produce excellent software using a useless procedure - or indeed the other way around - but the probability of producing good software rises significantly with the quality of the process.

The urge for improvement can come from many places both outside and inside the organization, and both from below and above.

#Customers or suppliers may push or even demand proof of maturity and ongoing process improvement directly. More indirectly they may express requirements in terms of quality criteria and time-to-market, whose fulfillment requires a certain maturity in the software testing and development organization.

#within the organization the Software Testing managers are pressed to obey constraints and to provide growth in the organization.

#Finally employees may well be fed up with constant firefighting and impossible deadlines requiring them to work overtime and cut corners.

Design of Software Testing Strategy to Suit Project Related Factors

A good software testing strategy is shaped not only by product risks, but also by factors within the project. Technical experts with advanced level ISTQB certification prescribe following project-based strategic principles:

1) We should not lose our bugs in the cracks between the software testing engineers. Unless we apply diverse half measures or overlapping software testing assignments, we face a real risk of not testing something because it lies on the boundary between the assignments of two testers (or teams).

2) We should frequently test what we have been asked to test. We should remember that we are testing on behalf of many clients. What do they think we should test? We should find out and make sure that we are doing at least some of it.

3) Occasionally we should test what we are asked not to test. Sometimes we are asked not to test certain parts of the product. This can be a delicate matter, and it is difficult to tell as to what to do. However, sometimes the things we are asked not to test are the things that need it most.

4) We should test the confusion and conflict. Wherever there is confusion and conflict, bugs will certainly come. If the programmer seems not quite sure what a feature is supposed to do, we should test it. If he is new to the technology, we should test it. If two programmers are building units that interface with each other, we should test the interface. This way we will not be disappointed.

5) We should not beat a dead feature. When it is clear that a feature seems full of bugs, we should not continue to test it unless we check in with the developer. It may be a bad build or a bad configuration. Also, if a component is so bad that it is going to be replaced rather than revised, any bugs we find will be summarily closed, so we should not bother software testing.

6) More change means more Software Testing. Theoretically, the smallest change in the product can create large and non-local effects. That means any change can potentially invalidate all the software testing we have ever done on the product. In reality, most changes have a fairly localized effect. However, it is certainly true that we must follow the changes with our software testing. The more change in the product, the more software testing we must do. This becomes a big deal in the end game of a project.

These principles have been pointed out in the syllabus for ISTQB Certification CTFL as well.

Importance of Robustness Testing for Reliability of software Product

Fault tolerance or robustness is the ability of the software product to maintain a specified level of performance in the presence of software defects or infringement of a specified interface.

Generally the software testing experts focus on the following important aspects of the software product:

# Containment of defects to specified parts of the system

# Reactions to failures of a given severity

# Self-monitoring of the operations and self-identification of defects

# Ability to allow specified work to continue after a failure of specified severity for specified parts of the system under specified conditions

# Loss of specified operations (functionality requirement or set of functionality requirements) in case of failure of specified severities in specified periods of time for specified parts of the system

# Loss of specified data in case of failure of specified severities in specified periods of time for specified parts of the system

The failures to consider in Software testing aimed to check the technical robustness are those forced on the product from external sources. Failures due to internal defects should be handled in the functional testing.

Failures from external sources could, for example, be caused by lack of external storage capacity, external data storage not found, external services not available, or lack of memory.

Software testing aimed to robustness aspect can, like the other technical tests, start at the requirements level, with testers reviewing robustness requirements.

Even more important is review of design. Software testing engineers can make the design more or less defensive, that is more or less robust to external circumstances. A simple, though often overlooked way to make systems more robust is to check the return code of all system routine calls and take action in the code when system call is unsuccessful.

Lack of memory may be due to memory leaks. Software testing engineers generally adopt the technique of dynamic analysis to detect the memory leaks if any, for example, during component testing. Software testing aimed to test the robustness in system testing and/or acceptance testing may require the use of simulators or other tools to expose the product to external problems otherwise difficult to produce.

Introduction to Software Testing Tools & Test Automations

The purpose of using software testing tools for testing is to get as many as possible of the noncreative, repetitive, and boring parts of the test activities automated. The purpose is also to exploit the possibility of software testing tools for storing and arranging large amounts of data.

There are a huge number of software testing tools on the market, and it is growing fast. Every software testing tool automates some testing activities to a certain degree. No single tool automates everything completely. But there are software testing tools for all testing activities, even though most testers think about test execution tools when test automation is mentioned.

Test automation is not an easy task. A company can be more or less ready for test automation. It requires a certain level of maturity to be able to use tools efficiently. Tools do not provide more maturity; they should be implemented to support the existing maturity.

It also requires a certain amount of courage to engage in test automation, both courage to choose and to refuse. It is important to select tools with great care so that they don’t end up just as “shelfware’ lying as a decoration piece.

It may be difficult to choose, but that is peanuts compared to getting a Software Testing tool introduced in an organization. And keeping it running efficiently is perhaps even more difficult.

In a professional organization it is important to treat the investment in software testing tools as the serious decision it is. Tools are usually expensive, and even if they are not expensive to buy, they are expensive to implement and maintain in the organization.

The crux of Software Testing can be understood by V-model

It is a general conception that the software testing is something, which needs to be done after the software code has been written. It is quite obvious that we can not test something, which does not exist. Thus we can assume that testing is simply execution of set of pre planned tests. For that we essentially need software that is actually working. However fact remains that testing activities include much more than simple execution of the tests. Let us see as what it is.

The V-model of software development illustrates when software testing activities should take place. The V-model shows that each software development activity has a corresponding testing activity. The tests at each level exercise the corresponding development activity. The same principles apply no matter what software life cycle model is used. For example, Rapid Application Development (RAD) is a series of small Vs.

The simplified V-model in following figure shows four levels of software development and software testing activity. Different organizations may have different names for each stage; it is important that each stage on the left has a partner on the right, whatever each is called.

The most important factor for successful application of the V-model is the issue of when the test cases are designed. The test design activity always finds defects in whatever the tests are designed against. For example, designing acceptance test cases will find defects in the requirements, designing system test cases will find defects in the functional specification, designing integration test cases will find defects in the design, and designing unit test cases will find defects in the code. If test design is left until the last possible moment, these defects will only be found immediately before those tests would be run by the software testing engineers, when it is more expensive to fix them.

Test design does not have to wait until just before tests are run; it can be done at any time after the information which those tests are based on becomes available. Then the effect of finding defects is actually beneficial rather than destructive, because the defects can be corrected before they are propagated.

Of course, the tests cannot be run by the testing engineers until the software has been written, but they can be written early. The tests are actually run in the reverse order to their writing, e.g. unit tests are written last but are run first by the Software Testing engineers.

Single Destination for Those Aspirants Who Wants To Become a Master of Software Testing

Software testing is also very important in order to design the software that can meet the full fledged purpose and the requirement of software. It reduces the possibility of the problems that can arise as a fatal or an uncontrollable issue in the later stages. Thus, it is important for a tester to be updated with the latest technology so that software developed with updated technology can be tested.





If you are also associated with the testing field of various kinds of software or if you want to groom your career in software testing then SOFTWARE TESTING GENIUS can help you. You can follow us to know the latest ins and outs in the field of software testing technology. The sole motive of our services is to help the people in polishing their skills of software testing and getting quality assurance.

Our website provides a platform to the aspirants so that they can explore their knowledge on Software Testing under one roof. This way they do not have to hunt for their desired information or knowledge by digging various websites. The information and lessons given on our website are absolutely free for the users.

We have also provided the support materials and really valuable tips that can aid in getting success in ISTQB Certification for foundation as well as Advanced level. You can also find various updated unique questions that are really helpful in preparing for various certification exams. Log on to our website, to enhance your knowledge of software testing.

Get complete guidance for software testing and related certifications at one destination point

Online services have served a lot to the people in every field whether it is a student or professional or any home maker. People can get in touch with anything they want just by sitting at a chair under one roof.  One can also gain knowledge and a guidance regarding various topics which can help them to boost their career. This all has only become possible with the help of advancement in the field of IT.

I was searching from a online service that can give complete guidance about some IT related topics. Since, I was working, so, I was unable to quit my job and then joining some institute just to learn those technical things. So, I decided that I will study with the help of SOFTWARE TESTING GENIUS, as I had found it during my search on the internet.

It was a website that provides complete guidance about the different important things all related to Software Testing. I found that website the perfect one for me as all the contents available there was a complete package through which one can become master of a specific topic. I started following their website on the daily basis after my office hours.

I decided that I will learn QTP on my own effort & get QTP Certification so as to get some good job opportunity in automation testing. I prepared myself and started following skill test given on their website and that skill test really helped me in achieving my goal. To get complete assistance for software testing, visit their website.