Pa. Revenue Dept. computer glitch impacts processing of $15.3 million in business tax refunds

Reading Time: 1 minute

January 23rd 2018 – Click to read full article

ROOT CAUSE: glitch in the state Department of Revenue computer system

ROOT CAUSE: The batch of refunds that Revenue’s business tax system sent over for processing at Treasury had taxpayers’ names truncated and Treasury’s computers couldn’t read them properly [which] prevented the processing of the refund checks

IMPACT: the distribution of $15.3 million in tax refunds owed to about 700 businesses across the state

COMPANY RESPONSE: Revenue employees created a fix for the issue and implemented it
 

Thousands of BC Children’s Hospital ultrasound tests affected by technical glitch

Reading Time: 1 minute

2018 01 18 – Click to read full article

ROOT CAUSE: an automated feed that forwarded the radiology results to doctors was disabled for 11 months when a new system came into effect last February

IMPACT: radiologists at the hospital must do a retrospective medical chart review for thousands of cases to find out if the error delayed and impaired the diagnosis, treatment and prognosis for any children who had ultrasounds at Children’s Hospital

FOLLOW UP: Once the investigation into all the patient files has been completed, a quality assurance review … will take place [understand] how and why the glitch occurred and how to prevent it from happening again
 

Facebook apologises for storing draft videos users thought they had deleted

Reading Time: 1 minute

2018 04 03 – Click to read full article

ROOT CAUSE: a “bug”

IMPACT: resulted in draft videos being indefinitely stored instead

DISCOVERED BY: users discovered videos they had never posted were being stored by the company

COMPANY RESPONSE: “We discovered a bug that prevented draft videos from being deleted. We are deleting them and apologise for the inconvenience.”

 

Trying out cypress.io for UI testing because Selenium, ugh

Reading Time: 2 minutes

I am not a huge fan of fiddling around with Selenium implicit and explicit waits, and all the trickery that can go into setting up Selenium to make it “just work” and “stable enough” to get tests running on the pipeline.

 

If you have not struggled with that, my best is guess is one or a combination of the following:

  1. You are a genius and all the people working on the web app and tests worked with excellent best practices all of the time, and your world was basically perfect
  2. You worked alone on a small to mid size project and had absolute full control so could quickly figure out a false positive or false negative on your pipeline
  3. Your site had fairly new code that worked well in most modern browsers, and was not laden with layers of frames or custom code hiding legacy front end challenges

 

For the rest of us, may I recommend trying out cypress.io

 

It has also delivered on making the syntax for finding any UI element I needed to find very simple and intuitive.

 

In addition, the debugging is a breeze.  There is nothing to set up, and it “just works”.

 

And finally, the documentation is well thought out and organised, which made it easy for me to get cypress.io up and running.

 

Obviously I am still in my honeymoon phase with my beloved cypress.io.  The main reason is that so far it is has delivered on my major pain point with Selenium, which is that once you get those UI tests on a pipeline, the wait time trickery gets exponentially harder.  I have not yet used cypress.io extensively.  Instead I have tried to see if it delivers on some scenarios that are typically a small pain in Selenium.

 

I hope that my initial trial is a good sign of things to come.  Meanwhile, I am sending cypress.io a virtual hug.

 

HHHH     HHHH    UUUU    UUUU    GGGGGGGGGGGG
HHHH     HHHH    UUUU    UUUU    GGGG    GGGG
HHHHHHHHHHHHH    UUUU    UUUU    GGGG
HHHHHHHHHHHHH    UUUU    UUUU    GGGG  GGGGGG
HHHH     HHHH    UUUU    UUUU    GGGG    GGGG
HHHH     HHHH      UUUUUUUU      GGGGGGGGGGGG

 

Computer glitch at CSU fails to upload SAT scores making applications incomplete

Reading Time: 1 minute

2018 01 26 – Click to read full article

IMPACT: SAT and ACT scores failed to upload and attach for prospective California State University students

COMPANY RESPONSE: despite the “backend issue” it hopes the rollout of this new system will greatly improve the application process and ultimately save students some money

ROOT CAUSE: A computer coding issue

ROOT CAUSE: The glitch deals with computer codes associated with each application and how those codes match up with The College Board, which administers and keeps the tests and grades

 

Technical glitch cripples Vizag Treasury server, salaries may be delayed

Reading Time: 1 minute

2018 01 26 – Click to read full article

IMPACT: freeze all payments except for salaries and pension bills from the third week of this month

COMPANY RESPONSE: we will be trying our best to clear the bills by the month-end

ROOT CAUSE: the data can’t be uploaded onto the server and so the payment of salaries is likely to be delayed

ROOT CAUSE: technical snags in the main server for the last four days

 

Southwest Operations Return To Normal After Technical Glitch At LAX Lead To Delays Nationwide

Reading Time: 1 minute

2018 01 19 – Click to read full article

ROOT CAUSE: A computer issue

IMPACT: grounding travelers throughout the country… as all flights to LAX had been canceled

COMPANY RESPONSE: “…the issues with our airport technology system at LAX have been resolved, and our operation is returning to normal. We appreciate customers’ patience…”
 

Using Jira Query Language (JQL) to give visibility on the work done to automate installing software

Reading Time: 4 minutes

This is how I use labels in JIRA to give visibility to the team whenever QA is working on software installation and/or configuration scripts.

 

I add the label “qa_install” to tickets that involve working on installation scripts or config related to installing the software

To view all tickets in the project with that label, here is the JQL query I use:

project = QA and labels = "qa_install"

Returns: 72 tickets

 

 

I also want to see all tickets without this label

project = QA AND (labels not in (qa_install) OR labels is EMPTY)

Returns: 266 tickets

 

This returns tickets in the project that have labels other than “qa_install”, as well as tickets with no labels at all.

In other words, this returns all the tickets in the same project that do not have the “qa_install” label.

 

Credit for this tip

 

This allows me to get a rough percentage of the tickets, which could translate to an amount of overall work,  involved for QA to automate software installation

 

72/266 x 100 = 27%

 

Of course, credit goes to the entire team for working on these scripts, as QA does not work in a bubble.

 

TL;DR,

Originally I added this label for myself, to better understand my typical work day, and where my efforts were spent.  Also, I wanted to be completely transparent with the team when I was not “just testing tickets”.  Of course, “just testing tickets” is only possible when the appropriate environment is available.  Hence the need for spending time on installing and configuring test sites.

 

Over time, adding this label has been valuable.  For example, this label highlights whenever development changes affect the installation procedure, as a QA ticket with the label “qa_install” can be linked from the development ticket causing the change, with a link description such as “caused by” or “relates to”.

 

Adding this label was especially useful when I realised I had been hearing variations of this phrase when asking for help or clarifications on our software installation and configuration procedure:

 

Why invest time in installation scripts when installing is only running “two lines” ?

 

Sure, maybe it is only two lines on an environment that is already up and running, and it is only a standard update that is required.  Maybe it is only two lines if you happen to know the correct two lines for that particular configuration and customer.  In any case, running two lines is besides the point.

 

The point of having installation scripts is to have an easily reproducible environment that can be torn up and down quickly.  And the tickets with the label clearly illustrate how there are many more than “two lines” that need to be run when installing the software.  If it were so simple, the scripts would be tiny, and there would be virtually no QA tickets with the label “qa_install”.

 

Inevitably, this question popped up on many occasions:

 

But why not just test on the XYZ site? It is already running the “latest” version of the software

 

I won’t get too deep into the vagueness of what running the “latest” software could mean.  Does it mean the latest of the entire software suite, or only a few key packages, in which case, what configuration should be used?  The most common?  What about associated services — do they have a “latest” version that should be installed as well?  And so on.

 

However, running on some “other site” that you do not have control of, or knowledge of the setup, invalidates your testing by definition.  For example, that test site could have any number of manual tweaks, such as certain users being given more permissions that they would have in a production site meaning that you could falsely assume a scenario passes with that user because they have too many permissions on the “other site” compared to a production site.

 

Testing involves having an easily reproducible environment that can be torn up and down quickly.

 

Of course, there is also configuration to take into account.  For the sake of simplicity let’s assume that all configuration is also baked into the install scripts, so one version = “one version and its configuration for customer A” where customer A has the most common configuration used.

 

Back to having a reproducible environment.  For example, to test a feature, here are just some examples of when a test site needs to be installed with a certain version of the software:

 

  1. Running a pre test involves installing the version the issue was found on, in order to reproduce the issue
  2. Running a post test then involves installing the version the issue should no longer be reproducable on
  3. Running automated regression tests involves installing a particular version, for example when running semi automated tests that involve some human interactions during the test run
  4. Tearing down a site because your testing made the whole thing blow up, and you need to reset it since the devs have taken a look and gotten the info required to evaluate if this is a likely scenario in production
  5. Installing on a new server available for testing

 

Therefore, I can find myself installing, or reinstalling after wiping a site, somewhere between one and five times a day.

 

If this was not automated, I would surely go mad… or at least make human errors when installing.

 

So I believe the time invested in creating these scripts has been well worth the effort.  In addition, being able to highlight to the team when these scripts are being worked on, gives transparency to the work done in this area.

 

Apple text bomb bug ‘can cause phone crash with a single message’

Reading Time: 1 minute

ITV News – January 18, 2018

ISSUE: can crash an Apple phone or computer with a single text message

ROOT CAUSE: A “text bomb” software bug (a malicious link)

IMPACT: A number of Twitter users confirmed they had suffered crashes in their Messages app… some saying that they struggled to get their systems working properly again