Tag: QA


Why You Need Software Testing

July 5, 2017

Software

Comments Off on Why You Need Software Testing


Introduction and Importance

Software development companies dedicate a substantial amount of resources and manpower for the development of applications according to requirements specified by enterprises or individuals. However, subsequent to development of such applications/software, companies are required to ensure that such software/applications perform in accordance with the client’s requirements. To ensure that any and all bugs in the software are identified prior to the deployment, various testing procedures are implemented by the IT industry. The importance of this is directly related to the ability of software to measure up to its potential. If the new software is unable to perform the task it was designed for, the client might face severe losses due to stoppage of work and also adversely affect the business of the software development company. The scope of these procedures is to facilitate identification of a problem in the software, fixing of such problems is not within in the scope of software testing. Some of the leading methodologies implemented by companies in the IT industry include General, Load, Functional and Regression Testing.

General Testing

This refers to the general tests carried out on software/applications to ensure the functionality of newly developed software. Some of the common tests included as part of standard Quality Assurance procedures are web performance and usability testing. The web performance testing procedure is mostly engaged in evaluating the online performance of a web-based software application or a website. Usability testing is a mainly subjective approach, which ensures that the software is capable of being utilized effectively in a given set of circumstances. The purpose is to identify the general operating capability of the software/application being tested and to help developers determine some of the areas of improvement for the software. A software development company usually performs general testing of software/applications along with other more advanced methods to ensure that the software conforms to the pre-defined operational capabilities specified by the client/user group.

Load Testing

The load testing procedure simulates operating conditions of the software/application during periods of higher/normal load to gauge the effect of such changes on the functioning of the software/application. This is not the same as stress testing, because load testing checks the operational capabilities in case of both normal load and high load conditions, while stress testing attempts to induce errors in normal operations by using increased system load. This is considered to be a type of non-functional testing, which is undertaken by software development companies to gauge the multi-user support capabilities of the application.

As a commonly employed practice in the software industry, its specific goals are widely disputed and the term is often utilized in conjunctions with volume, reliability, software performance and concurrency testing. By using load testing, developers can attempt to determine the reason for slow performance of software. The common reasons for such slow response commonly include load balancing between multiple servers, client-side processing, network congestion/latency, available database service and/or bugs in the application server(s) or software. The use of load testing is recommended for software/applications, which are subjected to SLA (service level agreement) for ensuring that the software is capable of supporting multiple users. As the procedure simulates an increase in system load by using multiple virtual users, various software are currently available to carry out load testing. Some of the leading load-testing tools used by developers globally are IBM Rational Performance Tester, Apache JMeter, LoadRunner etc. Additionally, a load testing tool commonly favored by software testing companies in India is available as part of the Visual Studio Ultimate Edition of Microsoft.

Functional Testing

This type of testing is a type of black-box testing based on the specifications of the software components being tested. The functions of specific components of the software are feeding inputs and checking the output thus obtained. In functional testing, the internal structure of the program is seldom considered hence, it is classified as a type of black-box testing. The key steps involved in functional testing include identification of functions, which the software is expected to perform, creation of input data according to specifications of the identified functions, determining output based on the specifications of those functions, executing the test scenario followed by comparison of the obtained output vs. the expected output. Functional testing is not the same as system testing as system testing involves validation of a program in comparison to the published system or user requirements, whereas, functional testing is carried out by checking a program with respect to established specifications and available design documents for the software/applications.

Regression Testing

The regression testing refers to any type of software testing, which attempts to identify bugs, which are present in either the functional or the non-functional areas of a system subsequent to making modifications such as configuration and patch changes. The key function of regression testing is to ensure that the use of a patch or upgrade does not lead to the introduction of a new bug into the existing system. Additionally, regression testing helps ensure that the changes in one section of the software do not induce changes in another part of the software’s code. Some of the commonly applied regression testing methods include the use of earlier tests to check for alterations in program operation and the search of any previously fixed bugs, which had re-emerged subsequent to introduction of the new code. Fixed bugs in software often re-emerge and regression testing is one of the leading methods to ensure that such re-emergence is identified and easily controlled before any lasting damage occurs. Software development companies repeatedly perform regression testing of software/applications after any change in coding such as use of patches etc. to ensure that the functionality of the application is unimpaired. Such repetitive testing is usually automated by using an external tool such as Bamboo, TeamCity, Jenkins, Hudson, Tinderbox or BuildBot. This type of testing is generally performed by the QA team in case of leading software development companies, however, smaller companies are often engaged in outsourcing such services to companies specializing in the field of software QA and testing.

What’s Next?

As new technologies emerge, more testing procedures are being developed and implemented by organizations all over the world to ensure that new software perform according to their requirements and specifications even when stress or when additional functionality is introduced into the software. The emerging testing solutions, which are powered by new technology, are designed to reduce the time and resources required for testing in order to streamline the quality control / quality assurance services associated with software development. Some additional types of testing, which are currently used in the software industry are white box testing, system testing, non-functional testing, acceptance testing and integration testing. Each of these testing was developed to identify and resolve application/software limitations in a specific set of conditions; hence they are useful for software testing carried out in case of specific quality assurance and testing procedures.

 


The Process Of Software Development

June 20, 2017

Software

Comments Off on The Process Of Software Development


Many business people don’t fully understand the complexity of a software development process. It’s natural, since specialized books about development are read by developers and other IT people, and many others might still be referring to a software project as ”coding” or ”writing”. With better luck one might add ‘designing’ and ‘testing’. Quite inaccurate.

One can think of several metaphorical comparisons to describe software development, such as writing a book or building a house. Some of them are a good light in the dark, some are rather misleading. And while many people may argue whether creating software is an art, a science, or a precisely elaborated process, we’d leave that choice to someone else. It cannot be described sparsely. But we’ll try to give some descriptions and comparisons in a compact and clear way.

Do We ”Write” Software?

One of the common but rather vague things is comparing creating software with writing. Writing code, writing a book, and so on. You can start writing a book without a plan and go with the flow; with custom software development you cannot, unless developers do a rather small piece of software on their own – and for themselves. Moreover, an outsourced software project never starts with writing code.

Books and software may both have strict deadlines. But once a book is published, what’s written is written; rewriting is not an option. But software keeps being under constant improvement with new versions being released – it’s a natural thing. It’s almost impossible to get every need of your end user, catch up with business and technological changes once and for a lifetime. Books aren’t that dependent on changes; software is. But that’s good: your software, unlike a book, can’t become just another mediocre thing on the market, can’t become irrelevant and outdated. The processes are absolutely different: we prefer using the words ”create” or ”build” software rather than ”write”.

Do We ”Grow” Software?

”Growing” software on a good basis and a good set of documentation is possible to a certain extent. Like with writing, it’s not the best description one can suggest. It partially gets the incremental, agile nature of making and maintaining relevant software. But while ”growing”, the product is rarely tasty until it’s ripe, and the owner has to wait awhile.

The difference is, in software development there are different stages of being ”ripe”. Startups usually demand rolling a minimum viable software product on the market, getting feedback and making corrections and improvements. Each version is more ”ripe” than its predecessor, and it has to be ”watered” by support and maintenance, kept fresh amidst all the business and technological changes.

Do We ”Build” Software?

This one is considered by many specialists the closest way to describe software development, and we can agree with that. Construction works show the huge importance of careful planning, preparing, guiding the work, and performing it. The limits of software depend on how its architecture is constructed. The amount of works doesn’t grow gradually, since every building is different, and requires different approach. There can be a hospital, an office building, a school or a barn, and same physical size doesn’t mean equal amount of labour. Something is done with concrete, something can be done with wood and nails, and the latter doesn’t work well with complex and valuable software for mobile startups and other businesses.

– Everything depends on the kind of a building you need. You need to figure out the problem the software will solve, and conduct the necessary preparations, do market research, gather info, etc. The more complex your software is, the more resources must be spent on planning. Bad planning – and the whole app fails, falls like a house of cards by the first gust of a wind.

– Then you and your chief architect (project manager) can proceed to design that perfectly combines functional requirements and interface, resulting in proper user experience. Sure you want those who will work or live in the building to be fully satisfied with it. Same thing with software. One more good thing, once the design is approved, it’s way easier to give more precise estimations for the remainder of the construction (development) works.

– When furnishing a house, you needn’t building things you can buy: household appliances and furniture. It’s much cheaper and way faster. Same with software: if your software development team is experienced, it will use all the available resources to stay away from writing needless basic things: there are lots of software toolkits, frameworks, classes, and libraries for that, each for a particular case. And if the team means business, they will easily find tools and technologies that will get your tasks done as fast as possible. Custom pieces of furniture take more time and efforts, but in most cases there are already existing pre-built ways to save your time and money without compromising security and efficiency of your software.

– There will always be changes in functional requirements. Again, changes can painlessly happen within the planned architecture. Here we once more emphasize the importance of preparations – although this topic is worthy of a separate article. And we cannot go anywhere without mentioning quality assurance, which constantly checks different aspects of how the software works. What’s more – even a minor change involves testing, so that’s not the place to cut the costs (in fact, QA usually takes about 30% of the whole development time).

– Optimization of software (inner walls of a building) is limited to the approved architecture, and here main expenses are all about labour, not materials. But what you receive in the end is better software and satisfied users. Meanwhile users speak their minds on what they would like the apartments to look – and one should never neglect these opinions.

– One more thing worth noting – a good architect (or a good creative expert in software development) is always ready to consult you on things that should be solved immediately, and what can be left for later without breaking your plans or the quality of your software. You are most likely to not know the subtleties of the technical side – so leave making suggestions and explanations to your team. Unless you are an experienced IT person and you needn’t reading this article to get these insights.

As you can see, the last example is really the closest, and the list of similarities can be continued forever. But the ones we presented here should be enough to understand the process of software development, which is impossible without patience, expertise of the team, and mutual understanding.