Modern software is multi-functional and complex. Manual testing of a new software product usually requires considerable resources. Meanwhile, automation testing can help to increase software quality and run tests more quickly. But before you decide to change something in the current workflow, make sure you’ve figured out all the advantages and disadvantages of automation. We are going to help you with this, dispelling some popular myths and explaining important nuances. What is automation testing? Software automation testing is the process of software verification, during which all major functions and steps are performed automatically by using specially designed tools. It is an alternative to manual functional testing, where tests are run by a program instead of a human. Don’t confuse automation testing with automated tests. The latter is a scope of tasks that can be automated. They are just a part of a wide concept we discuss in this article. Automation testing is a cycle followed at multiple levels in diverse environments. Let’s start by covering the difference between manual and automation testing. Usually, QAs come up with a formula that balances manual and automation testing for a project. The level of automation depends on the project type and a company’s internal processes. A closer look at automation testing Before we move to the advantages of automation, let’s learn (or recollect) the basics: the way it works, its purpose, application, and common misconceptions. How does automation testing work? Automation testing involves the use of special software, besides the one being tested. QAs create automated tests that can be started at any time and repeated numerous times. These tests are launched and executed quickly and accurately. QAs monitor the execution of tests, then compare expected and actual results. What is the purpose of automation? It simplifies performing frequently repeated or time-consuming tasks necessary for maximizing test coverage. Moreover, sometimes manual testing isn’t efficient for finding certain classes of mistakes. In such cases, automation helps to save time and allocate resources smartly. What can be tested? There are several types of automation testing, each based on what exactly is tested.  Code-driven testing – at the level of software modules, classes, and libraries. They are divided into unit tests (on separate code modules) and integration tests (on multi-module system components). Graphical user interface testing – a framework that allows to generate user events and scenarios (button clicks, page activity, etc.) and track whether the software responds correctly. API testing – tests on program interfaces used for integration with other apps or users.   Phases of automation testing Product owners often ask on which phase the potential benefits of automation testing are outlined. There is no universal answer because an approach to software development process and automation testing, in particular, varies in every company. An approximate sequence can look like this: We wait for new changes in source code.  Team QAs run unit tests. Deployment on integration environment.  Following integration tests.  Deployment on an acceptance environment.  End to end tests.  Deployment on production.  Automation testing tools Testing tools play a key role in the automation process. Both commercial and open-source software solutions are available today. To choose a suitable one, you should consider: a type of testing to automate;  applications tested; a language used for the test; additional tools you use or are going to use.  Some of the top-popular tools are:  Selenium – an open-source framework for web application testing.  Katalon Studio – widely used for testing web apps, mobile apps, web services. UTF – a popular commercial tool for functional testing.  IMB RTF – a platform for functional testing and regression.  Tricentis Tosca – a model-oriented tool with a wide range of features for continuous testing.  Myths about automation The benefits of automation testing may trick even freshman QAs. Some expect it to be easy and requiring minimum efforts. Be ready that it isn’t so, and many things can shatter your way of looking at things.  Myth #1. Automation testing increases expenses. Truth: It requires investment because automation itself is another software development process. If you plan it smartly, however, you will save money by spending less time and resources. And remember that software bugs in production cost much more than testing.  Myth #2. It can always replace manual testing. Truth: The purpose of any automation is to facilitate the manual part. Test efficiency increases while QAs can focus on more complex issues. Meanwhile, an autotest will skip even the smallest bug if this type of error isn’t detected in the search algorithm  Myth #3. Automation is always better than manual testing. Truth: Automation is senseless if you are going to run a test once. The process of automation can take more time than manual tests in some cases. Besides, a program cannot always handle 100% of work without a single glitch. It is impossible to execute all scripts without crashes. Myth #4. Automation is always faster than manual testing. Truth: Automation is much faster compared to manual testing, when it is relevant. In some cases, it takes more time for a program to detect an object with properties that aren’t straightforward. For example, a tester can detect multiple headings with similar properties on a page by just looking at it. A program requires running a long analysis to handle the same task. Besides, a QA quickly finds the data needed to conduct test cases. A program requires a prescribed sequence of operations to complete the same task. Myth #5. An end-user of automated testing only needs to click one button to run the tests. Truth: Some think that when the automation is completed, an end-user of the application (a QA or a developer running unit tests) can execute the scripts without any changes in the test data. Unfortunately, this happens rarely. You can “teach” a program by adding additional code after you notice a gap. Still, script execution is a secondary task; our end-user needs to understand streaming data, keywords, and know what values ​​to enter.  Myth #6. You can spend time studying frameworks and test cases while automating a new application. Truth: Writing an automation script requires a QA who knows the field, knows how to automate test cases, and can choose an appropriate framework. And just like app development, automation needs to be tested. Scripts written using automation must be carefully checked using all test data and negative testing. A tool that hasn’t passed these tests will cause errors in the script during operation. What are the benefits of automation testing? So why automation testing is better than manual? This is probably the question that brought you here in the first place, and below are the longed-for answers.  #1. Increased testing quality. Automation testing excludes the human mistake factor. Programs used for running tests don’t get tired or become inattentive. The accuracy is close to 99.9%. Besides, almost all existing cases and scenarios fit in five lines of code. #2. Advanced testing opportunities. With automation testing, you can handle some tasks a big team isn’t – imitate the simultaneous work of thousands of users. You can quickly deal with the tasks that require extra investment or specialists if run manually.  #3. Acceleration doesn’t affect test quality. Completing the same amount of work manually will take much more time, while automation testing allows using ready scripts without further development. Thus, a team gets extra time for testing problem zones manually. #4. Multiple time usage. The same tests can be used numerous times – as many as necessary until you make sure the software is bug-free. It is also possible to run multiple tests on several devices with different configurations without affecting the efficiency of the results. #5. Distant auto start. Server load is minimal from 2am to 5am so this is the optimal time for running tests. A QA doesn’t have to wake up this early to start working.  #6. Detailed reports (that are also automated). Manual testing is subjective compared to automation, which generates statistics and reports after every test. They are saved and mailed to all (or chosen) group members. #7. Cost- and time-efficient results. Large high load projects require more attention to details and more thorough quality control. Over the long run, only automation testing will be efficient for finance projects, ecommerce websites, and online casinos. Besides, to replace an automation test, you’ll need 3 to 8 live QAs of flesh and bone, each with a $25+ hour rate.  And are there any cons? The benefits of test automation over manual testing are rather obvious but don’t forget about the flip side of the coin. Automation isn’t unequivocally perfect. It can have some disadvantages for a team as well. #1. Possibly high initial investments. The tools used for automation testing are costly, as well as proper education for QAs. In this case, a QA is a bit a developer, who sets up software for testing, and their price is higher. #2. Problems with UX testing. This is one of the few aspects where human estimation is more efficient than machine tests. The latter cannot cover our aesthetic requirements.  #3. Lack of professional experience. The longer QAs work, the more likely they are to notice extraordinary bugs. Based on previous cases and mistakes, you can come up with unexpected tests to prevent too tricky bugs. #4. It takes time to start. You need some time to write autotests that will cover the product testing. Things that can go wrong Despite all the benefits of automation testing, there are some situations to beware of. We hope that learning about the situations mentioned below will help you to avoid common pitfalls.  Some apps are projected without taking into account the necessity to test them. Thus, it is difficult or impossible to check particular components.  Some tools don’t include module or integration tests. If the tests are postponed, you get a serious problem.  Business logic testing is usually checked via the user interface, while it is designed on the lower levels. Addressing it directly helps to get more precise results, faster and more reliable.  More and more development companies offer to cover automation testing for you with just a few clicks, meanwhile creating artificial limitations. QAs, premeditatedly or not, may create a too complex testing solution. They spend too much time and come up with a program with a mass of dependencies, patterns, and decisions that aren’t necessary. And sometimes it happens that no one else can use it but this single QA. When to use automation testing? Automation is not a panacea. Below, you’ll find several criteria explained by cases that will help to figure out whether automation is necessary. If at least one of the points is familiar to you, introducing automation testing is a good idea that will benefit your project. Project scale. A project has been lasting for over a year, and now it consists of numerous sub-systems. The number of tests you need to run is constantly increasing. Dealing with all test cases (several hundred by now) takes almost a week if done manually. Team size. Every team consists of more than two developers. Each has to be certain no changes have affected the code. Without automation testing, a developer learns about new bugs in a day or two in a better case or after the software is released. Support of old versions. You support several versions of the software, releasing patches and service packages for each. Testing on different configurations is routine work that can be automated. Test data generation time. You are working on a data processing app. Entering various records manually and conduct a visual analysis is an untenable use of resources. Frequent releases. You have an agile approach with short iterations and frequent releases. You cannot afford to spend over a week for testing. Things to automate The most obvious one is the digital payment systems. Those have become an inseparable part of everyday life worldwide, and further digitization creates a need for test automation. Business owners need to ensure high quality of transactions and customer security and testing becomes crucial. Besides, payment software requires to run performance, usability, and security tests periodically to guarantee seamless and safe operation. Automation testing helps to meet the increasing demands of consumers and routines of companies’ agile approach.  This is, however, not the only case to consider automation. Depending on the customers’ requirements and software features, it makes sense to automate the following things: Hard-to-reach spots in the system: back end processes, file logging, databases, etc. Frequently used functionality with increased risks of errors: subscription, registration forms, etc.  Routine operations: sorting data, forms with a large number of input fields. Validation messages: automate the filling of fields with incorrect data and check for validation. Long end-to-end scenarios, like real estate CRM and similar systems.  Verification of data that require accurate mathematical calculations: accounting or analytical software. Validation of search function and data retrieval.   Bottom line Some projects don’t need full automation – a couple of auxiliary scripts will be enough to speed up the work. If you start working on development with a large team or join a project that is going to last for years, automation is indispensable. Automation testing will help the team deal with testing faster and more efficiently. If it usually takes 3-4 days to test before the product is ready for release. Automation can reduce this time to just a few hours.  If you are interested in test automation for your product, just let us know. UTOR always has a QA team ready to join a project and help to release bug-free software.

At UTOR, we believe that behind every great technical solution, there’s an even greater QA effort. That’s why our team is committed to empowering clients with a wide range of QA and testing services to decrease costly quality risks. After all, a critical bug postlaunch can be disastrous for building customer trust.  We’ve recently been named one of the leading development and testing firms in Ukraine by Clutch, an independent B2B ratings and reviews platform. Clutch ranks various service providers around the world using a rigorous research methodology: By calculating our industry experience, market presence, and verified client reviews, they’ve determined us to be a trustworthy company with a high ability to deliver! We’re proud to work with Clutch to showcase our client feedback, which has helped us grow over the years into an even stronger company.  One of our most recent reviews comes from Mushket Mobile, a development firm that helps startups realize their goals. Since our initial engagement nearly 3 years ago, we’ve continued to partner with them to test all of their apps before release. Mushket Mobile has been so pleased with our service that they gave us a perfect score! In their own words, “Perfection has no limits.” Passionate client reviews like that have helped us gain recognition on Clutch’s sister sites, too. We’re featured on The Manifest, a data-driven business guide, as a leading software testing company. And we’re recognized for our application testing services on Visual Objects, a portfolio-based directory of service providers. We can’t say enough how much we appreciate our clients. Each day, our team strives harder and harder to improve our skills so that we’re even more well-equipped to meet their needs. If you’re interested in trying out our testing or QA services, be sure to contact us to explore how we can best support your project needs.

The most dangerous laptop on the planet was recently put on the auction. The old 10-inch Samsung on Windows XP has got a nice name — “The Persistence of Chaos,” and six malware programs installed on it: ILOVEYOU, MyDoom, SoBig, WannaCry, DarkTequila, and BlackEnergy, which altogether caused the damage for $95 billion. The laptop is isolated from the internet and other gadgets, so it is not going to cause any harm now.  Computer viruses, however, aren’t always the issue that causes problems. Lack of communication between teams, lack of attention, and poor software testing can have more horrific outcomes — from causing inconvenience for thousands of people to shocking financial losses or even people’s deaths. So how much does a bug cost? It depends on the circumstances, and you can never predict the software development cost of bugs until you detect these weaknesses. We’ve decided to tell about some headline-making cases that prove the importance of good QA unit and responsible testing. What is bug in software testing (with example) Before we move to cost of software bugs, a short reminder for the newbies. A bug in software testing is a program error or a functional defect in software, which causes unpredictable behavior of a program or system. The goal of a QA team is to find all those defects, to detect the potential risks, and to pass on the findings to the dev team. Developers are to fix bugs before deployment and deliver the software of proper quality to an end user. You might have noticed some common bugs, too: incorrect localization features, troubles with supporting certain device models and OS versions, heavy power consumption, problems with connectivity and responsive design issues, unclickable buttons, etc. But these are just some minor issues compared to what you’ll discover below.  Houston, we have a problem: troublesome space investigation If you are curious about the sphere with the highest cost of software defects, this is certainly space exploration. Elon Musk may have successfully sent his Tesla Roadster to the other planet on the Falcon Heavy, but many more launches that meant to be spectacular turned into disasters. Mars Climate Orbiter Mars Climate Orbiter Cost: over $193 million The robotic space probe was sent to explore the Martian climate and take photos of the planet on December 11, 1998. The way to Mars took around 9 months. On September 23, 1999, the Orbiter was supposed to produce a retroburn, head over to Highly Elliptical Orbit with a 4-hour period, and enter an orbit in two months.  At the designated time at 193-km height, Orbiter started to spin down. In five minutes, it headed towards Mars and disappeared forever. The analysis of mistakes showed that the probe lowered to 57 km over the surface instead of the planned 110 km and collapsed in the atmosphere.  The breakdown happened due to incorrect calculations. The teams that were working on the development used different measurements: NASA calculated the final stage parameters in the metric system, while Lockheed Martin engineers used the British system. As a result, the craft descended 53 km lower than it was supposed. $193.1 million were spent for the spacecraft development alone, not including the price of the launch and mission operation.  Mariner 1 Cost: $18.5 million The spacecraft Mariner 1 was launched in 1962 for a first ever planetary flyby of Venus. Just in 293 seconds after the launch, the spacecraft went off the designated route. To prevent the damage for inhabited localities that could happen in case of a crush, Mariner 1 was destroyed high in the sky in 4 minutes 53 seconds after the start of the mission.  According to the official version, a software developer made a mistake when translating a handwritten formula into code: he mistook an index character for a dash. As a result, an onboard computer assumed normal speed steps for critical causing a breakdown. The spacecraft lost connection with controls on the Earth, and the system proceeded to Plan B. The New York Times called it the most expensive dash in history. Mariner 2 was launched two months later, with all the indexes on proper places.  Ariane 5 Cost: $8 million  Ariane 5 didn’t last that long: the heavy launch vehicle designed by European space agency was destroyed on the 39th second of the flight due to incorrect software functioning.  The software installed on Ariane 5 (it’s inertial navigation, in particular) was originally developed for Ariane 4. Because of the different launch trajectory, the horizontal speed exceeded the set limits and caused a breakdown. Ariane 5 had a more powerful engine, which caused a bug that wasn’t typical for previous versions. The program attempted to record 64-bit number into 16-bit space. Both main and backup computer failed because they were running the same programs. On the 39th second, the rocket started to collapse and self-destructed, induced by aerodynamic forces.  $8 million were spent on designing the rocket. The compound damage, however, was much bigger. The total price of satellites Ariane 5 was supposed to place into orbit amounted to $500 billion. Something’s wrong with my computer! Bugs in user software are much more common. In the end, people don’t try to launch rockets every day, while almost everyone has got several devices connected to the internet. Sometimes users have to deal with serious system errors, viruses, and gaming features that don’t function the way they are supposed to. Pentium processor bug Cost: $475 million In 1994, Thomas R. Nicely, math professor of  Professor at Lynchburg College, detected a bug in a popular Pentium processor and published an article about it. It was a Pentium FDIV flaw — a bug in operations module with floating decimal point in original Pentium processors produced in 1993. Due to the error, the processor might return incorrect binary floating point results when dividing a number.  According to the official statement, it happened because of the missing entries in the lookup table used by the floating-point division circuitry. The Intel486DX version of 1989 used coprocessor module with a floating point. The microchip of the next generation worked with integers but the coprocessor remained the same. The probability of such mistake was 1 in 9 billion so Intel announced that they were ready to replace processors in case a user proves the bug affected their work. Disgruntled customers, however, decided that every user deserved to get a properly working hardware and requested replacements.  Morris Worm Cost: $100 million In December 1988, a graduate student at Cornell University Robert Tappan Morris accidentally created a malware program. It started as a harmless experiment but the program went out of the control due to a mistake in a code. It started spreading rapidly, blowing out thousands of computers. Morris was accused of cybercrime and fined for $10,000, although around $100 million were spent for compensating the damage he caused.  Morris’s lawyer claimed that the worm helped to improve cybersecurity. Later, Morris became a co-founder of Y Combinator. He is an associated professor at MIT. A floppy disc with worm’s source code is stored in Boston University. WoW virus Cost: virtual epidemic, price is not announced This article wouldn’t be complete without mentioning some bugs in games, in particular, the case of World of Warcraft with its “bloody virus.” It started in 2005 when WoW developers introduced Hakkar the Soulflayer, the Blood God. His mission was to poison the enemies with corrupted blood during attacks. This cool feature turned into a real tragedy for players. The characters weren’t the only ones to be poisoned, but their virtual pets suffered as well. The blood turned into a virus and affected the characters for a long time.  As a result, experienced users somehow managed to survive, but the new ones were dying almost instantly. When the bug was fixed, Blizzard hurried up to announce the victory over the virus of corrupted blood. The scale of the damage for company and players, however, was never announced, neither was the reason for the accident. Windows authenticity questioned Cost: thousands of users received notifications about using pirated software In 2007, Windows XP users were informed that they were using unauthorized software. Windows Vista users have got more serious problems: some functions, including Aero and virtual RAM drives, were turned off. The reason was ridiculous: the developers released the system that hasn’t been tested in a production environment. They noticed this software bug in half an hour, but the quick update release fixed only the issue with activations. The validation errors continued for 19 more hours, causing a lot of troubles for users.  Heartbleed virus Cost: worldwide data leakage In 2014, the IT community started discussing a software bug named “Heartbleed” that appeared in the OpenSSL library of TLS protocol. It was caused by the RAM stack overflow, letting any person connected to the Internet read user information up to 64KB from a computer running OpenSSL process. According to the reports, around 17% of all the protected websites worldwide were using this protocol and had this security-sensitive area.  Interestingly, Heartbleed was first mentioned two years earlier, but only Windows and Mozilla started working on the problem. Google decided to solve it by a quick patch. Thus, Heartbleed may be still traveling on the web and scammers may be stealing some private data right now for their new scam schemes.  Financial loses, nervous customers, endangered businesses Big corporations and state bodies become victims of functional defects in software testing even more often. Again, there are many mistakes a good QA team could have prevented. Child Support Agency messes up payments Cost: $1 billion In 2004, EDS developed a complicated computer system for payment of a benefit for the British Child Support Agency. Meanwhile, the Department for Work and Pensions resolved to reorganize the institution. Running these processes simultaneously induced serious errors: the system paid over the odds for 1.9 million people and was short in payments for 700,000 people.  $7 billion dollars didn’t make their way to accounts in time. DWP had to deal with 239,000 old and over 36,000 pending cases that stuck in the system. It cost over 539 million GBP (around one billion US dollars) to handle the situation.  Knight almost goes bankrupt Cost: $440 million Knight is one of the key stakeholders of the American stock market, and they almost went bankrupt due to a single software error. Because of the bug, the stock quotations declined by 75%, and the company lost around $440 million. The company settled to amalgamation.  The reason for the collapse was an error in trade algorithm. During two days, the software flood the market with unplanned deals at approximately 150 trading sites shutting down the work. The software processed false deals, buying at too high prices and selling at too low prices — doesn’t sound like a successful trade strategy.  In-demand British passports Cost: $16 million In 1999, a newly implemented by the British passport agency Siemens system couldn’t handle the timely issuing of passports for 500,000 British citizens. The company compensated for delays and for overtime. They even paid for the umbrellas for people in the lines.  It happened because the system hasn’t been tested and the staff wasn’t educated. The implementation coincided with the issuing of a new law, binding all children younger than 16 going abroad should have passports of a new standard. The extraordinary demand became a challenge the new system couldn’t handle. Airbus A380 gets outdated software Cost: a one-year delay of the release and the amount of money Airbus prefers not to talk about In 2006, German and French divisions of Airbus started the development of two parts of the new А380. Both used CATIA software. When it came to assembling, engineers were surprised to find out that some cables couldn’t be connected — there was simply no place to connect them. The miscommunication (or rather the lack of communication) resulted in the usage of different software versions, which required different hardware. The release was delayed for over a year. French division of the Airbus prefers not to talk about the financial losses.  Flight delays in Heathrow  Cost: 42,000 lost luggage items, 500 canceled flights Shortly before opening the fifth terminal in the Heathrow airport, the staff started testing the newest luggage transporting system. It was supposed to facilitate managing a large amount of luggage received at the airport every day. Before the opening, it was well checked on 12,000 test luggage items. Everything passed smoothly. In the first day of opening, however, it turned out that the system is unfit for service.  The program couldn’t handle some simple real scenarios which for some reason weren’t tested. For example, a person forgot something important in a bag, and the luggage was carried back manually. In this case, the program went off and an item wasn’t recorded. Luggage processing was disrupted by every little detail. During the following ten days, around 42,000 items weren’t delivered to owners, and over 500 flights were canceled. Check-in to other flights became temporarily unavailable.  A mess for insurance companies Cost: 8,500 people declared dead (but luckily, they weren’t) An extraordinary case happened in 2003 in a hospital in Grand Rapids, Michigan. A software bug in the patient database declared 8,500 people dead. All of them were safe and sound, but it was detected only after the investigation by insurance companies. The thing is, after a patient dies and a corresponding record appears in the hospital’s database, an insurance company receives a notification with the requirement to cover the treatment costs and pay compensation for the family.  Many people were surprised when insurance agents appeared on the doorstep. Nevertheless, there were no lawsuit or official compensations. Maybe some patients decided to change the hospital. The breakdown happened because of a mapping error after patient management software updates: a disposition code “20” was assigned instead of “01” — “dead” instead of “discharged”. The headache for Washington state authorities Cost: 3,200 criminals released early (without court decision) At the end of December 2015, the authorities of the Washington state noticed a bug in a system that has been functioning for around 12 years. The state authorities decided to operate early releases based on good behaviour credits automatically. Prison sentences consist of the regular part and enhancement (added for crimes committed under certain circumstances). The so-called “good time” credits were to be applied to the regular part only, but an error made the algorithm work differently.  The analysis showed that in average prisoners got out 49 days earlier, although there was a case of cutting the sentence for 600 days. It turned out that the bug has already been reported in 2013 by a family of a victim — they found out that an offender was released too early. The police started to return people to jails.  Reputation seriously damaged Cost: scientists are to deal with the poisoned reputation Ironically, software for studying accidents became an accident itself. New England Journal of Medicine published an investigation about the increase in the number of suicides following natural disasters. The results turned out to be untrue. The software doubled the number of suicides for one year in the investigated period — quite enough to cause erroneous results. Although this case wasn’t followed by financial losses, their reputation suffered severely.  Fatal bugs: it’s not always about the money Sometimes the cost of defects in software testing cannot be measured in money. A bug in medical or military program leads to numerous deaths. Unfortunately, these cases are numerous, too. The USA launches five ballistic missiles, but do they really? Cost: seconds away from starting a nuclear war This is a story about the man who saved the world… by doing nothing. A bug in Soviet’s Early Reaction System displayed a false report about the launch of five ballistic missiles from the US territory. The duty officer Stanislav Petrov, however, considered it a mistake and decided not to take further actions. He thought that if the US forces decided to attack, they would launch more missiles. The accident was included in a report as a false alert. But what happened then? A software error made the system mistake gleams at the top of the clouds for a ballistic rocket launch.  Patriot missile defense complex Cost: 28 killed and 100 wounded soldiers In February 1991, American missile defense complex installed in Saudi Arabia missed a missile strike at barracks. It happened due to the software failure that resulted in tracking inaccuracy, which aggravated due to the long-term system exploitation. By the time of the blow-up, Patriot has been continuously working for over 100 hours. The defense complex predicted the trajectory of an attacking missile, but it was a roundoff error that calculated the time of flight incorrectly, and the defence mechanism wasn’t activated timely. Before the incident, American engineers found this bug that caused inaccurate functioning — every 100 hours of continuous work of the complex resulted in a ⅓ second shift in calculations — and fixed it. The updated version of Patriot software was delivered the next day after the attack. Therac-25 Cost: 4 patients died, 2 received an overdose of radiation In 1982, Canadian company AECL presented a computer-controlled radiation therapy machine Therac-25. The difficulty of testing a part of the software code responsible for estimating a patient's condition led to a failure that resulted in giving massive overdoses of radiation. Six cases were registered between 1985 and 1987, four of them lethal.  The machine had two work modes — direct therapy and megavolt X-ray therapy. In the first case, the electron beam was directed at a patient directly, when the radiation dose wasn’t very high. In the second case, the beam hit a metallic target which distributed radiation beams and then directed at a patient.  Earlier models of the device were equipped with physical detectors of the target presence to make sure the beams aren’t directed at a patient when they are going to receive a large dose of radiation. In Therac-25, physical detectors were replaced by program ones. Due to an arithmetic overload, the system started using in calculations a number that was too high for operations. If it happened during the setup, security systems failed and the target wasn’t placed where it should be, and a patient received 100 times higher radiation than was supposed. QA team found four other critical bugs, which caused synchronization failures and defined wrong setup parameters.  Software failure in Panama City Cancer Institute  Cost: 8 patients died, 20 received an overdose of radiation The series of incidents happened in the National Cancer Institute in Panama City in 2000. The software for radiation therapy planning produced by the American company Multidata Systems International made errors during calculating radiation doses.  Doctors could draw the position of protective metallic disks supposed to protect the body from radiation. The program allowed to manage four discs; doctors, however, expected to use five of them. They found a way to “outsmart” the system: to arrange the disks in a single block with a hole in the center. One thing they didn’t consider is that such order wasn’t mentioned in guidelines. The program calculated the amount of radiation depending on how the hole is drawn and in some cases produced a double dose of radiation.  Eight people died as a result of the mistake; 20 patients received the overdose of radiation. The doctors, who were to check the results before starting the radiation, were convicted of killing. Bottom line What cost of bugs in software testing are you ready to accept? Isn’t it better to detect some issues before you release the product with unexpected features that can cost you time, money, reputation, or even affect someone’s health? You already know the answer, and we know how to release bug-free software.  We value the privacy of each client and cannot share the information about the most serious bugs we have fixed. What we can do is to help you to release high-quality products. Leave a message and let’s discuss the cooperation.

In Biology, the life cycle is the period of time from birth to death. The meaning of the life cycle in software development doesn’t differ much. It embraces all the stages of product existence, from an intention to create a new software solution to an end of using it. Software behaves similarly to a living organism: it appears, evolves, faces difficulties, and sooner or later ends the functioning. For now, let’s try to figure out the basics of the life of software and the role of testing in this process. What is software development life cycle To start with, what is SDLC? Here’s a simple software development life cycle definition: it is a period, which starts with making a decision that a new software product is necessary and ends when the product is no longer used. Explaining SDLC meaning in simple words, this is a sequence of steps required for launching a product and supporting it. SDLC phases Software development life cycle is a structured process that lies in the core of every software product development. Someone identifies a problem, discusses it with a group of like-minded or interested people, they come up with a solution, make drafts, invent something, find and fix bugs. Every step becomes an input to the next action. Altogether, they result in a new product delivered to a customer. Each step is a part of a certain phase. What are the software development life cycle phases? Requirements. SDLC cycle starts from discussions. All the participants come together to share the thoughts on the final product. Their purpose is to determine the detailed requirements to a system, make sure every member understands their tasks, and prevent conflicts. QAs often get involved on this stage. Prototyping, or design phase in software development, brings developers and system architects together. To design a multi-level system, they need to discuss technical issues that may arise and the ways to solve them. A team decides upon the technologies they are going to use, workflow, load, restrictions, budget, interaction with the third parties and databases, etc. Everything is properly documented.   Development. Back-end developers start coding. System admins setup the software environment. Front-end programmers develop user interfaces and the logic of interaction with a server. QAs can start unit tests at this early stage. Testing. We look for the software defects: compare documented requirements with the actual features and search bugs. When a QA detects a defect, they create reports and transfer to developers. The latter fix the bug, then testing repeats. This time, a QA needs to make sure everything has been fixed and hasn’t affected other features. The testing goes on until all the requirements are met and no critical bugs left – a small internal software testing life cycle. Implementation. When no more serious bugs are left, the time for the release comes. An implementation phase in SDLC is when a product becomes available for the audience. Support. If any post-release bugs are detected, the team creates corresponding reports and handles the information to the development. Depending on the difficulty and urgency, some issues are fixed immediately (hot-fix), the others are released in the bext version.  Documentation is a conventional stage. Documents are created on all the stages of software life cycle – some describe development processes and fix procedures, some explain software specs and application. There are four main types of software development life cycle documentation: Architecture (or project) – describes models, methodologies, tools, and means of development chosen for this particular project (for instance, design specifications). Technical – a scope of the supporting files describing the work of the system on the level of separate modules; these are mostly comments to the source code that are later arranged in HTML documents. User – guides and manuals, informational chapters, and things a user needs to figure out how the product works. Marketing – promo materials that introduce a product to the wide user audience in an attractive way, showing all the competitive features and advantages. It is necessary to understand that the stages of program life cycle don't exist separately. There are points of intersection that ensure the smooth transition to every next stage. All stakeholders participate during the entire SDLC with more or less involvement. Why SDLC? Some may wonder why the full software development life cycle is so important for testing and vice versa. That’s simple: testing is not an isolated process. It needs a product – a code or functionality – to check. It also needs requirements to set-up the check. Software development methodologies provide conventional schemes that join together the separate stages. Each stage requires different actions, but all are vital for the final result. It is like a piece of a puzzle in a big picture: one does not make sense without the rest. Benefits of SDLC It creates a full picture of the process – estimating, timing, scheduling, and budget. It is a mechanism for project tracking and management. It provides a specific framework for a standard set of activities. It increases the development speed, decreases risks and delays. It allows participation for all shareholders. It establishes effective communication between the parties with defining inputs and output and the role of everyone in the process. It improves client relations, both between internal and external customers. It is impossible to develop a high-quality product without a plan. And any software development plan is better than no plan at all. In the end, how can you decide whether the product meets requirements if there are no requirements?  What are the 5 stages of SDLC? So how many stages to the software development life cycle exist? There are over a dozen approaches to SDLC nowadays. Different teams prefer to arrange a process according to their procedures, paying attention to documenting some stages more carefully than the others. The five-stage process, better known as the waterfall process, is currently one of the most popular. #1. Requirements and analysis. Clients, managers, and stakeholders opening a brand new SDLC life cycle. They discuss a product, a course of development, and collect requirements. #2. Design. A business analyst document the requirements. A designers prepare the background for further backend and frontend implementation. A QA specialist may start to create testing strategy for a product. #3. Development. Developers divide their work into modules, units, etc., and start coding. #4. Testing. This is when our team starts the main scope of work. The code is partially or fully developed by this time so we can begin the tests based on the documented requirements. This stahe features all the types of testing that can be apllied. We need to make sure the product meets client's expectations, is user-friendlyand bug-free. #5. Maintenance. A company handles the product to a customer. Customers share problems that arise during software exploitation. QAs often detect some new issues on this stage. Sometimes, this stage of development lifecycle is rather passive for the development and QA teams. What are the 7 phases of SDLC? There is one more popular approach, which features 7 stages of system development life cycle instead of the five described before. They come in the following order: planning; requirement collection; designing and prototyping; development; testing; deployment; and operation & maintenance. Technically, it doesn’t differ much from the previous SDLC type, only some accents have shifted. For instance, planning and requirements are two separate stages, while the discussion of the initial idea is viewed outside SDLC in the waterfall process. One more difference in the 7-stage system is deployment outlined into an independent stage. The previous approach suggests that some aspects should be included into the development stage, and some should relate to maintenance. If we speak about the one-time release, however, it would be logical to devote an entire stage to deployment. What is the most important phase of SDLC? It doesn’t matter how you decide to classify the stages, there is no such thing as the most important SDLC phase. Some of software development life cycle phases are long-lasting, some finish quite quickly, some get more attention. Can you miss one of those phases (do not confuse with “unite”) without affecting the entire process? If you need a clearer SDLC example, let’s get back to the biological lifeforms. Think of SDLC as your daily routine with all the basic requirements: sleeping, eating, physical activity, socializing. You can miss something, and your organism will keep functioning, but it'll affect your heath – physical or psychological. In the case of the SDLC, we are talking about software health. SDLC models We hope everything is clear with phases. You may be wondering, what are those software development process models? Is this something different or another division into stages? Software development life cycle models are the ways those stages are arranged. Remember our daily routine example? Some prefer jogging in the morning, some in the evening. There are people, work better after a walk, while the others find it difficult to concentrate in open space after 15 minutes outdoors. The same thing with SDLC models. There is at least a dozen that are popular and frequently used. The choice depends on expectations and requirements to the final product, project specs and scale, and company policies. Software development life cycle models The roots of the software development get back to the 1960s. Over 60 years of evolution with extremely rapid changes over the last two decades resulted in a wide variety of development strategies, methods, and of course software development life cycle models. We aren’t going to explain each of them, but here are some of the most used SDLC phases with examples of advantages and disadvantages. Waterfall Model The name “waterfall development life cycle” already explains a lot. SDLC waterfall means that phases come one after the other. To proceed to the next stage, you are to finish the current one. Every phase of a project takes place only once. Pros: A strict order and a well-structured process with least surprises. Opportunity to plan deadlines and resources accurately. The requirements aren’t altered during the process. Cons: A lack of flexibility and difficulties with too strict requirements The testing starts only in the middle of the project. Impossible to detect strong/weak sides and product value before the release. V-model Similarly to the waterfall model, it allows getting rid of the problems detected on the preceding stage. The processes on all stages are controlled to make sure that it is possible to move to the next level. The testing stars during writing the requirements. Pros: The strict order of following the stages. Better time management. Minimum risks and opportunity to prevent major errors thanks to the testing on early stages. Cons: Impossible to adapt to the continuously changing client’s requirements. No actions are devoted to risk analysis. Time-consuming development that sometimes lasts for years may end up in a situation, where a project is not relevant for the time/audience or not necessary for a client. Incremental model The software development process is linear. Every stage follows the previous one, but in several increments (versions). Product enhancement lasts in a planned order for as long as the product exists. System requirements are defined at the very beginning of the work. After that, the development process flows as a sequence of versions, where every next one is a finished and fully functioning product. Pros: Clients can leave reviews about every version of the project. Opportunity to predict risks related to expenses and stick to the schedule. The adjustment to the new technology happens gradually. Cons: The functional system should be fully outlined at the beginning in order to determine the iterations. In the case of constant changes, system structure can be damaged. Deadlines and release dates can be missed due to the limited resources (both executives and expenses). Spiral model Staring at the stage of planning, SDLC unfolds with every next step. After the exit of each next volution, we receive a tested prototype, which complements the current version. A prototype that gathers them all and meets the requirements is ready for the release. Pros: Special attention is devoted to risk management. Additional features can be added at the late stages. There are enough opportunities for flexible designing and prototyping. Cons: The risk estimation on every stage requires a lot of resources.   Continuous reviews and customer feedback trigger never-ending new iterations that significantly delay the release. More applicable to large-scale projects. Agile model The Agile development life cycle is a mix of various approaches. It is very dynamic and based on the constant interactions inside the self-managed working groups. These groups consist of the specialists of diverse profiles and deliver mini projects at the end of each iteration. One of the key ideas of Agile software development life cycle is interaction with a customer face to face. Pros: Fast decision-making thanks to continuous communications. Minimization of risks thanks to the instant reaction to problems and fixing them. Easy documentation management. Cons: A big number of talks and meetings can increase the time required for the release. It is difficult to plan the process, because the requirements are constantly changing. It is rarely used for the implementation of large-scale processes. Which SDLC model is best? It all depends on a particular project and company. Regardless of system life cycle models applied, teams use some well-tried practices to reduce the risks and increase efficiency. Source control helps to reduce the risks when it comes to coding and testing. A single server failure can ruin the achievements of an entire working day, while central repository saves the day. Continuous integration keeps the software in the functional state. By assembling a program every time the code changes, you prevent errors and defects in the final version. Management systems make complex projects easier to track. There is an entire class of software systems that assist in work management, bug tracking, even decision making. The best way to choose which model fits best for your project is just to communicate with the dev and QA teams. Theycan explain SDLC models with real time examples, provide some insights, share experiences. It will be much more important than trying to figure it out by Googling the existing methods.  Examples of SDLC, or how to launch a spacecraft So you already know biological life cycle definition and the one used in IT, the basics of SDLC methodologies and phases. Sounds like it’s time for the SDLC phases with examples. To make it easier, let’s draw an analogy between the stages of software development life cycle and a school project. You are informed about the upcoming school fair,  where student will present their crafts and inventions.  You decide to make a checklist to keep an easy track of the process and choose the 7-phase model. #1. Planning. Think about possible options. What are you good at? What are other kids good at? What will help you to stand out? It is probably an awesome spacecraft model. You know about the space much more than any other kid. Your school lacks spacecraft models of proper quality. You will solve this problem. #2. Requirement collection. You check out if other kids have presented similar projects. Then you find out what spacecraft models exist, what materials are available, how much time you have, when and where the fair takes place – as much details as possible. #3. Designing and prototyping. You take a sheet of paper and draw your model. You make it using low-cost and easy-disposable materials – paper, matches, etc. You see the plan is going to work out and move to the serious work. #4. Development. Time to make exactly the same model by using proper materials. #5. Testing. You check whether all details are fixed and glued well, whether your spacecraft model looks the way it should. If it doesn’t, you need to spend some time on removing mistakes. If yes, well, congrats! #6. Deployment. You have spent much on creating a beautiful but fragile model. Everything is ready, you just need to get safely into and out of parents’ car carrying it safely. And you check it once more before showing to a teacher and all other students. #7. Operation and maintenance. Now, everyone is looking at your spacecraft. People ask questions, say it is awesome, some say it is ugly and unnecessary. Don’t worry, this is life and this is how it always happens. You keep an eye on your project till the very end of the fair. The spacecraft has completed its mission: you get a high grade! The lifecycle of your project ends. How do we choose an ultimate SDLC in UTOR? We work with very diverse teams and projects, and each of them requires a specific approach. Agile works best for small companies and dynamic projects. A waterfall model is perfect for short-term projects, while an increment model is used most frequently for long-lasting products, where developers keep working on updates continuously. To decide what approach to choose for a particular project, we discuss the working process with the team on your side. As a rule, we jump on a project when the development is in the height or is coming to an end. We pick up the tasks and ensure seamless integration, particularly,  be using the SDLC you've already chosen. It doesn't matter what SDLC you currently use. We'll be able to keep up. Contact us to discuss all the details.