Software architecture represents earliest design decisions that are hardest to change, is a communication vehicle among stakeholders and are the most critical to get it right.

Architecting the software right ensures the business goals of high quality, quick time to market, effective use of limited resources, optimal leveraging of available skills, low cost production, low cost maintenance and mass customization, which results in improved efficiency and productivity.

In a rush to shorten the learning curve related to tools, technology, frameworks and processes and to get the development completed, very often basic development guidelines and quality attributes are ignored. Several transversal functions are unstated and are not met; basic principles of object-orientation and modularity are ignored. This is discovered too late in the cycle and this results in loss of quality of the software.

Architecting the software right allows you to create a template for significant parts of the code, say the primary types of components, thus ensuring that the common concerns such as modularity, error handling, logging and other quality attributes are met while ensuring that the developing team has a short learning cycle. This will allow them to get started quickly ensuring the business goals of quick time to market at lower costs are met.

Architecture driven development will ensure that software developed will be useful for the target audience accounting for the quality needs while adding value to both the user and the producer.

We can define software quality thus, it is a part of each phase of the development life cycle including testing and encompasses a whole load of factors and not just bug-free and aesthetic software. These factors that are a combination of tangible and intangible sum of quality attributes like functionality, reliability, usability, efficiency, maintainability and scalability forms an important part of the software.

A bug free, aesthetically appealing product that fails to solve business problems of the target audience for which it was designed is a poor quality product. Essentially, software quality is about meeting user needs and it is about the quality attributes as much as it is about being aesthetic and bug-free.

An improved Software QA process has the potential to affect both the users and producers by:

• removing more bugs before the software is released
• detecting bugs earlier in the software development life cycle
• locating the source of bugs faster and with more precision

This will reduce high re-working costs on the software and will help improve user satisfaction

Pair Testing gains the advantage of analysing the root cause of major bugs easily and since the tester is aware of bug root cause, he/she may start with exact test scenarios to capture bugs and can easily test the initial bug fixing status with the developer. The tester can learn more about the software application by exploring with the developer.

The following would be the gaining points when Pair Testing is followed

1. Developer or business analysts approach the software from a different view. They think in good paths, for example “I have to create an address and edit the fields.” The testers will also look at the exceptions, for example “What happens when I create an address and press cancel instead of save…”
2. When Pair Testing is executed with a business analyst there will be automatically knowledge sharing between the business analyst and tester. The business analyst will share his knowledge of the application of business with the testers during the session.
3. If a new project is started with new team members there will be often a gap between testers and developers. By using Pair Testing the team members will work closely together and get to know each other better.
4. Working in Pairs keeps us sharp, we cannot doze off. We will keep each other sharp.
5. If we find problems and decide to register them in a bug registration system, the problem is automatically reviewed. We work in pairs, so the data we entered is immediately reviewed by the other one.
6. As a tester we will encounter mysterious bugs that seem to occur at random. In a Pair Testing session with a developer we could find a pattern and thereby the cause of the bug. The developer will probably see the link between the problems because he has knowledge of the software framework.
7. The last reason to use Pair Testing is maybe the most important one: It is fun; working together with team members is fun.

Though Pair testing has so many advantages, there are some situations when this will not work out. Some of them would be

1. All executed test should be automated. Since, the result of Pair Testing is findings and no test cases; we cannot use the output of a Pair Testing session directly for test automation.
2. Team members cannot work together. If we have two team members who cannot work together because their characters clash we should not go for Pair Testing. The team members must be able to communicate well and work together without quarrels.
3. If we are only going to execute structured test cases. It does not add any value execute the test cases together. This kind of tasks can be done by one team member alone.

To conclude, Pair Testing is a combination of working together and testing. However, it has a lot advantages above “single” testing. There will be knowledge sharing (about testing and the Software Development process), to train new team members, break down barriers between team members. Still we need to be aware that we should use this testing only when possible and use it wisely.

There are some situations which really makes the QA users and project managers to think about importance of non-functional testing for their products. A few of them would be

• Multi-user application that has tones of great functional features but simply crawls or frequently hangs up when several users try to use the system
• A web application that works best only in a limited set of browser types and versions on limited platforms and unfortunately there are users using and comfortable on other versions of browsers and platforms
• An application that has sensitive data but is fairly easily susceptible to security breaches and exposure of sensitive information
• Product containing excellent features, but vague for real time usage Actual Users because of poor user manual documentation
• Project is fully complete and deployed in production systems but users could not able to access the system

In the above scenarios, the tester role is not only limited to test the product against the client specification, but also to verify non-functional requirements. Non-functional risks need to be evaluated and considered during project planning. During requirements phase, both functional and non-functional requirements need to be spelt out and considered by both development and testing teams. The following testing can be considered as a part of non-functional testing and should be performed for a successful delivery of a product and to help the marketing team for a better sale

• Perform Load Testing to see, how the product behaves under heavy stress/Load. Try to load the system with many users and complicated actions
• Calculate the System performance and Response time and ensure product has good performance even during network traffic
• Carry out installation testing and verify the product is easy to install without technical expert intervention. Even if it requires, make sure it needs minimal external guidance
• Perform Stress and Volume testing to product
• Concentrate on compatibility testing and ensure product behaves consistent in all most widely used browsers and operating system
• Check for Security Testing which includes Application Security, Network Security, System Security
• Give importance to documentation testing and verify User Manual Guide, Release notes are reflecting latest updates and highlights

1. Wasting our time to report bug incorrectly and additional time to correct and rewrite it
2. Wasting the time of other people who review it and trying to make sense of what we wrote
3. Reduce our testing professionalism, by writing a bug that is correct but incomprehensive

The following components could be considered for a good bug reporting

1. Short and precise title
Each bug should have its individual title. The title gives us the opportunity to quickly understand and remember what the bug is all about. The title cannot be generic (e.g. Error on Application), or too long. It should be one sentence, providing the highlights of the issue and the way to understand how a user could run into it.

2. Concise but complete description
The description of the bug is where the tester can express his artistic sense and write what he thinks will help developers/business users to understand and handle the bug. Items like Steps to reproduce, consequences of bug, and suggested behavior can be included in the bug report

3. Good attachments
Attachments always help the testers in forecasting the issues to developers. This is especially true when we need to show GUI malfunctions, error messages, and/or log files that compliment the description of our bug. One thing to take into account is to provide only the relevant information in attachment. This means that if we have a long log file we can attach only what we know is relevant and not all of it, and capturing the error screen part instead of pasting the entire screen window, etc. Use also zip files and compressed formats as attachments in order to save space.

4. Complete definition of the categorizing fields
Information like Module, Infrastructure, Browser, etc. related to the functionality, in which bugs was found can be described.

5. Correct Severity & Priority Another big Tester Sin is to over prioritize bugs. Obviously tester is happy when he found a bug and want it fixed, but giving it the wrong severity will only make the person in charge of the bug angry and it will lower the chances of having this bug fixed. Creating and using a Severity Lookup table for bugs will really help testers to place correct and appropriate severity bugs

An example of a Severity Look-up Table that could be used will looks like below

S1 – Critical
A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround. We can note down the important bugs that were reported from customers and we assured them will be fixed.

S2 – High
The defect causes a part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users. High visibility GUI issues can come under this.

S3 – Medium
The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users.

S4 – Low
The defect causes no dysfunctions to the system and may even be unnoticed by most users. The bug has an easy workaround or may not even require a workaround at all.

S5 – Enhancement Request or Suggestion
The items which the tester thinks, that it could be enhanced

6. Follow-up and comment.
We should continue following up on our bugs, and providing comments when necessary. This is especially true when a developer or other stakeholder does not understand the bug, and either rejects it or delays it.

When the above components are followed while reporting bugs, this will improve the tester efficiency and reduces the bugs being transported from QA and Development team.

When facing a limited time frame available for testing, we need to effectively use the available time and resources. Starting the testing of the project with an assumption that “We can’t test everything, no matter what” will really help in prioritizing tasks. Do a risk analysis to identify functionalities with the highest risks and functionalities that will be used by the maximum number of users. Do an analysis about what to test first and in which sequence.

Also, preparing a checklist that focuses on major key areas covered during testing will help testers, by ensuring that they are not missed out in the tight scheduled testing. The checklist should cover

• Functionalities that are most visible to users and those which are frequently used.
• Functionalities that are very important for the intended purpose of the project.
• Areas that contain more risk, i.e., those areas/items when broken, will bring the entire application down to ground
• Newly added functionalities, since they are the least tested ones
• Complex functionalities that are easy to misunderstand
• Functionalities that had recent updates or bug fixes
• Functionalities that were developed under schedule pressure
• Functionalities that could cause the most customer support complaints
• Functionalities which, if they go wrong, could result in bad publicity

This is clearly not the only exclusive list of guidelines to test under tight testing schedule. But still, it covers many important areas that usually need attention. With the available checklist, proceed with testing the project and help the team deliver the project in time with the expected quality output.

What is UAT (User Acceptance Testing)?

The explanation of UAT is in its name. Taking each part separately explains what it is about.

• User These are the real business users, who have to operate the system – usually the staff of an organization. System developers cannot play this role, as although they are expert at writing software, they are unlikely to know the nuances and the realities of the organization, beyond what they have acquired from the requirements specifications and other documents.
• Acceptance Acceptance means giving the confidence to the client that the product delivered will benefit them by satisfying their actual requirements and expectations.
• Testing Though the most common explanation of testing is to prove the system works, I would say a good test is also one that is designed to try and make a system fail, so as to expose its faults before it goes live.

Bringing all the three together, the UAT can be explained as business users checking the system in the context of the business environment to ensure requirements satisfaction.

Why is User Acceptance Testing Required?

The simple answer would be protecting the product/system from harm while at the same time reducing Reputation Risk, Time Risk, and Resource Risk. Therefore the main reason for UAT is to identify what a system will do and how it will benefit the client before it is implemented in their live environment.

How is User Acceptance Testing Performed?

• The QA team creates a Test environment using the Client Live environment as a base and deploys the product and/or its enhancements.
• They engage and coordinate with the client to provide information about the new features that are part of the release.
• They hand over the Test Scenarios created for internal Testing to client to validate with their business requirements.
• They assist business users in executing the Test Scenarios (and others as the client may determine) and confirming whether all requirements are satisfied.

What are the Benefits of User Acceptance Testing?

Apart from the major benefit of the client gaining confidence in the system, benefits include

1. Reduced system failure risk in Live Environment
2. Reduction in bug count reported from Production
3. Better understanding of process workflow by actual users

Using advertisements has two parts: first, developing the advertisements for the iPhone and second, developing the iPhone application to show these Ads. Regarding the advertisements, these will be interactive as well as live (with videos, games, maps etc.) But the best part for developers is  the development of iPhone applications in which they can create banners to display these advertisements.

The selling and hosting of ads will be done by Apple. The developers can create applications using the classes and methods for iAds in SDK and allot space in the user interface to show these advertisements. Apple is sharing 60% of the revenues through such applications with developers. The model basically works based on the clicks and views of an advertisement through an application, similar to web advertising (note: Ad Sense).

The developer can use the ADBannerView class and its delegate methods to integrate iAds in their applications. They can allocate banner space of sizes 480 x 32 for portrait and 320 x 50 for landscape. These sizes can be achieved using the pre-defined constants ADBannerContentSizeIdentifier480×32 and ADBannerContentSizeIdentifier320×50.The delegate methods like bannerViewDidLoadAd and didFailToReceiveAdWithError should be implemented to handle the various actions while an Ad gets loaded or a banner fails to receive an Ad.

iAds is a tremendous help to iPhone application developers to allow them to make money through facilitating advertisements through their applications. This model is expected to revolutionize iPhone application development.

Reference: For more details on ADViewBanner click here

I assumed that the ten companies he was mentioning would be Microsoft, Oracle, IBM, SAP, HP, Adobe, Nintendo, Symantec, EMC and CA. These would anyway acquire the remaining players.

The challenges that application software vendors face are:

A. There is an open source offering in every segment that you operate

B. The big players bundle your offerings as an add-on to their enterprise offerings

Either way, the software vendor would find it difficult to survive and be profitable. Essentially, you either have to be big or have a really differentiated offering that others including the big boys find it difficult to offer. This means, they either join hands with you through partnerships or acquire you to add  capabilities to their offerings.

I see a lot of entrepreneurs today having acquisition as one of the key exit strategies. They even plan for it, but how successful they are when it comes to such plans are not clearly known. If you have to keep yourself away from getting acquired, then you have to be self funded or you have a differentiated offering, which is obscenely profitable.  Else, you have a 50x valuation, which any of these biggies will find it obscenely pricey and stay away from it.

This form of consolidation, is it good for the industry? Good or bad, it is inevitable as big guys want to grow bigger through both organic and inorganic routes. This is anyway not the end of the road for application software vendors, as more and more companies keep coming up with differentiated and innovative offerings, which will keep challenging the established ones. They in turn, would get gobbled up and the cycle would continue.

If you have noticed, the funniest part of this post is that I have not even touched on the poster boys like Google, Sales Force etc. and that gives me hope.

The iPhone SDK has provided developers with the MFMailComposeViewController class, which can be used to display a  standard interface that manages the editing and sending of an email message. This UI will have the facilities to add recipient mail ids in To, Cc or Bcc. There are options to specify the subject line and type in the content of the mail. The user can edit the initial contents you specify and choose to send the email or cancel the operation.

MFMailComposeViewController class also offers methods (such as addAttachmentData) to add a file/data as an attachment. This method supports most file formats. The file format is passed as a parameter (mimeType). The mimeType is generally divided into categories like 

• application – formats like json, pdf etc… comes under this type
• audio – most of the audio formats comes under this type
• image – most of the image file formats are under this type
• text – formats like csv, css, rtf, xml, rtx etc…
• video – most of the video formats are under this type.

So the mimeType for a CSV file will be specified as “text/csv”. Along with this, we will pass parameters for data as well as the filename to be used for the attachment.

The user can click on Send button in the UI to send the mail. The didFinishWithResult method, which is a delegate method of MFMailComposeViewController class can be implemented to get the status of the mail sent (like MFMailComposeResultCancelled, MFMailComposeResultSaved, MFMailComposeResultSent, MFMailComposeResultFailed). This status can be used to further handle or alert the user regarding the mail they sent.

Thus the developers can easily make use of the iPhone SDK to implement the mailing facility in their own application, which will add more value and make it more user-friendly.

References: More details on mimeType – http://www.iana.org/assignments/media-types/