Tag: Musings

Testing 123

~ Danny Kwok ~ Leave a comment

Testing a system is a two edged sword for many because it can lower risk or incur cost and delays to the project. There must be a balance to what should be tested. In many instances, users often test whatever that comes in mind with a guiding script. So, what is the true purpose of testing?

Testing for Reassurance

Why test when you already know you are able to pass the results? In the old days, uncertainty is higher as many systems have high cost of rollback. It is difficult to go back once new features are deployed. Reassuring the stakeholders and their confidence are too priority prior to deployment. The present says otherwise as testing is now done at necessity. With Agile and DevOps, you can easily rollback your codes, resolve issues quickly or even create a speedy exit plan. Some may even go for canary testing, AB testing or pilot trial as confidence building.

Testing for Insight

Testing have any key objective that is geared towards insight and curiosity. This is usually done for innovations and new technologies. Testing helps to discover new requirements and uncover risks before deployments. Some Agile team also use this technique for test driven development. Of course, users will lament the failure of test cases even though it is clear that the requirements are unclear!

The basic principles of testing is not a pass or fail from test cases. Human nature seek for reassurance for new things. Testing is one way to build user confidence and “sign off”. Another aspect is the insight that can be gained from testing. In this case, testing is a method for discovery and development. Thus, it is important not to lose sight on the purpose of testing.

Ignorance is Not Bliss

~ Danny Kwok ~ Leave a comment

It is not surprising to know that ignorance can be quite a force to be reckon with. In every project, information gatekeeper can make or break your project. This is why Agile advocate retrospective on each sprint. My conclusion is that ignorance is not bliss at all.

Ignorance is Risk

Alarm bells are ringing loudly when your technical team starts to flag the following items or the PM (Project Manager) is hearing the comments from users during workshop.

  • This is an IT project.
  • There is no SOP.
  • Resources are busy and only 1 user is available for the project.
  • Please follow the same requirements as legacy system.
Ignorance is a Root Cause

In the initial phase, inexperienced PM or “nice” PM will not be sensitive. In fact, many will ignore to avoid conflicts. After all, nobody wants to negotiate such mindset or do change management. When there is a delay, everyone seeks to explain the reason but not the root cause. After all, it is really hard to admit ignorance is a root cause.

In many years of project implementation, ignorance continue to remain a key root cause. As management retrospect each project, it is a must to acknowledge that ignorance can either be ignored or be tackle head on. Only then, ignorance can be minimised for the project benefits.

The Dilemma of UAT

~ Danny Kwok ~ Leave a comment

UAT (User Acceptance Testing) is one of the flawed processes in Waterfall project model. This is why UAT no longer exist in Agile project. As it happens, UAT is a subjective processes and based on the users approval for the system to Go Live. This creates a major roadblock if you are changing or upgrading your system. This is because users resistance contributes to the failure of UAT, creating a dilemma!

UAT is Bad for Change

UAT is notoriously bad for change management. By default, majority of human do not have high tolerance in change, especially those who are in operational role. You will find many test results referencing the expected behavior of the old system. Another common issue is the required update of SOP (Standard Operating Procedures) which is not updated resulting the confusing test steps to the users.

UAT is Seldom On Time

It is ironic that many users are have a day job and not full time testers. Thus, it is really hard for users to commit 100% to the testing schedule. Any fixes will result in regression testing for the users. As a result, testing fatigue sets in and develop into frustration for the users. It is normal to see many UAT delays due to the users commitments. If you really want a full time tester, you will not get a true user.

Many UAT process faces constant dilemma to pass X number of test cases working a Y durations. Delays are foreseeable and expected. UAT also do not fit change management and SOP changes well. Therefore, the push for Agile testing will be harder as a replacement of UAT in waterfall project.

Project Boundary Tips

~ Danny Kwok ~ Leave a comment

In every project, scope creep is so common that we have to set boundary with project scope. Some users will request for all requirements with no understanding of story point. Others may become information gatekeeper to reveal scope a little at a time. So, how should we set project boundary?

Vague or Clear

Requirements are always vague in project. Clear requirements are referring to known story points. Soon, you will notice that there are often no issue for clear requirements. You should focus to preempt your vague requirements, if you choose to work on them. Thus, this is where your boundary will start.

Far or Near

If in doubt, do KIV. In reality, this is difficult if you are running on a fixed cost outsourced project. You will want to implement as much as possible. This is where you need to draw your boundary as near to the scope as possible. If the boundary is set too far, the likelihood of this scope acceptance will be very low.

Project boundary and scope creep is a never ending push and pull battle. You can decide this by setting the limits of your boundary. Clearer requirements will often lead to nearer boundary to scope and higher success in your project.

Agile Template

~ Danny Kwok ~ 2 Comments

Agile templates are getting popular now. There is no need to build many things from scratch. You can easily setup eCommerce shop within a day. Template are developed with Agile in mind and vice versa. Thus, you should start to develop Agile Templates instead of projects.

Why Template

From many legacy applications, templates comes from the ease to reuse and the need to reduce cost. Project is a mash up and gelled need to address a focus objective. In contrast, templates address a particular story point and suit Agile perfectly. Agile team will gain most from towards templates more than previous project implementation exposure.

Shift to Template Management

The role of project manager (PM) will be on a decline as teams shift towards Agile approach. Instead, this role can move to a focus on template management. Some organisations will have similar approach like COE (Center of Excellence). Another big push is Cloud which emphasis a lot on templates for rapid deployment.

The shift in IT landscape is huge for the past few years. The COVID-19 pandemic is also a major push factor in accelerating these changes. We will see more of templates design and model from major cloud organisations. Their template libraries will be the key factor to lock in the customers, including me.

Macros Tips

~ Danny Kwok ~ Leave a comment

Wonder if anyone just remember Visual Basic (VB)? If you have, you will feel at ease with Excel Macro and its IDE (Integrated Development Environment. Macro is a strange world that exist between developer and users.

KISS

Keep It Short and Simple is the first and most important tip of macro. If you find yourself building an entire application, it will mean that you are using the wrong solution. In many ways, macro is similar to RPA (Robotics Process Automation). You should not solution full fledged data driven application with dependency to your system.

Breakpoint, Add Watch and Step Into

The second most important tip you need to learn is the mastery of breakpoint, add watch and step into debugging. Owning to the local copy of each macro, you will find yourself checking every copies of macro floating around your ecosystems. This can really a be pain in the maintenance process. One way to manage is to master the debugging features. This is really the highlights as these features enable you to trace your macro issues quickly.

Macro is a legacy chapter in development which will be phase out in future. Meanwhile, I still need to manage and maintain my love hate relationship with Macro. These two tips are the most useful for anyone who want to maintain macro till it goes away for good.

A Strange View of RPA

~ Danny Kwok ~ Leave a comment

System is a minefield for various human interventions. A fully automated process runs on a set of controlled variables and environment. What will be the check and balance for these automation? This is also the key critical view towards RPA (Robotics Process Automation).

Minding your RPA

RPA is truly a strange view because it is attempting to speed up data entry of poor User Interface (UI) with automated key strokes. The system of today have so many relational tables that users are expected to link and click every dropdown values or foreign keys. The end results is a horrific experience for users. “Some wise people” will introduce RPA to reduce the key strokes for these data entries. Are these really the right approach?

Balancing the RPA

In most cases, I will not recommend introducing RPA to resolve UI deficiency or bad UI. By doing so, you end up playing a cat and mouse game with the application. This is why there is a balancing act to using RPA. You may end up investing your RPA too much instead of focusing to resolve the underlying process or application constraints.

RPA is not a new tool and existed since the time of web scraping. It gain popularity with digital transformation with the complexity of linked data and UI. This strange view towards RPA means you need to be mindful and balance your RPA wisely.

Agile Testing

~ Danny Kwok ~ 2 Comments

Agile testing was fairly new because of prevalent of waterfall model. The short deployment time of Agile will often means a reliance on automated testing. However, these automated testing often relies on known scenarios and limited scope. Thus, you will need to relied on past experiences to conduct testing for Agile.

What to Expect

Agile have shorter time to deployment than waterfall. Thus, coding and testing strategies must vary from that of waterfall model.

  1. Codes must allow graceful exit of exception scenarios i.e no crashes.
  2. Codes must be scalable for additional test scenarios.
  3. Failed test are often due to additional scope and and will be updated into backlog. Thus, they are not showstopper to deployment.
  4. User Acceptance Testing (UAT) are optional because of close collaboration with users.
Mindset Change

Users must stop their negative mindset of saying “it’s an IT project”. Application of Agile testing requires deep mindset changes. You cannot continue to apply the traditional approach of UAT. Instead, users must collaborate closely and be committed with the development team. This way, Agile can be realised in quicker deployment without the need for time consuming UAT.

Node.js 101

~ Danny Kwok ~ Leave a comment

Node.js is a JavaScript backend for service side scripting. If you are familiar with JavaScript, it is a client side scripting. Basically, you can imagine Node.js as JavaScript for server. That is really interesting as you can JavaScript client and server side.

var http = require(‘http’);

http.createServer(function (req, res) {

res.writeHead(200, {‘Content-Type’: ‘text/plain’});

res.end(‘Hello World!’);

}).listen(8080);

w3schools
Starting NodeJs

Usually, I will Hello World as my starting point. Although it is quite simple, it took me a while to get used to Node.js. This is because I am very used to JS as a client side scripting language. You will also need to run npm (node package manager) for some of the JS library. In terms of syntax, there are many similarities between Node.js and PHP. Of course, the best part is the reuse of JS on server side.

ODA Node.js SDK

One reason for playing Node.js was testing of Oracle Digital Assistant (ODA) Node.js SDK. It was required in the integration of ODA to another channel like Telegram. ODA also use Node.js as its custom component. To utilise this SDK, you end up having to learn Node.js and npm. On how to setup, that will be another post.

Node.js is a lightweight container type of scripting language. It can exist by its own package. Perhaps this is why it was used as custom component for ODA. However, it creates the need for this skillset for maintainability of ODA.

Just In Time Documentation

~ Danny Kwok ~ Leave a comment

Welcome to the paperless and Agile era! Finally, we can forego the need to print files of user guide and documentations nobody read. We also get many requests on the rows and columns on the documentation that non users wanted. Do we really need to generate so much documentation from Agile project?

JIT Documents

Unlike waterfall project, agile do not advocate documentation as deliverables. Instead, documentation is part of the process and can be provided as needed. This retain timely information and just in time efforts. There are even software that auto generated code documents if commented properly. Thus, agile document if required, not must required. Of course, you must also produce documentation promptly if asked!

Why JIT?

Document is the code.

In reality, documentation is good to have and help me to reconcile the thoughts and the codes. The best documentation from a technical view is always the code. However, this approach may not fit well with many Waterfall requirements. This is where JIT comes in play. Timely, current and just in time!