post

How gamification in software testing can boost your software quality?

I have been working as a software tester, developer and manager for years. Serving organisation from multinational company to small tech startup. Regardless of what kind of organisation that I work in, we love to apply gamification in software testing.

We did it by hosting internal software test campaign after our product code complete. Within the time frame, we encourage developers to find each other’s bug and publish the scoreboard result daily. The score is based on evaluation of the quality of the bug that they found. For example, critical bug weights more points than less important bug. At the end of the campaign, we’ll reward those with most points. To me, if applying gamification in software testing correctly, it can bring more value than damage. Below are the three main reasons why we love gamification in software testing:

1. It is a cost effective way to increase product quality

Other than having the developer to test his own code, there are a few other options to do more testing:
A) Hire more internal software testers
B) Outsource software testing to professional firm
C) Crowdsourced software testing to freelancer around the world
These are some good options, however they might cost a lot, especially obvious to a small company. By applying gamification in internal software test campaign, you can increase your software quality by just rewarding a few top performers. It doesn’t sound cool, but it helps.

2. It motivates your team to produce better quality work

When gamification in software testing becomes a usual practice in your organisation, developers know that the result will be published to everyone else during the campaign. If they produce crappy code with lots of bugs, very likely their name will be shown as one of the top bug producers. With that, every time when they try to go with an easier path and write crappy codes, they’ll think twice. This helps to guide them to become a better and more responsible software developer.

3. It is fun

Software development and testing can be boring if we repeat the same routine again and again. So why not to make a fun game after coding complete? In order to make a test campaign fun, you need to be fair. You need to define the weight of different kind of bug differently. You need to set ranking for the different level (For example Godlike, Knight, Grown-Up, Baby), as a goal for participants to aim. You need to keep everyone updated on the status by publishing the result daily. At the end of the campaign, you need to reward the top performer publicly and make it a carnival. It can be fun and build up morale within your company.

Gamification in software testing definitely is not a replacement for all other software testing options. However, it can bring unique values and be part of your software testing strategy in your organisation. It might be a lot of work to evaluate and calculate all the scoreboard result manually. Because of that reason and we cannot find a tool that can apply gamification in software testing automatically, we’ve developed our own tool and share it to public. You can get more detail at http://get.bugmine.com.

I hope that you find this article useful and feel free to leave a comment to share your thought if you have any.


blog-writer-1
 
Kenaz has 10 years of software development and team management experience in Altera Penang and ICT startup – Dinomedia. He is the CEO & Co-Founder of Persizt Technology now.

Project Management and Development Methodology

In Persizt, we have been working on numerous different projects of varying scales and technology platforms. Depending on project scope and size, some of the bigger projects need detail planning and project management.

In this article, we will discuss standard project management and development methodology that we adhere to ensure a product of highest quality while meeting the project budget and deadline.

Pre-Sales Consultation

A project usually starts from some forms of enquiries and we will initiate some discussion with the client.

For certain project, client has detail requirement spec out. They already have screen design completed and done by professional graphic designer. Even so, after studying the requirement and design, we usually will discuss face-to-face with client to ensure we truly understand the business requirement and problem to solve. This is to make sure we are solving the correct problem using the correct solution, instead of blindly following the flow from client and facing serious problem of developing the wrong product down the road. Sometime, we might counter-propose a different flow, design or implementation to client.

Project Cost, Schedule and Quotation Preparation

We usually prepare a first rough quotation budget to client to sync up our expectation before engaging in a more detailed discussion and firm requirement specification discussion.

To estimate the cost, we perform both bottom up and top down schedules and try to achieve a balance between them. If the cmythicallient has a hard deadline, we will see how to schedule reasonable work in that schedule and discuss with the development team. Also, we breakdown requirement into detail to prepare a work breakdown structure (WBS). Adding up work day or hour required for each task would provide a total man-day/hour needed for the project to accurately estimate a project cost for client.

We will also perform a simulation of project resource allocation for the project to determine if we have the bandwidth and resources to complete the client project in the designated deadline. Depending on project complexity and technology platform used, we might assign a mixture of senior and/or junior engineers to the project. One thing to note is that, adding more people to a project would not necessarily guarantee a proportionate reduction of time due to the overhead of communication channel. This is clearly illustrated in the great software engineering masterpiece, The Mythical Man-Month.

If project cost is out of client budget, we usually will present the WBS to client and further discuss with them. As we strive to understand the client problem instead of blindly following the entire stack of feature request that they want, we usually would be able to propose alternative solution with lower cost and/or less features. We will propose a version that would still solve the client’s requirement by removing some fancy and unnecessary features. It’s also beneficial to the client for them to deliver a Minimal Viable Product (MVP) to the market first, then study the market response, feedback and steer the product accordingly. This would be better than investing a huge amount of budget and several man-months into a single product without getting any feedback.

In addition, we usually will propose the entire product to be broken down into several milestones with clearly-defined schedule and milestones. We practice agile development methodology in our development phase. Agile software development is set of software development methods that focus on adapting changes to to requirement flexibly in software development phase. In Persizt, we encourage frequent and face-to-face communication with the client and would greatly welcome a product owner appointed from client and communicate frequently with our project manager.

agile

We practice short development cycle (usually a few weeks up to 1 month tops). i.e. We architect and design our develop workflow to break down into several short period (up to 1 month), while being able to develop and present a workable and testable work-in-progress product for the client to test and feedback. A clear milestone deliverable and schedule will be defined. By the milestone delivery deadline, client will be able to test the product (website, apps or system) available in our test server. Certain test data will also be made available so that client can perform testing efficiently.

Through early milestone tests performed by client, they would be able to provide early feedback and requirement changes in early development stage so that the cost of change is low. Also, this would provide reassurance to client and both sides do not need to take high risk commitment (e.g. Client do not have to pay a large portion of project cost without seeing any thing being developed until the end of project development life cycle)

We also adopt other agile development practices such as code review, automated testing, continuous integration, code-refactoring etc.

Interface Design

We provide and handle interface design for the product as well. We usually start off by designing the flow in a series of wireframe mockup. We use Balsamiq Mockup extensively. The wireframe mockup is very rudimentary, as if sketching in restaurant napkin, intentionally. This is to help all parties to focus on content and interaction, not graphic design detail. This helps the design discussion iterates more frequently and discovers any user flow defect early.

balsamiq

Once the user flow and general design are approved, we will prepare a more detailed design. It would be prepared in Microsoft Powerpoint or Adobe Photoshop for discussion on graphic and theme design used.

Requirement Specification

With the detail design flow nailed down, we will also furnish a detailed requirement specification to client. The WBS should also be updated accordingly as well. With that, work would be assigned to engineers and development commences. We usually prepare our development schedule and WBS in Microsoft Project or Omniplan.

Development Status

During the development, task status in project plan would be updated accordingly as the work progresses. Client would be welcome to view and check the real-time status themselves too.

Change Control

Change is something inevitable in the most software projects. Things change in business environment. What’s more critical is how we manage it and keep the project stays on track and hopefully does not steer away from original timeline and budget drastically. Change request is usually submitted by client, formally or informally. We would appreciate as much detail as possible for the change requested.

In an outsourcing environment, we might not be in the position to question the validity or priority of a change, however, we usually will discuss and evaluate the change request with client. Sometime, when associate with a cost for the change, client might then reconsider the priority of the change.

From development standpoint, we do adhere to good development and coding practice to incorporate and reduce change cost in our code.

Issue Tracking

fogbugzWe have been using Asana currently and have previous first hand experience in Fogbugz as well. We track all our incoming bug reports in our bug tracking system, whether reported internally or externally (by client during milestone testing or User Acceptance Test or after product delivery). All reports are being recorded with detail steps to reproduce, priority, due date and assignee. They will be assigned and monitored by our project manager. Once they are fixed, test and pushed into releases, it will be closed and updated accordingly. This would assure accountability and efficient quality control monitoring.

Version Control & Build Management

Version control is the integral part of software configuration management. It is crucial in managing your source code systematically, even if your development team is little as one person. It provides a safety net for engineer to fall back, compare changes, debug on certain versions of source code.

In certain larger projects, we need to maintain several copies of different versions of the program as well. For example, one engineer develops and check-ins into main trunk for the main development task while another one working on fixes for soon-to-be release stabilised build or a patch build. This would prevent risky code that is not tested thoroughly going into build that is going to market soon.

Currently, we are using the distributed Git version control system, BitBucket and has previous experience in Perforce.

perforce bitbucket

Project Delivery and Testing

When the project is delivered (including milestone delivery), we provide a detailed Test Plan for client to perform testing. Certain test data would be prepared too. The project would be considered completed once it passes complete User Acceptance Test by client. We also provide a warranty period to cover any bugs and issues discovered.

Conclusion

In this article, we discuss project development process and tools used by us. We advocate on systematic project management and best software development practice to ensure we would be able to deliver a quality product within client budget and timeline.