How Covid-19 Showed Us The Importance Of Big Data In Medicine

Big Data and modern programming technologies have been indispensable for years, affecting almost every area of our lives – from commerce, finance marketing to aviation, and crime prevention. The biggest potential of Big Data and new technologies can be seen when it comes to reducing the costs of doing business, allowing faster access to information, and improving management.

Read more

Say that you’re going to work on custom software development. You have an amazing idea, but when it comes to execution…

Custom software development is not always a bed of roses unless you find the right software development company for your project. 

You may fall for recommendations, reviews, and ratings, but you should also trust another R factor – Research. No matter what you choose, it’s good to have a list of 5 features to consider when making up your mind. And we’ve created exactly that for you. 

Read more

Hola, Nǐ hǎo, Bonjour! Looking for the best tools to learn a new language? You definitely have heard of apps like Duolingo, Memrise, etc. But I’d like to share with you some useful tools and websites that aren’t so well-known and might be helpful when improving your language skills or learning a new language. 

Read more

Since functional programming evolved from lambda calculus and has its roots in academia, it was initially discussed in scholarly contexts. It’s no longer the case. Even though significant technologies associated with functional programming (such as Lisp or Scala) were created at universities — FP is making its way to the general “software development discourse,” and some might say that it’s taking it by storm. 

Despite the rising interest, however, not many articles on the web seem to tackle the benefits of functional programming for business. Let’s face it: hacking a new technology in spare time is great, but there’s always a practical side to business when it comes to trying out new things and having a good reason for that. And that’s precisely what we’re about to cover in this piece. 

Here’s what functional programming is, and why does it matter for your business. 

What is functional programming in the first place?

Functional programming (FP) is a programming paradigm, a certain way of thinking about software development that’s based on a few defining principles. In the case of FP, these key principles are as follows:

  1. Binding everything in pure mathematical functions. The purpose is to look for simple, repeatable actions that can be abstracted out into a function and then built upon to create more complex features.
  2. Immutable, unchangeable data — which means that you should rather create new data structures, not altering the ones that are already in place. For example, if you want to modify data in an array, you need to add a new array with the updated value instead of making changes to the “original” one. 
  3. Declarative code. The main focus here is on what to solve, rather than how to do it. 
  4. Statelessness. Functional programs should perform each and every task as it was for the very first time, without any knowledge of what happened (or not) earlier in their execution. 
  5. Recursion. There is no “for” or “while” loop in functional languages, iteration is implemented through recursion. Basically, recursive functions repeatedly call themselves, until the base case is reached. 

Functional programming vs OOP (Object Oriented Programming)

Speaking of programming paradigms, you might already be familiar with another one that’s still more popular: object-oriented programming (OOP). This doesn’t mean, however, that FP is not gaining any traction. Both functional programming and object-oriented programming are unique in their own ways. 

Here’s functional programming vs OOP at a glance to help you grasp the differences:

XFunctional programmingObject-oriented programming
DataImmutableMutable
Programming modelDeclarative Imperative
FocusWhat you’re doingHow you’re doing
Parallel programmingSupports parallel programmingNot suitable for parallel programming
Side effectsIts functions have no side effectsIts methods can produce side effects 
IterationRecursion“Loop” concept
Application stateFlows through pure functionsIs usually shared and colocated with methods in objects 
Key elements of the codeVariables and functions are the main elements of the codeObjects and methods are the key elements

What about programming languages, then?  

Pure functional programming languages, such as Haskell, are specially designed to serve this particular paradigm and accept only pure functions. Interestingly, you don’t need to use a pure functional programming language to bring FP principles to your code. 

There are a few languages that still make it easy to write “pure programs”, such as Scala, Clojure or OCaml.  More popular programming languages like JavaScript or Python can also support FP one way or the other – either natively or with the right library.

At Scalac, we’re big advocates of functional programming and, which shouldn’t come as a surprise, we mainly use Scala for this purpose.  There are at least a few good reasons for that:

  • The language is extremely versatile and offers advanced features, clean code, and both functional and object-oriented programming in an open-source, practical package that leverages Java’s environment. 
  • Speaking of — Scala has emerged as one of the most powerful Java alternatives. Actually, one of the reasons why Scala was created in the first place was to address various concerns developers had with Java. Nowadays, Scala provides interoperability and compatibility with Java, allowing the developers to keep their Java libraries, and leverage the advantages of JVM. 
  • When comparing it to Python, on the other hand, Scala’s maintenance is simply much faster. Despite providing the fluency and flexibility of a dynamic language like Python, it’s still a strongly statically typed language. The performance also tends to be much more efficient, especially in a multi-threaded environment.  
  • Because of its functional aspects and flexibility, Scala is also useful for expressive code and parallelism. Basically, with a functional approach and no mutation, there are no race conditions and parallelism gets a lot more straightforward. Then, lambda expressions are also helpful when communicating some aspects of parallelism. 

But, the question remains:

Why should you use functional programming (and Scala, for that matter)?

For some reason, this programming paradigm still seems complex for many. When taking a closer look at the benefits of functional programming and languages associated with it, you might have a different impression. 

To start with, adopting functional programming helps you break down every application into smaller, simpler pieces that are both more reliable and easier to understand. It’s mostly because functional code tends to be more concise, predictable, and easier to test. How come? 

  • Since pure functions don’t change any states and depend only on the input given, they are much easier to grasp
  • When there’s less code, there are also fewer bugs — not to mention that actual testing and debugging gets much easier with immutable data and pure functions that take only arguments and produce output. 
  • With the outputs depending only on the arguments passed to the function, the software can also behave more “predictably”
  • FP adopts Lazy Evaluation which avoids repeated evaluation (basically, the value is evaluated and stored only when it is needed) and supports other Lazy Functional Constructs like Lazy Lists, Lazy Maps, etc. 
  • Functional programming also means efficient parallel coding — there’s no mutable state and no state-change issues, which supports easy reusability and testability. 
  • Speaking of efficiency, functional programs consist of independent units that can run concurrently and can be more efficient as a result. 

Since Scala supports functional programming, these benefits apply to it as well. In fact, the combination of features in Scala makes it possible to write programs that are concise, elegant, and much easier to debug & maintain. 

As a result, increasingly more companies switch to both functional programming and Scala, including well-known tech giants like Twitter or LinkedIn. Interestingly, Scala also made it to the top 10 languages that developers want to learn these days. 

The rising interest from both companies and developers are contributing to the recent growth of functional programming and the adoption of Scala as the main language for many applications — also in a business setting. 

What do functional programming & Scala mean for your business, though?

There’s no doubt that knowing the principles of functional programming can broaden one’s horizons and introduce new ways of thinking about software development. But what’s in it for the companies? 

To start with, code quality. When it comes to functional programming — very often, you can do more with less code. It’s much more concise, which essentially means fewer bugs, and shorter time (and/or fewer people) to actually write it. Plus, it’s a lot easier to grasp what the code does, explain it, and even onboard new team members who can almost immediately join the project and start working on it. In the process, Time to Market often gets shorter. 

What’s also worth mentioning is that the interest in functional programming and languages that bring its principles to life stems from being tired of limitations posed by other programming paradigms and technologies. As already mentioned, Scala as a modern language has plenty of useful features that you won’t find in Python and Java. Even implementing it can be a big savings cost of the bottom line. 

What’s more, there are already some business cases that both functional programming and Scala have been applied to successfully. Health care, accounting, banking, advertising — are just a few exemplary industries.

For the time being, functional programming seems to work best with apps aimed at concurrency or parallelism, carrying out mathematical computation, and whenever there are many different operations performed on the same data set. Scala is a good fit if you have a lot of data or complex data structures and algorithms, but FP languages are also often used for artificial intelligence applications like machine learning, language processing, or modelling of speech and vision. Pretty impressive, right?

With the rising interest and so many benefits of functional programming, how come it’s not yet as widespread as it should be? 

At the end of the day, businesses rather choose the technology based on the skills of their team or the availability of developers, who are more likely to represent more traditional approaches to software development. That’s precisely why it matters not only to educate developers about FP but also give them tools to apply it in practice. 

For now, “the movement” is all bottom-up: it’s starting from developers who are tired of being limited by other programming languages, become interested in functional programming, and then teach their colleagues about it. 

As these developers start creating libraries and frameworks that solve specific business problems across multiple areas (such as backend development, analytics, distributed development) with the use of functional programming — eventually decision-makers will also get excited about FP. And, the more companies are interested in functional programming, the more developers skilled at it they want to hire. It’s a chain reaction from there. 

To facilitate the shift to functional programming, drop some of the jargon around FP and lower the barriers to entry, there are initiatives and projects like ZIO — a library for asynchronous and concurrent programming based on pure functional programming. Taking advantage of it is said to help in solving common business problems, and ensuring higher success rates of projects. This, in turn, brings more attention to functional programming, in the business world as well. 

What’s also great about ZIO is that it’s inclusive for all sorts of developers. It’s still fairly new, but it’s expected to be a great venture in the long run, mostly due to all the open-source support it gets. It might be difficult to take advantage of ZIO when developing enterprise-level software just yet, but more and more companies are already testing it in production for smaller projects. And that’s only one of the reasons why the future of functional programming definitely is bright. 

Dig into functional programming yourself 

Increasingly more companies are prepared to train development teams on how to use FP and solve business problems with functional programming, including Scalac

Switching to functional programming can be done whenever there’s a new module to implement and thus, can be done gradually. Start small, and see how big of a difference the main aspects of functional programming can make to your business. As per usual, we’re here to help

We compared hours and hourly rates and the outcome might surprise you

Automation testing or manual testing? That is the question! Which one is better? This is something that gives many in the tester community sleepless nights. Especially during a project when we have to determine the testing strategy, even at its later stages. This is also, unfortunately, a question with no clear answer. Why? Because the reality is that these two ways of testing are inseparably connected with each other.

If you’re still wondering which is more profitable, effective, or better suited to your or your client’s project, let’s dive right in. Here we’ll be revealing the true value of automation vs manual testing, based on one of our clients’ applications – CloudAdmin.


Why CloudAdmin?


Together with Pawel Gieniec (CEO & Founder CloudAdmin), we are creating and developing a web application – CloudAdmin. Cloud Admin is a cost-optimization platform, which helps save thousands of dollars by eliminating hidden cloud instance buying costs.

The project turned out to be perfect for introducing an automation architecture for modules that are always tested during regression testing (the process of running older tests to ensure that new updates to a piece of software haven’t introduced or re-introduced previously eradicated bugs). Our goal is to save time, which we will then be able to spend on manually testing new functionalities. The application is developing dynamically, so we’ll be needing more and more time to check all of the fresh new features.

One of the core functionalities is logging. Nothing surprising, this is probably the module most often automated.

We decided to use automated testing with Python and pytest. 

And this is how it went:

We based our login tests on these 7 test cases below.

The first video is from PyCharm (the Python IDE). It shows how long it takes to run and finish all of the tests for the login module. As you can see, all of them passed. This means all of the cases have been tested correctly and have achieved the expected results, i.e.  the functionality works properly. 

Automated tests – this process took 1:39.

Now take a look at the video below. It shows how long it takes to carry out manual testing for the same test cases as for the automated tests. 

Manual tests – this process took 1:57.

How test automation reduces the time

At first, you might think “Hmm, this is no big deal. There’s only an 18-second difference in favor of automation.”. Okay, you’re right, but let’s think more in the long-term and globally.

First of all, it’s not just an 18-second gain. It’s an almost 2-minute yield for one run! This will ultimately give us more time to spend on the project. How? 

If you decide to implement automation architecture for sections that always needs to be covered by manual regression testing, you will gain all of this time for doing other things (manual testing for new features, application development, automation architecture development).

The login module is just a drop in the ocean. But let’s take a look further. Let’s compare working times by adding the next 3 modules: AWS Ri Planner, AWS RI Management, AWS Spend.

As you can see, the automation tests give us a 35% time yield relative to the manual tests (9:16 min vs 14:14 min). And again, this is a 14:14-minute gain, we have saved on regression tests – for only 4 modules.

How test automation increases productivity

As mentioned before, by dint of test automation, the testing team gains more time they can spend on doing other tasks. But this is not the only thing they get. Regression testing can be tiring. Imagine how tedious it would be to repeat the same action over and over again. This might sound trivial, but the time involved in repetitive, manual testing is wasted, especially over a longer course of time. With this in mind, think about how much more productive testers could be if they were able to devote more time to performance testing, security testing, or testing of new features. 

Moreover, testers have to quickly and continuously execute a lot of time-consuming tests simultaneously, just to be sure an application is performing as expected at all times.

How long will setting up an automation architecture take?

It’s rare that everyone on your team has  automation experience, so when it comes to resources, you will really have to gauge how much time it will take for your tool to make an impact. You will either need to invest in expanding your team’s automation knowledge or hire automation specialists.

Let’s go back to our CloudAdmin tests. 

Considering the  4 sections previously mentioned (Login, RI Planner, RI Management, Spend), our QA Engineer (the automation tests were written by one person) devoted 80 hours to:

  • choosing and configurating tools  – 16 hours
  • writing automation tests for every test case – 16 hours per module / 64 hours per 4 modules

It might seem like this is a long period of time, but don’t be fooled. Automation architecture is reusable. We can use it limitlessly.  Maintenance and development of automated test cases is an ongoing process. Unfortunately, there’s no guarantee that  spending eighty hours automating a set of tests means you won’t have to deal with them again. But it will still take definitely less time in general. Take a look at the graph below:

Source: https://www.multisoftsystems.com/

The turnaround time for automatic testing is definitively longer than for manual. However, the benefits of automation outweigh the time benchmark in terms of:

  • Reduction in execution time 
  • Reduction in effort 

These two metrics will provide an incredible boost towards higher efficiency and a better rate of reaction to potential bugs.

What about costs?

Last but not least, is something most crucial when establishing a contract with a client – costs. Test automation might be a catchy slogan during negotiations but it’s worth checking the hidden costs. You don’t want the client to think this is just another fashionable balloon, ready to burst at any time.

If you intend to adopt an automated testing process to meet the rising demand for bug-free releases and faster delivery cycles, it’s vital to assess whether the return on investment (ROI) is worth the changes. Before executing, or even considering building an automation strategy, you will want to calculate the net gain you will achieve from transitioning. Divide this by the net investment needed to transition (i.e., the tools and resources you use), and you will see your ROI for automated testing.

Source: https://www.level12.io/

The maintenance cost of test automation is not usually trivial but if you keep enhancing the test automation framework, improve the application testability and overall testing processes, a high ROI is very much achievable.

To get the total cost, you will also want to take into account the hourly cost of the number of team members executing the tests.

Based on the average earnings for an Automation QA Engineer and a Manual QA Engineer (I rely on data from Glassdoor), we can make a labor cost comparison simulation based on the CloudAdmin case study (hours needed to perform each type of tests for this application).

As I mentioned before, it took 80 hours for our QA Engineer to develop and execute the automated tests for the 4 CloudAdmin sections. How many times might we manually test the same part of the app at the same time? 337 times (for the record: manual testing time -> total time from the module times table). So what’s better: 

  • spending $2,100 on performing  the same set of regression, manual tests 337 times

or

  • spending $2,700 on building an automation architecture – which once created is reusable?

We’ll let you answer that question ;) 

Final battle: Manual Testing vs Automation Testing

To wrap up, is an automation testing a cure-all for time-consuming manual testing? Not really. Manual testing will always be important. There are scenarios that will always require manually executed test cases. This means you will still have to create, run, and maintain the tests. But there are still a lot of situations when you can successfully implement automation. This can be a cost-effective method for regression testing of software products that have a long maintenance life.

With a balanced approach to the testing process and a smart and effective amalgamation of both automation and manual testing, you can spend more time focusing on building new features to enhance your product quality – ultimately giving yourself the opportunity to stay ahead and be more competitive in the market.

Check out other testing-related articles

Check out other business-related articles

Why do you need this Rest Assured API testing tutorial? In the world of testing – automation can be a real game-changer. That’s why it’s on everyone’s tongues, especially  “automated tests” in the context of GUI tests written in python/java with SeleniumWebDriver. Or possibly with the increasingly popular Cypress.io. However, GUI tests sit right at the top of the basic pyramid when it comes to testing. 

Read more