The big day had finally arrived – for our annual Company Trip. It was the morning of March 30^th, a Saturday, and about 50 of us had gathered outside office. We were bubbling with excitement as we got into the bus. We had brought with us a few guitars, and even a bongo drum! Our due destination was Bentota Beach Hotel, where we planned to stay the night.

We set off around 8.00 AM, and started singing within a few minutes of settling in our seats. There were plenty of snacks, soft drinks and a few beers that were passed around to help us loosen our vocal chords. We sang mostly old Bila songs and played classical Sinhala tunes along the way, such as “Surangani” and “Udarata Kandukaraya”. We reached Bentota Beach just about noon.

After we settled into our rooms, we went straight for lunch, which was well prepared. Some of us hit the pool thereafter, while the rest of us including myself explored the hotel and its surroundings, which had a fabulous Spa, a Gym, and a Badminton court.

We all met up at 3.00 PM and hitched a boat ride on the Bentota Ganga (river), infamous for its scenery and its wildlife. We went among the mangrove trees and into the swamp, and observed many water birds. The highlight of this excursion was the sighting of a baby crocodile, which we were allowed to touch! It was one of those surreal moments in my life. After a couple of hours on the river, we returned to the Hotel.

Around 5.00 PM we all changed into sports attire and played games. Some of us teamed up for beach football, while others played badminton.

Bentota Beach Hotel is a spacious place, ideal for games and recreational activities. Their service throughout our stay was good. As the sun began to set, we stepped into the Indian Ocean and some of us even swam. The current was strong, but we stayed very close to the shore and enjoyed the feel of the waves on our feet.

We returned to the hotel around 6.45 PM and a small group including myself went to the Spa. This experience was truly relaxing…

Dinner was served around 8.00 PM and was a truly sumptuous affaire. There were many cooking stations with grilled fish, vegetables, meat items, pasta, noodles and a variety of seafood dishes. There were also Indian cooking stations, which served Chapati, Naan and suchlike.

Immediately after dinner we went to the hotel bar to try out the cocktails. There was a very nice dance group that was performing, which complemented the party atmosphere. The bar was entirely ours after 10.00 PM and we requested songs, and began to dance! We literally danced till we dropped, well passed midnight.

Most of us headed for bed around 1.00 PM, but a few of the guys stayed up till even later, playing poker and relating amusing stories.

The following morning we went for a swim in the sea before breakfast. Breakfast was again another gorgeous meal, where we had a variety of items to choose from, ranging from Sri Lankan foods like Halapa, Lavariya and so forth, to Waffles and Pancakes. After breakfast, we played one last round of badminton. We climbed into the bus around 11.00 AM and headed back home.

It was a truly fun filled trip, with many interesting and sometimes amusing incidents to fill our memories with, and talk about in office for months to come.

PurePlay, a leading online gaming company headquartered in San Francisco and with data centers in Utah, has engaged Calcey Technologies to provide software development services on a long-term basis. PurePlay delivers gamers a complete Virtual Currency gambling experience, gifting prizes to winners via a subscription-based revenue model. Calcey will help to re-engineer and extend PurePlay’s core platform for Poker and Slot Games. PurePlay’s online games have over seven million subscribers and the underlying technology platform is Java based.

PurePlay’s CTO Yang Lim visited Calcey’s offshore development center in Colombo last week, to assist in the setup of the development environment and to train the engineering team in the product’s features and underlying code. Yang himself is a Silicon Valley veteran having worked for several leading technology firms in the past, like go2net and Dini Group.

The PurePlay platform is built using a fusion of technologies including a Spring enterprise application framework, a JSP/Tapestry presentation layer, a Hivemind service layer and an Oracle database. PurePlay has adopted Scrum as their agile development methodology. Calcey will deploy a startup team of five engineers and commence the first Sprint of work for PurePlay this week.

Web designing is not only about creating a clean code-base and sharp graphics, or having bug free functionality, or even fulfilling the owner’s strategic objectives. These are essential requirements in a web design, but even the most sophisticated technology or the best-written content won’t hit the nail on the head, if the user experience is not consistent, cohesive and stress-free.

Creating such a user experience is not a trivial job, and involves addressing many issues such as usability, brand identity, information architecture and interaction design. Web user experience development, from strategy and requirements through information architecture and visual design is a process that needs input from the client, creative designers, end-users and software developers. These stakeholders might have different perspectives and expectations about the website.

Client expectations when designing and implementing a website is usually more about delivering the message to the maximum possible number of users. To be more specific, the website would:

• Show as much information as possible
• Attract users
• Look great aesthetically (not just another website, but be THE website)

The users’ perspective when visiting a website may be drastically different when compared to the site owners, such as:

• Grab some data (easy scanning through the pages)
• Pleasant (good contrast and no harsh distractions)
• Simple
• Easy navigation

The challenge for designers is to come up with a website that addresses both these perspectives. This is why the concept of website direction – Whiteboarding the concept and making adjustments to address the concerns of all stakeholders, including sample end users – is a key part of the web development process. The Whiteboarding process must be kicked off immediately after a clear set of written goals for the website are provided by the client.

A given functionality or content could possibly be presented to users in a hundred ways, and be accepted by them as a “good” experience. However it is possible to abstract atleast a few general principles for website design, based on numerous “usability testing” exercises conducted within the industry. Here are ten such important principles:

1. Speed. The Website or page must appear to the user within a maximum of five seconds through reasonable Internet access (ideally less). There is nothing worse that a user could experience, than waiting for a website to load. Since loading speed is related to page-size, pages must be as lightweight as possible. We must avoid that 2 MB home page at all costs, even with today’s high-speed Internet connections.
2. Simplicity. Present the core idea in a manner that the users could grasp it in the least possible time. Most usability experts say that if a given Web Page’s idea or functional purpose doesn’t register after five seconds, its poorly designed. It doesn’t mean the details could be read in five seconds, nor does it mean that any fields or user actions to be taken must be completed in five seconds. It just means we must “get it” in five seconds or less; for e.g. “this Website is about a social media marketing tool” or “this page is where I unsubscribe from my services, I have to give the service provider a reason for it” etc.
3. Focus. Present the idea or functionality in an uncluttered way, with a focus on the core message or function. Lots of white space is fine, especially when we are dealing with functionality. Google pioneered this concept with their legendary home page. Even when we want to provide the user with a multimedia experience, we must keep it clean. For example, having two or more scrolling images within the same screen-view, or littering the website with advertisements that are not demarcated as such, can be most confusing to the user.
4. Readability. Whenever we present textual information, we must keep it as succinct as possible. There is a whole school of advice on how to write for websites. In addition to the simple writing style they all advocate, we must make the paragraph width smaller for lengthy texts (so the eye doesn’t tire when scanning). Contrast must be good (beware of those fancy background colors and textures). Paragraph spacing must be adequate so the text doesn’t look clumped. Over the years, typography – the presentation and arrangement of text – has been considered a critical success factor in web design.
5. Resolution-robust layout. There are a host of screen resolutions out there, and one must ensure that the web pages appear readable and pleasantly laid out to all these users. This does not mean that we design separate style sheets to cater to a dozen resolutions. It just means we should pick a minimum resolution (say 1024 X 768 pixels) and make sure that the site looks good in this resolution, and in any other resolution reasonably higher than this. Layouts must not be broken or look minute because of a higher resolution. One customary way of ensuring the latter is to have liquid layouts. In any case, all critical content should be above the fold – an imaginary line at the bottom of a screen with the minimum supported resolution. The purpose that the website represents, for example, should be apparent above the fold, within a few seconds.
6. Coherence. This simply means that the collection of styles applied throughout the website must be the same, and each style applied for similar purposes. If there are two types of paragraphs, then all page content must use these paragraph templates. The color scheme, font scheme, input field and labeling scheme etc must be consistent throughout. Also, the way we perform different functions must be consistent. If field validation messages are displayed just below the field, then it should be so in every field in the website.
7. Accessibility. Depending on the website’s business goals, it must be made accessible to as many users as possible. Cross platform testing, cross-browser testing and loading custom style sheets for targeted mobile devices are the commonest measures that one can take to ensure accessibility.
8. Navigability. This means that we must have a uniform way to navigate throughout the website, without functional complexity (e.g. “tree views”) or the presence of multiple navigation areas. The ideal website would have a simple link-based navigation, perhaps within a common header. Complex dynamic navigation (cascading menus and flash pop-ups) should be avoided, unless for very particular reasons.
9. Searchability. This simply means that your site is properly tagged and ready for search engines and for textual search. Page headers, meta-tags, resource links and paragraph headings must reflect the search criteria of the target users. For example, the heading for this article is “web designing for a good user experience”. It is likely that the article would show up if the words “web designing” and “user experience” was to be searched on Google. If the title were “good design tips”, it is unlikely that someone searching for user experience or website design would end up seeing it.
10. Interactive. The concept of promoting interactive websites was a key component of the “Web 2.0 revolution” some years ago. Technologies like Ajax frameworks emerged to handle the problem of posting little bits of server-side content to the browser screen based on user actions, without refreshing the entire page and thus distracting the user. Anything ranging from enabling your website’s content to be posted on social media, to implementing anonline chat function to support your business goals, would be advocated.

A concluding remark; people visit a Website to gain information or to perform a task (a function). Making sure we provide just this, and nothing more thatwould confuse the user, is the goal of user experience design. We could display our artistic skills in moderation, as we don’t make website designs today to merely showcase the artistic prowess of the designer, unless art has some special value to the core purpose of the website itself. What we do (or aught to do) is to capture the target audience by giving them exactly what they seek. A good website design is one that has as little design as possible, where the UI is clean, simple and unobtrusive.

Compare Networks, Inc. (CN) has engaged Calcey Technologies to help them develop an interactive mobile sales and marketing tool, which they are deploying to blue chip enterprises across the US that have a large, mobile sales force in operation.

The core concept of the base product is fairly simple. It has a web-based content management portal for product managers to upload and organize their multimedia promotional content. This content is then synced with the iPads of the field sales staff, who show the material to potential clients. The actual finished product has many nifty features to address the needs of the domain, such as the ability to deliver HTML5 apps as a content type that could be distributed to the sales staff.

CompareNetworks’ Product Director Jason Roy visited our development center in Colombo in late January, to monitor a release for an important fortune 500 client. We spent many hours with Jason resolving last-minute technical issues, and thereafter took some time out to discuss the base-product’s roadmap for the rest of the year.

Left to Right: Jason Roy, Chamindu Munasinghe, Asela Indika, Mangala Karunaratne

The product release to CN’s first enterprise client Shofu was a big success. Shofu’s representative had this to say in their first official communication about the app’s rollout: “The app was a huge hit…the demo [to our sales staff] went perfectly and the response could not have been better!”

Jason also spent time discussing the strategic aspect of the partnership between Calcey and CN with our CEO Mangala Karunaratne. We are CompareNetworks’ principle software development partner, enjoying a seven-year relationship with CN for executing a multitude of engineering projects.

Jason is an experienced User Interface/User Interaction Developer and a dynamic Product Director, with unique abilities in both engineering and management. We benefited immensely from his visit, and our team is excited about helping with the development of the new roadmap features. The technologies involved are principally iOS/Objective-C and the .NET Framework.

As part of my degree coursework back in 2002, I had to write a whitepaper that outlined the commonsense principles behind ethical conduct within the sphere of IT, as affairs stood at that time. A recent conversation I had about the ethical conduct of software engineers prompted me to revisit that old paper, and try to extend the principles that I had outlined in it, to address the ethical issues that may arise when developing software applications. I’d like to highlight the underlying principles that ought to govern the good conduct of software engineers, for the benefit of newbies to this noble profession.

Whilst some folks might put forward issues such as violation of privacy, infringement of ownership rights or plain malicious intent (such as developing viruses) on top of their list of ethical concerns facing software developers, I’d like to begin with the issue of professional integrity as a developer. Basically, a software developer must be committed to building a safe, useful, reliable and secure piece of software. This means that one must:

• Not build malware unless it is for the explicit purpose of testing the security of an application in a controlled environment
• Have a rational use case for the application being developed; it must not be a piece of junk
• Test the software thoroughly and be committed to fixing defects in it
• Ensure to the best of one’s ability, that any information stored within the application should available only to those who are authorized to view it, as per the business use case
• Learn and follow recognized engineering practices in the industry, with respect to the architecture, design, coding,testing and distribution of the software. In other words, one must be a craftsman and not a hacker
• Be confident that the application’s business use case doesn’t violate any law of the land, civil or criminal. Building a piece of software that facilitates a ponzi scheme would be an example of unethical conduct
• Report to the client or the employer promptly if, in one’s opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic

A developer who fails to adopt the above guiding principles into his code of conduct would end up being “unprofessional” by today’s standards.

Let us now consider the issue of respecting the intellectual property rights of others. The parameters of this issue have been debated for many years, sometimes with winning arguments emerging from the flipside such as students in developing countries being unable to afford software development tools due to the absence of pricing structures catering to their poor economic conditions. However this conflict seems largely behind us now because big companies building popular propriety development tools (such as Microsoft) have created special pricing mechanisms to address the issue of global affordability and affordability for students. Also the vast open source development movement sprang about to address this very problem;and today we can say that, at least in principle, any developer can choose a toolset for building powerful, robust applications at zero infrastructure cost. Therefore the ethical principles behind respect for IP rights become even more morally binding, such as:

• Acknowledging borrowed IP that is being used as subcomponents of your application. This is particularly true for some free or open source apps,frameworks or code snippets. The providers of such software usually state the requirements for acknowledgement of their IP rights
• Adhering to the detailed parameters of licensing agreements of all software at all times. We should not exploit loopholes that allow us to gain access to the working tools, and then exceed parameters that the provider has stipulated but which he is unable to control, such as limits on concurrent database access. The providers have presumably decided on a fair business model for the software tools they peddle based on their operating costs, so we must not cheat them
• Helping those who have helped us, such as submitting honest reviews about the software subcomponents we have leveraged. This again is particularly true for open source frameworks; actively participate in ironing out issues in them and campaign for their progress
• Having clear licensing agreements for all applications we develop, and ensuring they are read by users when they install or sign up for your product

Another interesting aspect to ethical conduct in software development is the fair management of projects, to cater to the best interest of all parties concerned; namely the client, the developer(s) and the organization that employs their services for profit. This issue is mainly present in service companies that employ large teams of software developers to build applications for clients rapidly. Some of the recognized fair management practices include:

• A pragmatic estimation of the effort involved and delivery schedule, and an honest communication of the same to the client
• Close collaboration between the client and the developers, and ensuring transparency on both sides such as technical difficulties or changes in user expectations
• Monitoring of the ongoing effort and correcting capacity inadequacies proactively. Whilst enterprise software development is sometimes tedious and may require overtime effort from developers, the long-term goal of a ethical project manager would be to match client expectations with available capacity, and ensure the developers enjoy a work-life balance
• Develop a firm opinion about the risks and issues arising in a development project, based on investigation and past experience, and take action to mitigate the problems at hand. In other words, an ethical project manager would have a “backbone” to make decisions and influence people
• Ensure that whilst team communication can be assertive or relaxed based on the situation at hand, it always remains professional and follows all norms of communication decency

There are many other ethical issues that we may face as software engineers, please see below some interesting references that cover this topic more thoroughly.

When we set standards for a profession, we draw a line on the sand between the acceptable and the unacceptable, which sets the stage for greater respect and higher compensation. I invite you all to choose the higher standard.

References:
Computer Ethics Institute:http://computerethicsinstitute.org/
Communication Decency Act: http://en.wikipedia.org/wiki/Communications_Decency_Act
Software Engineering Code of Ethics and Professional Practice:
http://www.acm.org/about/se-code
http://www.computer.org/cms/Computer.org/Publications/code-of-ethics.pdf
Ethics and software development: http://www.ibm.com/developerworks/rational/library/may06/pollice/index.html

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.Django lets the developers build deep, dynamic, interesting sites in an extremely short time. The framework is designed to let the developer focus on the fun, interesting parts of the job while easing the pain of the repetitive bits. In doing so, it provides high-level abstractions of common Web development patterns, shortcuts for frequent programming tasks, and clear conventions on how to solve problems. At the same time, Django tries to stay out of the way, letting the developer work outside the scope of the framework as needed.

Django is usually called an MVC framework, and justifiably so. It is very heavily influenced by classical MVC and it’s even possible to argue that Django improves the architectural pattern. In Django, the three core layers are the Model, the View, and the Template. A key advantage of such an approach is that components are loosely coupled.

Having come to know of the interesting features of Django, we recently worked on a pilot product development project, called Xaffo, which had demanding needs for a web framework. Xaffo, a cloud-based social media monitoring tool,allows users to analyze the popularity of their brands among leading social networks.

Why we decided that Xaffo needs a web framework like Django

Xaffo basically deals with large chunks of social media analysis data shuttled between different web services, with huge task lists in the background that requires higher performance and scalability.The Xaffo prototype was initially built on Google App Engine and therefore in Python,and keeping the python code was also an essential part in our decision-making.

Meeting performance expectations when handling large sets of data was the challenge where features of Django became relevant and interesting. Handling large number of tasks in the background, Celery (explained below) came in handy to support Django to dynamically add or remove workers to handle the tasks.

On account of handling large sets of data, Django makes a better pair with MongoDB, which brings out easy database connectivity with high performance.

Xaffo is hosted behind nginx web server with uWSGI for high performance and static and dynamic content serving.The combination of this hosting environment and Django proved optimal. Xaffo is hosted on Amazon EC2 achieving the scalability where Django becomes the perfect web framework to match all these components.

Django made it easy to achieve tedious tasks that Xaffo demanded, with its appealing features such as,

• Object Relational Mapping
• Template System
• URL Resolver
• Forms
• Admin Site

In addition to the aforementioned features of Django, Xaffo relies largely on Django’s modularity.

We used several 3rd party Django packages, such as:

1. Celery
2. MongoEngine
3. Flower

Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well.The execution units, called tasks, are executed concurrently on a single or multiple worker servers using multiprocessing, Eventlet, or gevent. Tasks can be executed asynchronously (in the background) or synchronously (wait until ready).Celery is used in production systems to process millions of tasks a day.

Celery is used with Xaffo to manage the periodic tasks that are executed to fetch and calculate data gathered from various social network APIs. RabbitMQ is used as the message broker.

MongoEngine is an object document mapper for Django, which is very similar to Django’s own ORM. This enables developers who are already familiar with the Django ORM to interact with MongoDB without having to go through a whole new API documentation.

Celery Flower is a tool used with Xaffo to monitor the periodic tasks executed by Celery. This tool provides a web interface with information such as task progress, graphs and statistics.

To wind up, Xaffo was a successful project with Django, proving to us that Django web framework is highly suitable for projects that require higher performance,scalability, and high load of backend processing with large chunks of data.Its also a RAD framework in this context, and facilitates meeting tough deadlines.

Django takes away the tedious tasks of the development environment and makes it easier to build better web apps more quickly with less code. We at Calcey recommend it wholeheartedly!

More info:
Django – http://www.djangoproject.com
MongoDB – http://mongoengine.org/
Celery -http://celeryproject.org/
Flower – http://docs.celeryproject.org/en/latest/userguide/monitoring.html#flower-real-time-celery-web-monito
RabbitMQ- http://www.rabbitmq.com/features.html

Domain-Driven Design (DDD) is an object-oriented approach to designing software based on the business domain, its elements and behaviors, and the relationships between them. It aims to build software systems that are a realization of the underlying business domain, by defining a domain model¹ expressed in the language of business domain experts.

The core idea is that the business domain stakeholders and the technical team must communicate in a ubiquitous language. A domain model can be viewed as a framework from which different solutions can then be rationalized. For example, the domain might be retail, and three different solutions sitting on the domain model for retail sales might be:

1. An online store for the general public.
2. An order processing system for the store’s staff.
3. A special offers app for mobile devices,that notifies customers about offers based on proximity to the store.

The domain model will be defined with the assistance of experts in the retail business, where certain “fundamental” concepts in the retail trade will be built into the model as entities, value objects and aggregates. These entities will reside within a domain layer in the conceptual architecture of the overall system, to be leveraged by upper layers that render end-user functionality.

We recently adopted a domain-driven design approach to build an app for the centralized distribution and control of Multimedia Marketing Content to Sales Staff. The business domain is one of marketing content management, and we sought our client’s expertise in this field to help build a generic domain model.

In marketing content management, the basic concept is that there are market segments (aka business units), and marketing content is associated with these segments. The actual content can be folders or multimedia content items. In domain driven design your objective is to create a model of the domain. You need to identify what are the items (entities) you need to accomplish the desired functionalities of your application. You need to identify the relationships among different entities and how they interact among themselves. You need to find if the business goal of your client is achievable using your domain model. You do not need to know how and where the data of your domain will persist or even if the data do need to persist while you do the model of the domain.

This ignorance about your persistence medium will make your domain model free from any coupling with the persistence layer of the application. This will eventually separate the concerns of the persistence and its communication mechanism from your domain model. As a result, your application will be free from coupling with any data store and will be very easily unit testable.

Of course, in a real application you do need to have a database. But your domain model will have no knowledge about that. All it will know is the existence of a “repository” which will eventually manage your application’s persistence concerns.

I hope I was able to provide a teeny insight into what DDD is about. Eric Evans popularized the DDD approach by presenting this concept in “Domain-Driven Design: Tackling Complexity in the Heart of Software”². I strongly recommend this excellent book to all budding software architects. Here is a diagram from Evans’ work, describing the key patterns involved.

Let us part with this thought; imagine, once your code becomes readable to those familiar with the business domain, both peer review and knowledge transfer would become a whole lot easier.

1. Domain-driven architectural style (definition by Microsoft): http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle
2. Domain-driven design by Eric Evans: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
3. Quick refresher on DDD: http://www.codeproject.com/Articles/339725/Domain-Driven-Design-Clear-Your-Concepts-Before-Yo

Have you ever wondered how efficient software development would be, if you could open up your Integrated Development Environment (IDE) and focus on your domain-specific logic and needs, right from day #1? And not bother about architecting and configuring your development environment for days? Platform as a Service (PaaS) represents just such a zeitgeist in the industry.

Platforms that allow us to immediately code our core business processes with ease, without having to spend too much time configuring environments, have surfaced time and time again in the industry. Groupware platforms like Lotus Notes or customizable SaaS products like salesforce are historical examples of facilitation for quick-start, domain-focused development. However most of these earlier attempts seem to have fallen short of being completely flexible platforms for bespoke software development.

With today’s advancement in cloud computing technology and the resulting shift towards distributed development over the Internet, we once again have quick-start domain-focused development knocking on the door – in the form of “Platform as a Service”. This time there seems to be real hope.

Let me briefly explain the basic concept behind PaaS.

There are many “common needs” when developing a web app with transactional support, say for a commercial enterprise. User management, security, concurrency management, scalability, persistence and failover would all be a common requirement of bespoke development projects. Integrated lifecycle management measures like configuration management, continuous integration, code analysis and unit test cases are usually essential environmental requirements of any sizable development project. Furthermore, in today’s age of shared services on the Internet, one might want to bridge one’s bespoke apps with best of breed service infrastructure like OpenID login or Amazon S3 file storage. Perhaps, it would also be a common requirement (if it isn’t already) to integrate apps with Social Media like Facebook, passing certain information to be shared publicly.

Traditionally, we’d have to piece together “by hand” the requisite development environment, and architect our project’s code structure. Most of us who have done this know that this requires a lot of thought and a ton of configurations in various components of the environment; not to mention figuring out the design for service integrations.

PaaS is envisioned to addresses just this problem – it allows us to register over the Internet with a provider, configure a development environment in a simple way – plugging in different “cartridges” into the environment like the required technology stack and service integrations – and sync one’s local Integrated Development Environments with it (usually via a downloaded plug-in). Presto! We will have on our local machines a ready-for-development project that has all the environmental configurations wired, with the appropriate package structure and requisite files to address all our common infrastructure needs. The software that needs to run locally and remotely – web server, database, life-cycle management tools, the lot – will have been configured and structured in our local code-base. We’d just have to write our custom code that governs the business logic and user experience, and check-in! At least, that’s the concept in theory.

The most notorious early strider towards the PaaS direction is of course Google’s AppEngine, but more recent examples of cloud-based, “quick-start” integrated development providers include OpenShift, appfog and Stackato. They all have their pros and cons, and there are many online comparisons^{1, 2} available for those who are interested.

Calcey Technologies is a strong proponent of PaaS, having exploited several leading providers like AppEngine and AWS to the advantage of our clients.

References:

1. A Java Developer’s Guide to PaaS: http://www.infoq.com/articles/paas_comparison
2. Conducting a PaaS Comparison: http://apprenda.com/library/paas/conducting-a-paas-comparison/

As we all know, a Test Case is an important instrument in Software Quality Assurance (SQA). For the benefit of those aspiring for a career in SQA, I’d like to explain why writing good test cases is imperative, and go on to describe the key elements in a good test case template. But before I go into details, let me firstly define a test case.

Test case is a document that describes an action or an event in a software app, and the expected response for that action based on the given input. It determines whether the features of the application are working to the expectations of the end users. A collection of test cases is called as a Test Case Document. A test case consists principally of many specifications such as the Test Case ID, Description, Steps, Inputs, Expected Results and Pass/Fail criteria.

So why do we need a Test Case Document?

1. To identify gaps in business requirements at an early stage of development

In SQA Practice, it is recommended to start writing test cases in the early stages of the development lifecycle, as it can help you identify problems in the requirements or design of an application. For example, if we are unable to figure out a test case (or test cases) for a given requirement, the requirement is probably too broad to be coded. It would force the product owner to go back to the drawing board and refine his or her statement of requirements.

2. To optimize testing effort

Writing test cases requires us to “think through” the entire app upfront from a functional perspective and ensure we don’t miss out on test scenarios during actual testing. Whilst ad hoc testing is a critical component of any testing exercise, deadlines and ill-thought functional boundaries by newcomers to the team at the last minute may cause us to skip checking vital functional pathways in an app. This problem is avoided when the test cases are documented. On the other hand, having test cases also helps us from repeatedly covering the same ground and wasting time; for example stepping through the login functionality many times in an app that doesn’t have CAPTCHA secured login. By spelling out exactly the necessary maximum scenarios to ensure 100% functional coverage (I use the word functional here in a broad sense, inclusive of performance, usability and other relevant testing scope), one can save time.

3. Instill confidence in a release

When a release is tested and a set of test cases are marked as “passed”, “failed” or “not run”, everyone in the team has a clear idea of where the release stands in terms of quality. Stakeholders can make an easy judgment call about whether to push a release to Live, or to hold off for bug fixes, when under pressure due to the business urgency of the release. If one relied on ad hoc testing, one has to depend on the gut feeling of the testers, and there is no formal accountability for the quality of a given release.

4. Easy to scope-down one’s testing effort

Having test cases will help you to identify the most critical functional pathways of an app. So it offers us the advantage when under a time constraint, to intelligently scope-down the testing effort, to cover the most relevant testing areas for the release.

Types of Test Cases

We can categorize test cases based on their purpose within the SQA lifecycle. Three of the most frequently used test case types are:

1. Functional Test Case – a test case which steps through new functionality in the app

2. Regression Test Case – test case that is executed to identify the impact from changes to existing functionalities

3. Smoke Test Case – a summarized test case or a check list item which is executed to identify whether the build is stable and can be accepted for further testing

How to improve Test Case Management

Due to simplicity and cost, most small software companies write test cases in Word or Excel document formats. However, there are many Test Management Software tools available in the market such as Mercury Quality Centre, QA Complete, or even open source tools like TestLink.

What is the Calcey Test Case Template?

Calcey Technologies follows industry standards for testing, and shown below are the essential elements in our Test Case Document template, that any newbie to SQA can study and master.

Rajitha Egodaarachchi is a software engineer working for Calcey Technologies; a Colombo based offshore software development facility catering to clients in the San Francisco bay area. Rajitha has been a fast track performer and was recently nominated by his managers for a promotion as a senior software engineer, in recognition of his abilities and dedication. I caught up with Rajitha during his afternoon tea break on Friday, 02-Nov, to learn more about his work experiences and interests.

Sanduni: Welcome to the interview, Rajitha, and congrats on your upcoming promotion. Tell us a bit about yourself.

Rajitha: Thanks Sanduni. Well, I’m a software developer working presently for Calcey Technologies. I’m 24 years old, and a graduate in IT. I’ve been working at Calcey for the past two years.

Which university did you study, and what subjects did you major in?

Rajitha: I got my degree from Curtin University, Australia offered offshore through SLIIT campus in Malabe, back in 2010. It was a “general degree” in Information Technology. The subjects I studied however were focused towards software engineering.

Sanduni: Why did you pick software engineering as a career?

Rajitha: I had a passion for this subject from my school days. I got to do a lot of interesting little software projects while at the IT Club of St. Peter’s College, which ultimately paved the path for my working in the software development sector. It’s the buzzword of our time and whatever we do ends up having an information technology component in it. People literally hangout in cyberspace today, like on Facebook or Twitter, and almost every business we can think of can potentially be on the Internet. So I thought that specializing in this area would make my life interesting. The software industry is booming with new inventions every day.

Sanduni: Indeed. So why did you decide to join Calcey Technologies?

Rajitha: Well, a few companies called me for interviews. As soon as I got into the premises of Calcey I felt like it had the ideal environment for me to begin my career. I always wanted to join a “not so big” company that is well established in the trade. Calcey is a sort of boutique firm, where seniorfolks are always available for brainstorming, where there is easy access to resources, including Facebook and YouTube [laughs], and where the salary scales are good. Besides, I saw that we could play games in the evening or even shoot each other with NERF guns! I just loved the “developer-friendly” environment that I was introduced to.

Sanduni: What was the first project you worked in? Tell us what the experience was like…

Rajitha: It certainly was challenging. I landed on a C# project called Vertical Platform (later I got to know it as one of the coolest projects to work at Calcey). I was a new entrant to the industry… even though I was working at HSBC previously I had minimal development experience. So I had to work a lot harder to understand the requirements, the design concepts, and basically everything that is expected from the role of a Software Engineer. There were tons of stuff to learn, ranging from configuration management using GIT, to how to keep my cool under pressure.

Sanduni: How would you describe the work environment at Calcey?

Rajitha: Very appealing. Resources ranging from books to laptops are always available without restriction. We have an ethical, heterogeneous setup, and maintain high standards in terms of the industry practices. You can always speak to the management about issues. Plenty of stress relieving activities is available like computer games, foosball, carom or even a small in-house gym. You will find peers always giving out a helping hand as well as experienced seniors mentoring us with new concepts. Everyone’s informal and on a first name basis. The leads are also straight talking, and will point out your mistakes openly and often [laughs].

Sanduni: So Rajitha, what are your hobbies and interests? How do you make it all worth it personally?

Rajitha: I play computer games, sleep [laughs], swim, dance and work on personal R&D projects in my free time; I just hang out with friends on weekends. We do pub and club once in a while and all the latest movies are watched by us!

Sanduni: Great! Ok so do you really like your job? I mean, what improvements do you expect to see in your career in the future?

Rajitha: Yes I do like my job. The job I currently do is the profession I wanted to be, it goes without saying. Moving forward, once I grasp the engineering aspects completely, I would seek to manage projects. Thus I’m looking forward to beginning my postgraduate studies in the coming months. I think it will be helpful with my long-term career.

Sanduni: What was your learning experience like at Calcey itself?

Rajitha: Calcey practices Scrum, the most successful agile project management methodology that I know of, and I’m proud to have adjusted to an agile mindset. I also had to learn Objective-C and iOS development in double-quick time. It’s easy to switch between programming languages here, as there are experts in the domain that you can learn from. SQL, asp.net, MVC, iOS and JavaScript are a few areas of expertise that I tapped into, but I am aware that we also use other languages and frameworks like Python on AppEngine or even older technologies like ColdFusion.

Sanduni: What’s your best moment at Calcey? Is there anyone particular incident that sticks in your mind?

Rajitha: I’ve nothing in particular to single out, but the zillion birthday parties, farewell parties, trips outstation and hangouts are equally memorable for me. We are getting ready for a birthday party this evening, as you know…

Sanduni: Okay. Is there any advice you’d like to give to a newbie joining the industry?

Well, being a newbie myself just over two years back, I certainly felt the stern pressure put upon me when working towards deadlines coding complex features. Looking back after two years, the experience that one gains the hard way would be the best one could get, and would lay the foundation for a long and successful career that awaits you. Never be afraid to work hard, and play hard!

Sanduni: Thank you for your time Rajitha – and good luck!