There is now statistical evidence for the fact that more number of software development teams are deploying software faster, as of 2018. The increasing pace of deployment owes a lot to technological advancements and best practices, which sped up everything from design to quality assurance and testing. Bugs are found and fixed faster now, and the feedback loop shortened. When it comes to testing, the prime factor that contributed to such growth in testing speed and efficiency is test automation.

Many major forecasts indicate that the test automation market will be soaring high in the coming years, hitting close to US $110 billion by 2025.

It’s not that automation simply makes testing hassle-free. It demands a lot of investment and great care in its implementation. This is why many organizations are reluctant to automate their software testing processes. Many others simply can’t ensure ROI if they go ahead with test automation initiatives.

The success of test automation depends on how the organization implements it, and a few other factors. However, test automation initiatives that become successful do have a few things in common. They could very well be the key to ensuring that test automation is implemented the right way for desired results.

Here are a few such factors that influence the success of test automation.
 

Make sure testing is aligned with business goals

 
Typically, the business goals of the software would be defined before the development itself begins. Once the functional and non-functional requirements of the software are addressed and discussed with the development team, a testing should be developed which aligns with the software’s business goals. Testers should come with a design that ensures thorough and detailed test coverage of the codes that implement the requirements of the product under development.
 

‘What to test’ is as important as ‘how to test’

 
Test automation is likely to fail if the organization simply focuses on achieving 100% automation. The success of automation also depends on where it’s applied. Testers should identify the right candidates for automation first. The common way to start is to identify repetitive tests in the cycle and validate the functionalities across the development environment.
 

Utilize QA assets wisely

 
Important QA assets include test cases, test data, the infrastructure etc. in addition to the testers themselves, the automation engineers, and even the product owners. When organizations decide to implement test automation, they tend to get a wrong idea that manual testers will no longer be relevant in such environments. Test automation doesn’t solve everything and cannot automate every tests there is.

Automated scripts have limitations when it comes to understanding issues and patterns at a contextual level. It can hasten certain testing processes but not all. Certain tests can only be done by humans. The point is that organizations shouldn’t simply consider a QA asset irrelevant just because they are confident that their automated testing strategy would succeed. Each asset can come of use depending on the context. The key to successful test automation is to pay attention to and utilize each of these assets wisely.
 

Integration with development

 
Test automation is meant to primarily hasten development and deployment, increase code coverage, and keep timeline overruns under control. But testing, be it automated or not, cannot achieve this in a conventional waterfall model. Testing delivers the best results when it is at the core of project development. This ensures that the final product meets the expectations and is delivered on time.
 

Conclusion

 
As more and more software development companies make the shift to a DevOps and Agile culture, it’s important to think ahead, devise, and implement an efficient test automation strategy before the development begins. Ultimately it’s up to the testing team to coordinate and support the implementation of automation without compromising the testing code’s integrity and quality which can adversely affect the outcome of the automation initiative.

Written by: Kiran

While developing software, every team will have to determine that point of time where performance testing of the product will benefit them most. The challenge here is to figure out where software testing should begin – from the beginning of the project, parallel to development or at the end of development?

Obviously, this depends on the software development methodology adopted by the development company. The methodology also applies to testing. Generally, developers either go for the Agile methodology or the Waterfall approach.

In the Agile approach, testing especially performance testing is started at the beginning of the development process and goes along with the development till the end. The waterfall approach is where testing is done only at the end after development.

Let’s look into both testing approaches in detail.
 

Waterfall Methodology – Pros & Cons

 
Though Agile has taken over the modern software development sector, many companies still practice the Waterfall model. As mentioned before, performance testing is done only at the end of the development process in the waterfall approach.

Pros

  • Easier to plan the testing and allocate resources since it’s done only at the end of development.
  • Typically uses test environments that share many similarities with the production environment.
  • Testing can focus on specific characteristics of the product based on priority.

Cons

  • Testing environment being similar to that of production makes it challenging to procure infrastructure exclusively for testing purposes.
  • Might demand architectural changes toward the end of development as testing also occurs at the end, which would in turn increase cost.
  • The team and the client would have to wait till the end to get assurance on performance which is also risky. Should the team identify major bugs in the system, they’d have to fix it before release which could essentially lead to failure in release by the deadline.

 

Agile Methodology – Pros & Cons

 
There is a reason why Agile development services enjoy great demand today. However, along with all its benefits, Agile does come with a fair share of challenges. In an Agile approach, testing begins right from the beginning of development with unit testing. Implementing continuous integration into development makes the entire process much faster, transforming simple performance testing to ‘performance engineering’.

Pros

  • Reduced risk
  • Early, constant feedback.
  • Continuous improvement, where testing finds bugs that are rectified in successive sprints.
  • Facilitates continuous integration.

Cons

  • Requires more effort in maintaining scripts and handling automation.
  • Automating less or more can lead to complications. The best practice is to automate critical test cases at the GUI level.
  • More testing effort where the team has to test components individually, and then test them working together to achieve optimal results.

 

Making the choice

 
Choosing the development approach requires us to consider the desired outcome and the project’s deadline. There are other important factors as well including the people who are going to work on the project, the technology that’s going to be leveraged, the development and testing tools that would be used, the processes involved etc.
 

Testing for Waterfall & Agile

 
Testing processes generally include test design, test automation, test execution, and test measurement.

For Waterfall

Software testing in waterfall development requires the tester to execute a load simulation at the end. With the simulation, the tester can:

  • Verify whether existing system supports a certain load
  • Give proof to the client as to how the system meets a predetermined standard for performance.
  • Check if the application requires some tweaking for the context where it will run.

For Agile

Performance testing is essentially ‘performance engineering’ in Agile, which reduces both cost and risks. It allows the team to understand the concept of performance engineering while executing it throughout the development cycle.
 

Conclusion

 
At the end of the day, we can’t choose one testing approach over the other though this isn’t the case when it comes to development. Early performance testing and load simulation for acceptance testing are both important, and needs to be part of the testing strategy depending on how far the development has progressed.

This blog explores the two most commonly practiced testing approaches – Waterfall and Agile, and where performance testing fits in both.

Making the choice between Waterfall and Agile performance testing is not easy. This blog shares some insights on both approaches and where performance testing fits in them.

Written by: Kiran

In the last couple of years, software development underwent many evolutions in terms of new methodologies, approaches, development tools, and even the mindset of the people using the tools. Due to new efficient approaches to development and users’ uncompromising expectations to quality assurance, testing also gained almost equal importance as development.

When it comes to software testing, there has been a significant increase in the number and variety of testing tools with multiple features and functionalities, which include both open source and proprietary tools. Due to the change, or rather ‘advancements’, in testing trends, testers are now considered as information brokers. They also have to be updated on emerging as well as modern mainstream technologies to design effective test strategies.

All of these facts emphasize the influence of technologies on various industries, and the influence will persist as long as there are advancements in technologies. If you look at a big-picture view, you would notice new technologies gradually shaping up the future of software testing. Here are 4 such technologies that will impact software testing and transform it in the near future.
 

Artificial Intelligence

 
AI, being the new buzzword, is at the top of almost every list of influential modern-day technologies. Thanks to AI, self-driving cars and intelligent digital home assistants are not sci-fi concepts anymore. They are today’s reality. AI’s influence spread across several sectors including finance, health care, travel & transport, and, of course, software testing.

However, as of now, the AI in software testing is still in its infancy. Only a very few tools that use AI/Machine Learning technologies are considered reliable for authoring and executing functional testing, end-to-end testing, and regression testing. AI finds its use primarily in test automation associated with UI. The algorithm evolves by learning from the test cases created by users, eventually becoming capable of creating test cases on its own adhering to specific preset conditions. AI algorithms can also track changes in the code made by developers which may affect test cases that were already performed prior to the changes. This means the tester won’t have to spend maintenance time on test scripts.
 

DevOps

 
The DevOps approach promoted collaboration between the software development and operations team, thus ensuring constant automation and monitoring throughout the software development lifecycle (SDLC). DevOps is likely to bring major changes to software testing in the coming days.

For instance, DevOps may require the QA tasks to be aligned to ensure a hassle-free Continuous Integration/Continuous Delivery cycle. We can also expect QA environments to be standardized in a DevOps ecosystem. However, for DevOps to truly make a difference in testing, automation is the key. Automation and DevOps are quite dependent on each other as one cannot be effective without the other. Considering that fact, we can safely assume that automation will have great value in the future of software testing, more than it has now.
 

IoT

 
Another technology that shares the same spotlight as AI, IoT at present is considered to be very promising. The advent of smart wearables and the concept of smart homes and connected devices give IoT a lot of hype, garnering it major investments from tech behemoths. However, behind the flashy concept lies the sophisticated reality of multiple communications and integrations taking place every second.

The data that IoT devices share are transmitted through the cloud seamlessly in real-time across multiple connected devices and apps. The notification should reach the right user at the right time as well. Testing such sophisticated functionalities can be very challenging for testers. Because IoT introduces such complexity, it’s expected that software testing will adapt to meet the challenges with further evolutions that focus more on integration testing.
 

QAaaS

 
QA as a Service is not anything new, and has been around for the past couple of years, enabling companies (medium-large sized businesses) to meet their software testing needs effectively. Not all companies that provide enterprise application services offer QAaaS solutions. But those that do can make various aspects of the testing process much easier.

QAaaS providers offer in-depth test reporting features with logs, screenshots, and even video logs. They also facilitate easier integration with Continuous Integration systems and provide automation tools to reduce coding time. QAaaS providers can also handle the maintenance of servers that run automated tests so that team members would be able to focus more on critical testing tasks.

Owing to the many benefits of the service, QAaaS could be standardized very soon. The service is not yet accessible to businesses of all sizes. However, we can expect it to be much more affordable and refined with better offerings in the near future.
 

Conclusion

 
Software testing is expected to get big changes starting this year. It’s just a matter of time as other technologies advance to being more affordable and accessible to all kinds of businesses. Even under such positive conditions, the mindset of the testers need to change as well, in order to accept and adapt to using better technologies to ensure quality.

Image Designed by Freepik

Written by: Suraj Jayaram

Complete testing of a software or mobile app ensures that it serves the purpose it was built for, while meeting all requirements without compromising quality or functionality. For this, testers perform a variety of feasible tests based on pre-determined testing strategies and the availability of resources. The entire software testing process provides an overview of the quality of the software and its risk of failure to end-users and stakeholders.

Among the many types of testing employed, black box and white box testing are typically the most common in almost all software development projects. Let’s explore what it is that both these testing types are for, and their key differences.
 

Black box testing

 
Testers perform black box testing when they don’t have any information about how the software works internally. The high level testing technique tests the behavior of the software when it’s subjected to various conditions. The tests are conducted from an end-user or external user’s perspective. Black box testing can be performed on virtually every aspect of software testing including unit and integration testing, system testing, and acceptance testing. It’s also known as box testing or functional testing.
 

White box testing

 
White box testing is generally considered as low-level testing. It tests the internal functioning of the software, and is based on coverage of code statements, branches, paths, conditions etc. White box testing is also known as glass box, transparent box, or code base testing. Inputs are chosen to exercise paths through the software’s code to get desired outputs. It’s usually done at the unit level though in some cases, it’s also applied at integration and system levels.
 

Key differences between the two

 
Internal & External

Black box testing tests the external behavior of the software while the testers have no knowledge of the internal structure or behavior of the product. Testers who know the internal structure of the product performs white box testing.

Programming & implementation knowledge

Testers performing black box testing need not possess programming knowledge or implementation knowledge to do so. However, to perform white box testing, programming knowledge and implementation knowledge are mandatory.

Automation prospects

Black box testing is considered as an advanced testing technique where programmers and testers need to be involved directly. This makes it challenging to automate black box testing. White box testing, on the other hand, can be automated and is quite easy to do so as well.

Major techniques

Black box testing can generally use one of the three following techniques:

  • Boundary Value Analysis: Focus on testing the input boundaries that are most likely to end up giving erroneous outputs.
  • Equivalence Class Partitioning: Focus on identifying and classifying errors so as to reduce test cases.
  • Error Guessing: Focus on finding defects first and developing corresponding test cases.

When it comes to white box testing, the tester’s knowledge about the system allows him to develop test cases to discover internal defects. The techniques involved include:

  • Statement Tests: Every statement within the code should have a test associated to it, and each statement must be executed in a test cycle.
  • Decision Tests: All decision directions should be executed in a test cycle.
  • Branch Condition Tests: The conditions associated with a specific decision should be tested to see if they are working properly.
  • Data Flow Tests: All variables and data within the system are tested.
  • Multiple Condition Tests: Each point of entry within the code is tested in a test cycle.

 

Conclusion

 
Many software development companies tend to not completely perform black box testing especially when there are time constraints. They instead do some quick tests to see if the software’s core features are functional. Some companies perform neither black box nor white box testing but instead implements grey box testing – a combination of black box and white box testing done only at the interface level.

In this age, product quality and usability are more important than ever which demands great effort from testers into ensuring that the end-product was built the right way, with the right functionalities, and without defects.

Written by: Suraj Jayaram

Pair testing, often referred to as Buddy testing, is a software testing technique where two people from the project team test the same feature in parallel under the same conditions while exchanging ideas. Contrary to how it appears, pair testing does speed up test assignments while delivering more quality results.

This guide serves to introduce beginners in software testing to the concept, and where and when they can adopt the technique to maximize its benefits.
 

Pair testing buddies

 
Pair testing is generally done by a developer and a tester. However this isn’t the only way to do pair testing. A technical writer and a tester can be paired up to document how the software would be in the next release. A tester and the client can be paired up to recreate an error scenario that the client identified, and fix it. A solution architect and a tester can also be buddies in pair testing, which could lead to exploratory testing with respect to what if scenarios. A tester and a developer can team up to investigate odd bugs.

So basically, pair testing can be done with almost anybody in the project team, especially if it’s a Scrum project.
 

Where you can apply pair testing

 
In a Scrum project, pair testing can be done throughout the software development cycle – in one sprint or many. It can be a good learning experience for junior testers. If the business analyst needs to see how a particular feature works and identify possibilities for further enhancements, he can do pair testing.

A tester or developer who wants to investigate an odd bug or look into some issue with the application that’s becoming a problem for the client, can speed things up with pair testing. In addition, almost every task directly associated to testing done by a pair from the project team may fall under pair testing even if it’s noticed to be so.
 

Basics of doing pair testing

 
Pair testing can either happen spontaneously or it can be executed with a predefined approach. For the latter, testers should begin by defining the preparation for the tests they will be doing and then plan the execution. Both parties should agree upon a time period and actively make an effort to finish testing as planned.

Spontaneous pair testing can happen in many scenarios, a common example of which would be when a tester gets stuck while looking into a problem and seeks aid from a colleague. While the partnership works with different test data, shares ideas, and explores new aspects to test, they’d also find the cause of the problem that had been bugging the tester at the beginning. This can be considered as unplanned pair testing.

Another situation is when the tester explains how a feature would work to a colleague. The colleague might have questions that didn’t occur to the tester. This is also unplanned pair testing.
 

Conclusion

 
The bottomline is that pair testing is a beneficial practice for any software development company, provided they have replaced traditional development methodologies with Agile. Making an execution plan, setting up the test environment, and ensuring that your testing buddy bought into the concept of what it is that you are testing – this is how you do pair testing. Give it a go once and see how it can speed up application testing.

Image Designed by Freepik

Written by: Suraj Jayaram
Page 2 of 51234...Last »