On and off you come across the battle of performance for your application and most of us don't take load testing seriously until it has raised some red flags. Yeah, that's when we all start to talk about performance and testing applications, monitoring all the shit which is happening, looking at the speed at which data is loaded and RPS of API is critically looked to make judgement. We all know about Load testing but yet very few of us really invest in it and mostly just live on the unit tests.
I am also sure that most of us would have come across a group which believes in testing things only once and then forgetting about it has really damaged our reputation and invited you to a meeting with the CTO or CEO of the company. I mean as a dev we change so much on a monthly basis in any application and its UX for users that at times we don't seem to remember all of it and the business reasons behind it. This blog post is not out of frustration but more about understanding the importance of Load Testing and why its done, the basics, what you need measure and do's / don'ts, etc. What is Load Testing: Load testing is the process of putting simulated demand on software, an application, or website in a way that demonstrates its behavior under various conditions. It used to be a simple pre deployment exercise to ensure a web application could handle the load of multiple users and is slowly becoming an integral part of software development and continuous performance improvement. As websites and web applications become more innovative and complex, load testing poses a significant challenge for teams to 1. Execute properly and 2. Cover all the bases. As a result, load testing needs to be done more frequently, more effectively, and more efficiently. It’s also created a need to simply train more people in the basics of load testing. Given that our lives increasingly rest on apps functioning properly -- whether it’s in medical devices, transportation, communications, defense, or entertainment — app performance has never been more important. We’ll cover:
0 Comments
We have all gone through this cycle of vulnerability detected and patches applied in our careers. Some of us still go through this vicious cycle of tense, challenging and nerve wrecking moments when you are racing against time and people in business are asking for updates while the customer support is assuring the customers with eyes on the screen waiting for the announcement "Patch Applied", "Service Restored" etc Software Patch and Vulnerability Management continue to be a major challenge for many organizations. There is no single software product or vendor source of these vulnerabilities. Organizations must consider patching at all levels of software and only applying Microsoft Patch through Tuesday updates to protect systems and data from cyber-attack is not sufficient.  Organizations that were diligent with Microsoft patches avoided WannaCry related ransomware. However, flaws with Apache Struts and Intel Processors left organizations vulnerable to cyber-attack (e.g., Spectre and Meltdown).
A lot of software companies have elected to stop providing individual patches each release period. Instead, separate and distinct patches are bundled in a roll-up model. The reason for this change is to prevent patch fragmentation that led to problems like dependency errors, lengthy scans, and testing complexity. This practice has created an all or nothing condition for customers in which selecting individual patches are no longer available. Further, software companies are building these patch bundles in a monthly rollup manner. These patch bundles not only contain all the recently announced patches, but also the previously shipped patches. This cumulative update model is intended to improve security, quality, and reliability. Yes i am referring to the Microsoft and Adobe model, however with this model in practice comes the requirement for customers to perform extensive application program compatibility testing in a short period of time—especially when functionality and non-functionality (i.e., security) code changes are mixed in the update. The days of cherry-picking patches are over. Orchestrating patching is complex and costly. Patching has many dependencies including asset management, notification tracking, risk assessment, patch preparation, QA, release management, communications, and auditing. As with the installation of any software update, many teams must collaborate to ensure success and avoid unintended interruption of service. If any of these teams are not resourced and prepared for this demand, then patches are not properly tested and announced prior to deployment creating availability and integrity risks. If patch deployment is delayed to perform necessary QA and communication, vulnerabilities linger longer for cyber- criminals to discover and exploit. Traditional operations and project management methods of patching are not nearly rapid enough. Sadly most organizations claim to have adopted the Agile methodology which is an iterative approach to software development and delivery but fail to address when it comes to the needs of patch upgrades and its mostly neglected until an incident takes place. I'll try my best to summarize how Agile can be implemented for patch vulnerability assessment and the structure through which you will be able to maintain pace as well as deliver quality. |
Archives
February 2020
Categories
All
|
RSS Feed