Web is the critical part of any business today and more so when you do transactions using the web as a medium. There are three critical factors that become important such as availability, confidentiality and integrity of the data. It becomes mandatory for every organization to take a proactive web security approach to safeguard themselves from any attacks that jeopardize their business and erode brand value.
When it comes to web security, there are broadly three types and there are different ways by which they can be addressed.
- Network level security – at the data center level, this can be hardened through usage of industry-grade firewalls and authentication services. This is in addition to the hardening of the operating system used, kind of frameworks used for the web etc.
Often, insecurity sets in when outsourcing product development to a 3rd party development company. If done right, the partnership will be very rewarding and will help you release quality products to market faster. In this post, I have covered 6 simple ways by which product outsourcing can be made successful.
1. Leverage an in-house architect who has control in specifying the roadmap for your product development. Doing so will help you clear the requirements, build the specification, determine what technology to use, and scope the architecture so that it can be safely outsourced
2. Outsource development while keeping product definition, systems architecture and quality assurance in-house
3. Keep it agile as this will allow the outsourcing organization to continue managing the requirements and have the flexibility to change the requirements when needed. The critical success factor here will be whether the development team is able to deliver what it is committing for every iteration
4. Set expectations upfront and have timely communication. It’s also important to ensure availability to communicate. This will help the project run smoothly and make necessary adjustments
5. Define measurable project deliverables so that performance and quality can be monitored
6. Share your product roadmap, customer inputs and customer successes with the provider
Business logic tells you to develop fast, show results faster, enhance time-to-market, and fix later. This process is commonly followed by most development teams. Proper testing and the automation of it may be viewed as conflicting to business logic. However, we believe the only way by which products can be built to scale and ensure future releases that are successful is by ensuring and enhancing quality. You cannot build high quality products on top of poorly built legacy code. Also, buggy products will drain more resources than what was originally planned.
Quality automation testing that can be used during development includes:
Automated unit tests – Nearly all of it can be automated, however efforts are required in designing and maintaining the tests. It provides assurance that low level code is correct.
I was involved in a discussion last week where this question cropped up on whether agile development adds value to a re-engineering effort? It got me thinking, so I probed further and I figured out that all that was being discussed was adding enhancements and sanitizing the software of unwanted features.
I believe that agile absolutely adds value here, so I started thinking whether this can be applied towards a quantum re-engineering effort as well. The answer to that is also an absolute yes, however with agile it may not be necessary to re-engineer the product on the whole. Even if we should, we can prioritize which portions will be re-engineered in order to achieve better results.
Whether you are developing a new product, re-engineering a product, or adding enhancements to a product, agile can add value to all these initiatives. The easiest way to use agile development is to follow these steps:
Toyota recalled approximately 133,000 2010 Prius and 14,500 Lexus vehicles in the U.S. recently to update software in the vehicle’s antilock brake system (ABS) because of uneven braking. This recall was necessary for the issue would harm those in the car should it occur.
The weak link in a car’s software is not a virus or ill-behaved third party application, but the computer code and how it responds, or fails to respond, to unforeseen conditions. The computer running the software is designed to do just one thing, and is not a buggy device. This example illustrates how critical software is, for it not only results in lost profits and lost brand loyalty, but potentially lost lives.
The requirements for managing a product or service workflow must be documented. However, when the number of requirements grows and the document becomes lengthy, readers find it difficult to review the entire document. Beyond a certain point, they rarely read the document again completely, or if they do, they skim over important sections without critical analysis.
It is therefore useful to express the requirements as a prototype. Doing so takes several pages of written requirements and represents the content visually in the form of prototype screens. Prototypes themselves can take many forms. A common way is to use HTML prototypes that represent web applications. Some professionals use a drawing program or even regular paper for their sketches. Others like to use Photoshop to mock up a prototype GUI, the advantage being that people will not confuse the prototype with the actual application.
Software is pretty complex and there is very limited understanding of its principles. Most defects in software are design errors, not production defects. Complications also arise from the dynamic nature of software programs. Often, testing has to be restarted after the preliminary defect is fixed and the associated costs can be prohibitively expensive.
Despite the challenges, testing is an integral part of ensuring a quality software development cycle.
Ensuring software quality is not about finding bugs and defects. These complications are directly related to the code that is written. Quality means complying with the business outcomes expected of the software. Factors that need to be assessed are:
- Functionality – correctness, reliability, usability and integrity
- Engineering – efficiency, testability and documentation
- Adaptability – flexibility, reusability and maintainability
Test automation is not about removing testers but to make use of their time better. It is impossible to automate testing completely, and it has to be a mix of automation and manual testing. If you have decided to automate testing, below are some practical tips for implementing any test automation initiative:
1. Focus on the methodology and not the tool
A clearly defined automation methodology that covers how the automation process will be conducted can eliminate most of the frustrations associated with automation by providing stakeholders with an upfront understanding. This would provide a fair idea on what is needed to automate tests, which includes tool selection as well as the rest of the automation process.
2. Choose tools that are scalable to meet future needs
- Test automation is expensive and takes ages to justify the investments.
- Automation resources are top-heavy and would mean a lot of upfront costs.
- Product roadmap is not clearly defined and we aren’t sure if automation is appropriate for us?
These are some of the initial reactions that we get to hear whenever we think of test automation. These reactions aren’t unfounded and it merits careful assessment.
Some questions to consider before deciding to automate are:
- Is your product fairly stable and do you have paying customers for its initial version?
- Does the product have a clearly defined roadmap?
- Does every version upgrade, both minor and major warrant running all the functional tests over and over again? Essentially, the test scripts would be re-used multiple times justifying the investments
- In most ISVs, developers double up us testers and there is no formal testing process in place
- Due attention is not given to QA and is looked at only when schedule and time permits
This is most likely to result in increased rework, decreased customer satisfaction, increased support and product maintenance costs. Independent testing or 3rd party testing, as it is famously called can help ISVs in addressing the pains listed above.
Some of the reasons that substantiate usage of 3rd party testing by ISVs are:
- Good software development practice calls for separating the development team from the testing team. This allows provision of unbiased view of the product quality and greater visibility of product issues. It also reduces direct staff costs for the ISVs who do not have to staff QA internally.