Our blog is moving!

The Development Lifecycle of a Feature: Part Two

Posted by Natalie DeCario on November 11, 2013 at 10:33 AM
Natalie DeCario

A few weeks ago we explored what went on behind the scenes of VoIP Innovations as a new feature was going through the development lifecycle. The work doesn’t stop once we hit the big green DEPLOY button because things like tasks, defects and incidents are bound to come up; this is just part of the development lifecycle!

Let’s first explore what’s involved when a new task is submitted. Tasks are unlike features and defects in that they are not software development type things. Certain times there is a need for maintenance or preparation in order for a feature to continue working or for it to get started all together. A few examples of tasks that might come through would setting up an FTP site or making changes to a server. Tasks can come from customers or on of our internal departments, but either way it’s a task that is needed to make something else function. Since tasks do not deal with writing code, either our Developers or IT staff can work on getting them completed. It all depends on who’s the right person for the job.

Development LIfecycle

Now that we’ve covered VoIP Innovations tasks, we can move on to exploring defects. Evaluating defects starts in the same way a new feature request starts; by gathering the facts and analyzing them to either approve or reject it. The information we gather determines whether or not there is an actual defect or if it is just an incident (which I’ll explain later on). If the defect is verified and approved, then the list below will be our guideline in starting the process to correct it.

  • The Component
    • We need to know what software is creating the issue. Is it the BackOffice? An LNP Form?
  • The URL
    • This only applies to certain defects and can be left out.
  • A Summary
    • This is just a brief (one sentence) explanation of what the problem is.
  • Details
    • We need to know ALL of the information that surrounds the problem so we can identify where it’s coming from and how we can fix it. This section needs to be as specific as possible.
  • Recurrence
    • This information tells us how often the problem happens. Does it happen every time you do this? Did it only happen once? Do you only notice it on Tuesdays?
  • Steps to Reproduce
    • This allows us to verify that there actually is a defect in the system. If it can’t be reproduced, let us know in the Recurrence section. If you can recreate the problem, spell it out step-by-step so we can recreate it and identify where it’s coming from.
  • Actual Results
    • This is what happened because of the defect.
  • Expected Results
    • This is what was supposed to happen.
  • Additional Information
    • This is where you can fill in any other information that you think would be important to help our developers solve the issue.
  • Severity
    • Try to be objective and reasonable when reporting on the severity of the defect. We understand that it can be an inconvenience for you, but try to think of the big picture. While this does affect the customer, it’s usually focused on the Developers perspective of the defect.
  • Security
    • Here we want to know if this defect can compromise your account security. (By the way, have you set up your CNPI code to better secure your account yet?)
  • Impact
    • Tell us who is going to care, be affected, and be involved with this issue. Also tell us who should be informed about it. Unlike Severity, the Impact of the defect is doing to mostly involve the customers and what they experience.

After all of these components are taken care of, the defect begins its’ development lifecycle. The Developers will try take the information they collected and try to recreate the defect. From here they backtrack to determine the problem and get it taken care of. Likewise, if they try to recreate the defect and are unable to generate the same results, they will try different things or get in contact with the person who sent in the defect. If they still aren’t able to reproduce the defect, then it is moved to an incident.

An incident is basically the section we put the “one hit wonders” into. If it ends up in this section, that means that we have done all we could to find the root of the issue and we’ve exhausted our resources for searching. Instead of rejecting the defect and losing all of the information, we put it in the incident section so we can revisit it later in case it happens again or more information is found on it.

We have these systems in place so we can keep our BackOffice running smooth and so we can keep it fresh with awesome new features. If you’re in our BackOffice and want to ask us a questions, shoot us an idea, or tell us that we’re doing something awesome, please take a minute to fill out the Feedback Form that is located under the Help tab. If you’re having an issue with something, here’s how to contact our Support Team.

Tags: VI News

Retail vs Wholesale: Which SIP Trunk is for you?

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all