August 11, 2021

Solving 3 Pervasive Enterprise Continuous Testing Challenges

A primary goal of continuous testing is to determine if a release candidate is ready for production. As described above, you absolutely need to ensure that the changes in each release don’t break existing functionality. But you also need to test the new functionality to ensure that it works and meets expectations. Making the ultimate go/no-go release decision can be a bit of a guessing game when different teams are responsible for different components and layers of the application: the browser interface, the mobile experience, the various packaged apps at work behind the scenes (SAP, Salesforce, ServiceNow), and all the microservices, APIs and integration platforms that are probably gluing it all together. They’re likely developing new functionality at different cadences and testing their parts in different ways, using different testing practices and different tools. But the user doesn’t make those distinctions. They expect it all to just work, flawlessly. Mo?t Hennessy-Louis Vuitton (LVMH), the parent company behind luxury brands such as Christian Dior, TAG Heuer and Dom Perignon, recently decided to streamline its testing process to support ambitious plans for e-commerce growth.

Mind Over Matter: Revamping Security Awareness With Psychology

It's clear that traditional approaches to cybersecurity training have failed. From mistakenly disclosing account information to falling for phishing attacks, time and time again, an organization's sensitive data often leaks through legitimate channels with a worker's unknowing help — demonstrating that cybersecurity is increasingly a behavioral challenge. Instead of clinging onto measures that have repeatedly proven to be ineffective at safeguarding organizations, security leaders must redesign cybersecurity awareness with the human mind at the forefront. For that, we must turn to basic principles of psychology so we can better understand human behavior — and how we can positively influence it. While it's nearly impossible to unlearn these biases, we can improve our employees' understanding of cognitive biases to make it easier to identify and mitigate the impact of psychologically powered cyberattacks — and ultimately facilitate changes in individual cybersecurity behavior.?

Chaos Malware Walks Line Between Ransomware and Wiper

Chaos became more ransomware-ish with version 3.0, when it added encryption to the mix. This sample had the ability to encrypt files under 1 MB using AES/RSA encryption, and featured a decryptor-builder, according to the researcher. Then, in early August, the fourth iteration of Chaos appeared on the forum, with an expansion of the AES/RSA encryption feature. Now, files up to 2MB in size can be encrypted. And, operators can append encrypted files with their own proprietary extensions, like other ransomwares, according to the analysis. It also offers the ability to change the desktop wallpaper of their victims. Ransomware has been on the rise so far in 2021, with global attack volume increasing by 151 percent for the first six months of the year as compared with the year-ago half, according to a recent report. Meanwhile, the FBI has warned that there are now 100 different strains circulating around the world. The most-deployed ransomware in the wild is Ryuk, the report found, which could account for why the Chaos authors attempted to ride its coattails.

Cybersecurity is hands-on learning, but everyone must be on the same page

Most times, we see that cybersecurity “budget” is spread throughout so many other budgets throughout a company or organization. It isn’t owned within a cybersecurity group. This leads to separate strategies, goals, and implementations of cybersecurity thus really wasting that budget entirely. The larger problem of having no cybersecurity budget because “we’ve never had an incident” or “we aren’t a big enough target” is one that many will regret when it is too late. Everything and I mean everything is largely reliant on the internet these days. I challenge companies to start thinking about their most valuable assets, those assets that if they were to disappear or be messed up they would likely have no company. I can guarantee that most of those assets sit on a computer system somewhere. May that be a water system, the grid, a chemical formula, a shopping system, cloud infrastructure, data feeds, medical records, personal records, etc. Look at the cybersecurity budget as one would for regular home maintenance.?

Agile or Waterfall, which method should project developers adopt?

The IT and software industry was amongst the firsts to adopt this approach as often the end objectives (what their customer wants) keep changing and the flexibility afforded by the agile methodology is welcomed. With the successes achieved in various projects, eulogies have been overflowing for the agile method. With almost every industry evolving fast, gross uncertainties, and if the product under development is late to the market, the calls to adopt agile grow. It is impossible, on any given day, to not come across some article that attempts to show how agile can be adopted in yet another industry. The traditional approach adopted by most industries has been the waterfall method where the objective of the project is known in advance and the project progresses through identified stage gates. ... There is a plethora of reasons: new products, new processes, change in businesses, and so on. The decision on whether to proceed with a waterfall or agile method is more seen in product development projects where a company plans to enter a market with a product but may need to change track midway if market needs and expectations change.

Improving Testability: Removing Anti-patterns through Joint Conversations

There are many code patterns and anti-patterns that we know are good (and bad) for developers. Usually we look at them in terms of maintainability. But they have an impact on testability as well. Let’s start with an easy one. Let’s say we have a service that’s calling a database. Now, if the database properties are hard-wired into the code, every developer will tell you that’s a bad thing, because you can’t replace the database with an equivalent. In a testing scenario we might want to call a mock or local database, and hard coding a connection will impact our ability to either run the code completely, or call another one. In what we call pluggable architecture it’s easy to do this, but the code needs to be written like that in the first place. That’s a win for both testers and developers. In fact, many clean code practices and patterns improve both code maintainability and testability. Now let’s take a look at another aspect of pluggability. Our service now calls three other services and two databases. But we’re not interested in checking the whole integration.

Read more here ...