Benefits of Using Correct Vision During Product Development

6/6 vision is not bad. But having 6/6 and not having a capability to look beyond is something that degrades the value of even the correction vision. It is like something valuable that you possess but are not able to get the best out of it, ever! Planting is one time activity, but it is watering and caring that helps in growing the plant. That does not mean that the later could have happened without former activity. It is sequential having both the activities in prime important category.

Testers do have a different blend of vision. They are bound to develop that extra edge of visioning through which they are able to look at the product more from a customer perspective rather than the vendor or product developer perspective. A tester is required to virtually slip into the shoe of end user so as to assess the capabilities and functionality of a product that is going to be delivered to them after passing through QC. Technically and functionally, a product must be able to cater to customer requirements to make business functions smoother, trouble free and less time consuming with higher level of accuracy.

That is what is about a product should be. One should understand, the earlier the better, that which situation is more important in business - merely selling the product by blindfolding or faking the customer or giving a state of the art product to the customer which in turn incurs manifold business through word of mouth and otherwise. Usually a good product even if sold at a lesser margins give greater benefits in longer term.

Five Good Blogs On Testing

Here is a segregated list of my blogs on testing mainly for the purpose of people enthusiast in testing, testers, QA, QC, bug management; and software Quality:

What stops a Good Programmer from being a Good Tester? – 8 Reasons

Knock! Knock! – it is tester here!

Linear Approach of Cost Estimation of Bug fixing for various Software Projects

Progressive Software Testing Approach by acquiring Soft Skills - Step by Step

BVT or BVA – Boundary Value Testing or Analysis

A Checklist Is Must To Ensure Complete Coverage Of Software Testing

The post ‘Twenty ways to ensure complete coverage of software testing’ can be treated as a checklist for ensuring complete coverage of testing of any software. It talks about some basic fundamental but critical and important steps to take care of for the purpose.

Purpose of testing is not only to ensure reporting of bugs in a proper manner, complete coverage of product vertically and horizontally both, and ensuring that critical bugs are taken care of. Test team must also ensure timely reporting back of bugs fixed from the development team so that they can one more go over the complete product to verify that all bugs have been fixed – properly.

Test team while ensuring fixing of bugs through their verification cycle must also ensure that while re-writing or varying the code, development team has not developed any new bugs during the course of their action.

There could be various ways to ensure complete coverage of product, proper identification and reporting of bug; and validation of bugs fixed etc. depending on level, automation, and methodology adopted but checklist can become handy in any case.

Why Software Testing And Importance

‘How Software Testing Took Birth’ would be an interesting read if you have not read it earlier. Give it a try to this small article that provides and insight to some very basic fundamental reasons about necessity of testing of software.

There would have been a time many years back when there was no concept of testing altogether. The software would have been produced and given on as is where is basis without any guarantee of its behavior or results produced by it.

Gradually a need would have arisen from both ends – customer and vendor to maintain a decorum, sanctity and reputation of software producer and software being produced.

Probablity in early days when software product cocept had started, software development would have been more of an experimental and adventure case rather than a serious business product building concept. And gradually when reliability on software increased, its necessity of providing a neat bug free product also would have arisen.

Test Environment Versus Live Environment

It is not actually Test Environment Detail Template. It should be termed as Test Environment Template. Let us first understand some terms first as below.

Test Environment: An environment in terms of hardware (server, end user, networking, LAN, WAN), software (client app, browsers, any other) and security environment (firewalls, antivirus, etc.) is decided to be as close to live environment so that no misbehave goes unnoticed during test phase.

Real or Production Environment: A real time scenario when product (software) gets launched at customer site (live environment) after completing all development and testing phases. In this environment, it is the end user that starts working on software in real for business benefits.

A real environment scenario with complete specifications gets frozen right in the beginning of development process (during high level design preferably and may be some part during low level design). Though some changes might occur in the final specs during development or implementation phase but those can’t be major in nature. Otherwise the whole project gets shattered.

A test environment should be as close to live/ production/ real environment in all aspects so that this environment is as good as a simulated environment as it is going to be in reality. Though it may not be possible to create a 100% same environment as it is going to be in live conditions because the same environment may cause a big amount of money and lot of efforts which may practically not be possible.

The template of test environment should be prepared at micro level covering all requirements of live environment with three main sections – hardware, software and security. A parallel column must be there to record deviations and next to that should be a column describing software behaviour and its reasons.

Five Tips For Bypassing Testing Of Product

1. Showstopper: Product manager always has the perception that the development team wants the progress of work whereas QC or testing team jams the progress. They even try to project in the way of showing development team sitting idle when the product is lying with testing team for finding out bugs in the product. It is reflected as if QC is not an enhancer but showstoppers.

2. Fault Finder: One of the reasons of not giving the product to QC for testing and emphasizing on an in-department testing is that QC or testing team is blamed for unnecessarily finding faults in the product just for the sake of highlighting the lacking in the product whereas it is claimed that the product is built perfectly and working fine.

3. Business Knowledge: One reason of bypassing QC team in Product development lifecycle is putting wrong perception in management’s mind that the testers lack business knowledge. For that sake even sometimes wrong, incomplete or ambiguous business process documents are produced to testing team so that they are not able to understand business properly and the test report lack the crucial business process bug reporting.

4. Process: Excellent process even in place are not adhered to sometimes in wake of fake reasons of lack of time, customer pressure, more time required for development and so on thereby giving short time to test teams for testing the product.

5. Management: Management if do not balance development and quality team equally then the product or the organizations do fall in trouble at a later stage.

Hide And Seek Between Development And Quality Teams

There is always a hide and seek game between Product Manager and QC Manager when a product is being built. Project Manager, Management and Customer on one hand stress on complete involvement of testing team during product building. On the other hand product manager keeps playing tricks to bypass testing by a separate team outside his control.

This could be due to a fear factor in him, or lack of confidence on his product. For the sake of not displaying his these weak points to other teams involved in Product Lifecycle, a Product Manager tries presenting his points in other fashion to convince management or other managers for not giving the product for testing or providing the least duration to testers. This satisfies him for the reason that least exhaustive testing by testers will lead to least number of bugs.

But by doing this he also is doing a inappropriate deed for his product and in turn for the organization. Usually Test team is taken as an opposing factor by the product manager. In a way while the development of the product; he gets emotionally attached to his product. Feeling of getting it scrutinized by an outsider (someone not from his team) makes him feel as if someone is intentionally going to find faults in him or his product. He also feels that the higher is the number of bugs,

Five Benefits of Software Testing On Cloud

In a normal scenario testing of a product is done within the organization by the quality/ test team members. Lately as cloud computing came into the picture, a new concept of testing on cloud has emerged, though not many companies have jumped into it.

Testing on cloud carried quite a number of benefits in terms of cost and resources. It is something like “service on demand” or “testing on demand”. The cost of hardware, software, tools, tester etc. is charged on usage basis.

Some of the key benefits that can be drawn from this are:

1. Tool License Costs: You don’t need to invest in tool license. You have varied option of selection of choosing tool of your choice depending on product to be tested. The service provider is supposed to ensure that latest version of the tool is provided. So instead of paying a hefty amount for buying a tool, keeping track of updating it with latest patches and fixes, getting bothered about the new release and then depending on it for all your product range; you just need to pay-as-you-use basis.

2. Infrastructure Costs: To perform testing, to load tool and to provide a substantial hardware/ infrastructure platform in-house; you can go straightaway for the cloud service provider.

3. Flexibility and Wide Range: You have the flexibility of using only when you really require. And you have an option of choosing the right tool for right product.

4. No Setup and Procurement Time Wastage: You can bypass to invest your time in procurement and setup process. straightaway select the cloud vendor, and get the setup already up and running to start testing instantly.

5. Expertise: You don’t need to hire tool experts.

Project Management and Project Defects

A study shows that incomplete, improper or imperfect requirements collection during business and requirement study leads to 70% defects in the final product. The shortfalls in the software product delivered to customer affect its business process not only initially but for long. As long as, till the shortfalls are identified and fixed.

Each shortfall accounts for a risk. Each risk calls for mitigation.

Usually customers either are not able to identify the shortfalls completely during the implementation phase; or the incomplete identification does not lead to the proper fixing plan. Some fixes may require a major overhaul of the product. Gradually, customer compromises with the shortcomings of the software and starts using it as it is. Sometimes such a compromise may even lead to a change in the business scenario/ process in practice, which no customer would like to.

Incomplete requirements have a long lasting impact on the product to be developed and leads to a big scope of loopholes in the product segment as and when it gets developed. The entire teams get into wrong loop without even realizing the wrong direction being taken by them. The quality team, for instance, may have done a wonderful job in testing the product by reporting complete range of bugs. But tragedy is that the testing is based on wrong base of requirements thereby putting a big question mark on the report submitted.

At a later stage when awakening happens regarding the requirements, it might be too late to revert back or a big chunk of the product may require complete overhauling. Sometimes it may require even scrapping of what has been developed and the entire team may have to build entirely a new product to cater to the later understood business needs. This will lead to complete product lifecycle stages of development, testing etc.

Dilemma of a Tester

A tester’s prime task after testing a product is to describe the bug. The development team while receiving a test report of a product from tester expects a detailed bug report. The report should be presented in such a way that is easily understood by developers. The point of confusion most of the time is a tester while reporting a bug, if know the best possible solution to be incorporated in the product. Should he report it as a part of his bug report or keep silent about it and let the developer explore the solution on his own.

There are two aspects to it. There is already a feeling in development team that whatever they produce goes to test team for finding bugs or any other inconsistency. This does not give a comfortable feeling to development team. On top of it if a tester tries suggesting a suitable solution for fixing a bug, the developer might get hurt.

This might give him a feeling that on one hand the tester is exploiting the code written by him to find out bugs. On the other the tester confidently suggesting a suitable technical solution to fix a bug to a developer, might give him a feeling that his knowledge is being challenged. This might be taken by the developer as a two way attack.

The tester has to be quite cautious in suggesting a solution for fixing a bug reported by him.