Author: jocelyn siccion

Why should we use dummy data instead of live data?

Why should we use dummy data instead of live data?

Dummy data is benign information that does not contain any useful data, but serves to reserve space where real data is nominally present. It can be used as a placeholder for both testing and operational purposes.

Dummy data must be rigorously evaluated and documented to ensure that it does not cause unintended effects.

There are obvious pro’s and con’s when using dummy data for testing.


  • Easy to create a dummy set of data for testing as and when needed.
  • There is no need to obfuscate live data.
  • Testers can create the data they need without depending upon other teams.
  • A smaller data set can be created to test against where the testers know exactly what data exists (controlled sample).


  • Dummy data cannot fully replicate every single type of data that exists in production, thus defects could be missed.
  • Using a smaller data set means that load test results may not reflect the size of production data (web page/web service response times).
  • Processing times on a smaller dataset will not accurately reflect what will happen in production (e.g. on an Oracle Financials database).

Most organizations are still using live data in test and development environments because of a lack of awareness around data security, and they don’t know they can easily mask or de-identify sensitive data using off-the-shelf technologies without changing applications or testing processes.

Even when the awareness is there, organizations still tend to rely on real data for its speed and ease of use.

Using live, cloned data is generally regarded as a shortcut when there isn’t enough time or resources to create test data, or a secure test data strategy isn’t in place.

But these are not excuses for a practice that can put customer data in great jeopardy. It is true that in general these test systems are not Internet-accessible, but even if you have absolute trust in all your employees — never a good starting point — that doesn’t remove the risk, as many organizations will outsource parts of development and hire contractors, consultants, and the like.  And if the media has taught us anything over the last decade about carelessness, it’s that people often store this type of data on laptops and removable media devices, and those assets can get lost or stolen.

Beyond the insider threat, there’s also the very real possibility that malicious external hackers can eventually work their way deep enough into the network after a blended attack and get their hands on test applications and live data.

The biggest change in recent years is the legislation requiring live data to be obfuscated on pre-live environments.  The challenge is to replicate live issues on non-live environments, and to test on live-like data prior to releasing code to production. Failure to do so can lead to defects being uncovered in production, just due to a deficiency in the actual data or the volume of the data used on a test environment.

It’s a challenge but one that cannot be ignored. Either you use hand-crafted dummy data, or obfuscated live data – either way, you cannot just take live data and test it unchanged!


Under what circumstances will you hold your TFN

Under what circumstances will you hold your TFN

Tax file numbers are unique numbers issued by the Australian Taxation Office (ATO) to identify individuals, corporations and others who lodge income tax returns with the ATO.

Once you get a tax file number (TFN), you need to keep it safe. Your TFN is how we identify you for tax and super. It’s yours for life, so don’t let anyone else use it – not even friends or family.

If someone else uses your TFN, it can cause serious problems because they could use your name illegally and you could be convicted of a crime.

Your TFN information must only be used or disclosed by TFN recipients for:

  • a purpose authorised by taxation law, personal assistance law or superannuation law
  • the purpose of giving you TFN information that they hold about you.
  • lodge a tax return
  • apply for income assistance or support payments, such as pensions or benefits from DHS (which administers the Centrelink, Child Support and Medicare Programs) or DVA
  • start a new job or change jobs
  • have savings accounts or investments that earn income (eg interest or dividends)
  • receive a payment under the Higher Education Loan Program
  • join a superannuation fund.

TFNs may not be used by a financial institution to confirm your identity.  You must make sure you keep your TFN information in a safe place.  It should be properly destroy any TFN information that you no longer need. This will help prevent other people stealing your identity. You should report a lost or stolen TFN, or unauthorised access of your TFN information to the ATO.

The Privacy (Tax File Number) Rule 2015 (TFN Rule) outlines how your TFN information should be collected, stored, used, disclosed and kept safe. All people, agencies, organisations and other entities that are allowed to ask for your TFN information must follow the TFN Rule.

The people, agencies, organisations and other entities that are allowed to ask for your TFN information must not record, collect, use or pass on your TFN unless this is permitted under taxation, personal assistance or superannuation law.

There is no law in Australia that says you must give an authorised person, agency, organisation or other entity your TFN if they ask for it. However, sometimes there may be financial consequences if you don’t give your TFN to someone who is allowed by law to ask you for it.


  • If you are claiming or receiving a personal assistance payment from DHS (such as a pension, benefit or allowance) they may ask for your TFN to check your information with the ATO and other agencies that make payments.
  • If you do not give DHS your TFN, certain personal assistance payments may not be paid to you. Providing your TFN is a condition of receiving most Australian Government personal assistance payments.
  • If you don’t give your employer, bank, other financial institution or superannuation fund your TFN, it may affect how much tax you pay and could result in tax being deducted from your income or your interest payments at the highest marginal rate.
  • Your superannuation fund may ask for your TFN to facilitate the location and combination of your superannuation accounts. If you decide not to quote your TFN, the fund may not be able to find any additional accounts that you may have.

When an authorised person, agency, organisation or other entity asks you for your TFN, they must tell you:

  • why they are collecting it (including the name of the law or laws that allow them to collect your TFN and the purpose for which they are collecting it)
  • that it is not an offence if you do not give them your TFN
  • what will happen if you do not give them your TFN.

This information must be included in any forms that ask you for your TFN. The description of the purposes for collection can be reasonably general as long as it adequately informs you of what the law authorises the person, agency, organisation or other entity to do with your TFN.

If you consider someone has not handled your TFN information properly, you can make a complaint to the OAIC. And before you can make a complaint to the OAIC, you must first make your complaint to the person, agency, organisation or other entity you consider has mishandled your TFN information.


Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile and Waterfall are two distinct methods of software development. The Waterfall model can essentially be described as a linear model of software design. Like its name suggests, waterfall employs a sequential design process. Development flows sequentially from start point to end point, with several different stages: Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance.

In contrast, the Agile method proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, as a way to give designers more freedom. The design process is broken into individual models that designers work on. There is no pre-determined course of action or plan with the Agile method. Rather, designers are free to respond to changes in requirements as they arise and make changes as the project progresses. Agile is a pretty new player to the development game. However, it has made substantial gains in use and popularity in the last couple of years.

First of all, before you embark on a software design project, make sure you have the basics of software design down.  Before making a choice, it is important to do some research and understand the advantages and limitations of each approach.  Let’s take an in-depth look at the pros and cons of both the Agile and Waterfall methods of software development.

AGILE : The Pros

Agile offers an incredibly flexible design model, promoting adaptive planning and evolutionary development. Agile might be described as freeform software design. Software developers work on small modules at a time. Customer feedback occurs simultaneously with development, as does software testing.  This has a number of advantages, especially in project environments where development needs to be able to respond to changes in requirements rapidly and effectively.

Agile can be especially beneficial in situations where the end-goals of projects are not clearly defined. For example, if you are working with a client whose needs and goals are a bit hazy, it is probably worthwhile to employ the Agile method. The client’s requirements will likely gradually clarify as the project progresses, and development can easily be adapted to meet these new, evolving requirements. Agile is also an excellent option for experimental software design.

Lastly, this method also facilitates interaction and communication – collaboration is more important here than design. Because interaction among different designers and stakeholders is key, it is especially conducive to teamwork oriented environments. Different developers work on different modules throughout the development process and then work to integrate all of these modules together into a cohesive piece of software at the end of the project.


The emphasis of Waterfall is the project plan and therefore before beginning any kind of development there needs to be a clear plan and a clear vision in order. Because the Waterfall method requires upfront, extensive planning, you can launch software fairly quickly. You can also estimate timetables and budgets more accurately, which definitely tends to please clients.

Furthermore, Waterfall development processes tend to be more secure because they are so plan oriented. For example, if a designer drops out of the project it isn’t a huge problem, as the Waterfall method requires extensive planning and documentation. A new designer can easily take the old designer’s place, following the development plan without a problem.

AGILE : The Cons

Though highly flexible, Agile simply doesn’t have the structure that the Waterfall method has and this does present some drawbacks. Agile projects tend to be hard to predict, from timelines to budgets. Without a concrete plan, everything remains a bit vague and nebulous.

In addition, as previously discussed, active user involvement and intense collaboration are required throughout the Agile process. This can prove highly problematic for a number of reasons. First of all, this method of development can be quite time consuming, much more time consuming than the Waterfall method. And, it means that designers need to be committed for the duration of the project. If a designer leaves in the midst of a Waterfall method development project, it likely won’t be too big of a deal as the project is plan based. In the case of the Agile method, however, development is much more person based. Having a person drop out of the project could prove catastrophic.


The Waterfall method is incredibly rigid and inflexible. Altering the project design at any stage in the project can be a total nightmare and once a stage has been completed, it is nearly impossible to make changes to it. So, if you’re planning to use Waterfall, you will need to gather all of the requirements upfront. In addition, the problem with the Waterfall method is that feedback and testing are deferred until very late into the project. So if there is a problem, it is very difficult to respond to it, requiring a substantial amount of time, effort, and sometimes money.

So, What’s Better?

When it comes down to it, neither the Agile method nor the Waterfall method is inherently better than the other. That being said, each method does have its uses. Waterfall tends to be best for static projects, where it’s not likely that many changes will be made throughout the development process. In contrast, Agile tends to be a better option for smaller projects where changes are likely to be made during the design process. Though, keep in mind that these are just rough guidelines and suggestions. Really, when it comes to choosing a method there is not a right or wrong choice. You just need to understand which method is better suited to your project and your needs







Jocelyn Siccion

Jocelyn Siccion


A determined, reliable and achievement oriented IT professional with more than 20 years experience as Programmer/Analyst.  With a well-developed technical skills in application development, system integration, problem identification and implementation of effective solution for IT business needs.

Highly developed analytical skills and excellence in providing problem resolution for user support and solving application issues. Competent interpersonal skills that enhance communications with internal clients, external customers and different levels of management. Capable of explaining complex software issues in easy-to-understand terms and with professional and collaborative nature, ability to work independently, under pressure, multi-task, attention to details, work to deadlines.

Exposure to industries such as Insurance, Superannuation, Reinsurance, Claims, Superannuation, Shares, Sales and Marketing, Banking and Finance, Loans, Trust Funds, Payroll, Compensation.