Using Microsoft Azure as the Back-end of your Mobile App

When building a mobile app chances are you’ll need some sort of server in the back-end to manage security, data, and likely to integrate with another system. We see a lot of potential in using Microsoft Azure for this purpose.

What is Microsoft Azure?

Azure is Microsoft’s answer to the cloud. It’s a scalable, pay-as-you-go service. Developers can connect their apps to in order to provide a robust back-end without having to buy hardware and manage back-end infrastructure. And the best part? In addition to supporting Windows Phone, it supports iOS and Android enabling you to create a platform agnostic back-end.

windows-azure-mobile-services Using Microsoft Azure as the Back-end of your Mobile App

A conceptual diagram of Windows Azure Mobile Services.

 

What can you do with Azure?

As illustrated in the diagram above, Azure provides a flexible back-end that can be used to build in some very common requirements. By using Azure (or similar services), developers can quickly produce a prototype that has the ability to scale to a production system. Without having the upfront investment typically required for hardware.

Security

Azure offers the three levels of security required by most apps: Authentication, Authorization, and Encryption. This essentially covers the requirement of having a mobile user log onto the system, access only data they’re allowed to access, and have that data encrypted along the way.

Notifications

Azure has a robust notification service built in through their partnerships with SendGrid (for email) and Twilio (for SMS). By partnering with these two providers, Azure gives developers a single platform to access both. If you’re looking to build an app that requires push notifications, email, and SMS, a back-end like Azure will be required to support it.

Scalability

One of the major promises of “the cloud” is scalability. By building on the platforms provided by vendors like Microsoft’s Azure, Amazon’s AWS, and Google’s Cloud Platform, your app can be designed to grow with your needs. The pay-as-you-go or usage-based models means that upfront investment is minimized and you only pay for what you use.

Data Sync

Not clearly mentioned in the diagram above, but a very important aspect of Azure, is the built in data synchronization frameworks. Microsoft Sync Framework Toolkit which supports Windows Phone, iOS, and Android. This framework will make it easier for developers to create an interface between the mobile app and the database through a REST/JSON based API. The sync framework then will then perform synchronization over OData to make it easier to keep both the mobile device’s storage and the back-end’s in sync. iOS has a built in solution to this called iCloud. However, iCloud is iOS only so if you’re planning on building a multi-platform solution, iCloud may not be worth the time.

Microsoft has a great video on using Azure as the back-end of your mobile app. It is a must-see for anyone considering Azure and wanting to know its capabilities.

Image credit: MSDN

 

Note: This blog post has been updated with new information.

What to Include in a Software Testing Traceability Matrix

A Software Testing traceability matrix is an essential tool for any thorough software tester. It should be referenced throughout the entire software development life cycle to bring transparency and completeness to software testing efforts.

Software Testing Requirements for Traceability Matrix

In simple words, a testing requirements traceability matrix is a document that traces and maps user requirements, usually requirement IDs from a requirement specification document, with the test case IDs. The purpose of this document is to make sure that all the requirements are covered in test cases so that nothing is missed.

The traceability matrix document is prepared to show clients that the coverage is complete. It usually includes the following columns: requirement, baseline document reference number, test case/condition and defect/bug ID. Using this document the person can track the Requirement based on the Defect id.

Adding a few more columns to the traceability matrix gives you a good test case coverage checklist.

Types of Traceability Matrices

  1. Forward Traceability: Mapping of requirements to test cases.
  2. Backward Traceability: Mapping of test cases to requirements.
  3. Bi-Directional Traceability:  A good example of a bi-directional traceability matrix used in software testing is the references from test cases to basis documentation and vice versa.

A forward traceability helps us see which requirements are covered in which test cases? Or whether a requirements is covered at all.

A forward traceability matrix ensures that we are building the right product.

A backward traceability matrix helps us see which test cases are mapped against which requirements.

This will help us in identify if there are test cases that do not trace to any coverage item. If the test case does not trace to a coverage item, it is either not required and should be removed, or else a specification like a requirement or two should be added. Therefore, this backward traceability is also very helpful if you want to identify that a particular test case is covering how many requirements.

A backward traceability matrix ensures that we are building the product right.

A bi-directional traceability matrix contains both forward and backward traceability.

Why use software testing traceability matrices?

The traceability matrices are the answer to the following questions when testing any software project:

  • How is it feasible to ensure, for each phase of the SDLC, that I have correctly accounted for all the customer’s needs?
  • How can I certify that the final software product meets the customer’s needs? It lets us make sure requirements are captured in test cases.

Disadvantages of not using traceability matrices include the following:

  • More defects in production poor or unknown test coverage.
  • Discovering bugs later in the development cycle resulting in more expensive fixes.
  • Difficulties planning and tracking projects.
  • Misunderstandings between different teams over project dependencies, delays, etc…

Benefits of using traceability matrices include the following:

  • Making it obvious to the client that the software is being developed as required.
  • Ensuring that all requirements are part of the test cases.
  • Ensuring that developers are not creating features that no one has requested.
  • Making it easy to identify missing functionalities.
  • Making it easy to find out which test cases need updating if there are change requests.

How to create a traceability matrix

  1. Open Excel to create Traceability Matrix:
  2. Define following columns:
    1. Use case ID / requirement ID.
    2. Use case / requirement description.
    3. One column for each test case.
  3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:
    1. Used cases (all the flows are captured)
    2. Error Messages
    3. Business rules
    4. Functional rules
    5. Software requirement specifications
    6. Functional requirement specifications
  4. Identity all the test scenarios and test flows.
  5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is one flow or scenario.  SR-1.1 and SR-1.2 are covered .
  6. Now from below table you can easily identify which test cases cover which requirements and which test cases need to update if there are any change requests.
Requirement ID Requirement Descriptions TC 001 TC 002 TC 003
SR-1.1 User should be able to do this.  x
SR-1.2 User should be able to do that.  x
SR-1.3 On clicking this, the following message should appear.  x
SR-1.4  x
SR-1.5  x  x
SR-1.6  x
SR-1.7  x

This is a very basic traceability matrix format. You can add more columns and make it more effective. Here are some columns you should consider adding:

  • ID
  • Assoc ID
  • Technical Assumptions
  • Customer Needs
  • Functional Requirement
  • Status
  • Architectural/Design Document
  • Technical Specification
  • System Component
  • Software Module
  • Test Case Number
  • Tested In
  • Implemented In
  • Verification
  • Additional Comments

Here is another simple forward traceability matrix that we used on a recent project in Excel format.

 

Note: This blog post has been updated with new information.