Hello, pleased to meet you.
I am your new Terminal Operating System, call me TOS. I know you have heard and learned a lot about me in the past months, it was indeed a very tough decision to take me home with you, but finally I am here.
You might have met my older cousin, I am his latest major upgrade. He told me something about you but I prefer to know you directly as sometimes we see things in a different way: they call it family affairs.
Frist of all I need to get used to this new environment, starting from the place where I will live. I like by design, to have a lot of space reserved for me, as well as several virtual friends to play with and a high-speed network to connect to the world. Yes, I am very social.
It would be better to check that everything at home works fine even when I am under stress. I don’t like to be under pressure but you have to challenge me to meet my limits. If my sanity fails while we are working with all your expensive Quay Cranes, I could unfortunately create big troubles and stop everyone and everything here at the port.
This check it’s not only about the number of containers we will operate but even deals about the numerous chats I will have with my friends like my friend the GOS, the whole freaky automation crew, the EDI schoolmates and whoever wants to talk to me: I told you, I‘m social.
We call all the above, performance and stress tests.
To understand the environment where we will live our lives together is fundamental to be in peaceful agreement and allow me to serve you at best.
Therefore, I have to ask you to invest some more time and effort to explain to me in detail, who you are, as I am still so neutral and blank that I am not even able to give a position in the yard to any of your containers. Well, to be honest I am not even happy of this anonymous vanilla dress I am wearing and would really like to have a tailor-made multicolour kaleidoscopic suit for our big go live show.
Can I please have a look at your business process mapping? Is this how you work now or how you would like to work in future? You know, I can do miracles but if your people are not ready for change management we will be like a train launched full speed on a sinuous mountain track: no control.
Once agreed how to work, let me play with my certified officers and re-born to new life with my desired rainbow dress. It may take some time as we like working and deliver quality, but in the meanwhile you can definitely start working on your own developments, open the gateway to let me talk to your community and to my old and new friends.
And now, let’s talk about testing!
I love to be tested. It is so safe, stimulant, relaxing. We can try all possible scenarios, play C or play Eb and see how we perform better with no risks, as there is no audience and every failure can only be an improvement or a case study for my creators.
My creators worked hard to design me and make me as I am, but at the end they are only humans and are focused on that pale vanilla dress, not taking in account all the possible variations we would like to create here together.
Good tests will be performed using the actual hardware and UIs appropriate to each operational role.
Let me group some tests we should work on over the next months, almost till the very last day before going live in production:
- Sanity check or smoke tests: a non-exhaustive set of tests for new builds and releases, regardless of source, to ensure that key functions work and further testing can proceed.
- Functional tests: granular tests that link together to produce integration or end-to-end tests. They will cover the functional areas of the TOS implementation. Test cases will include variations and exceptions. Boundary conditions for expected behaviour will be considered.
- Integration / end-to-end tests: groups of tests that cover functional areas to ensure that software meets documented requirements, including Interfaces to any external devices or software / middleware
- Regression tests: a subset of container flow and end-to-end tests used to validate new builds and releases by verifying previously passed behaviour.
- Live Equipment tests: a collection of container flow tests and integration / end-to-end tests designed to validate the operation of actual equipment:
undefinedundefined - User acceptance tests: performed by user representatives for the purpose of accepting the solutions demonstrated in the tests.
The number and complexity of tests is variable but, in any case huge and I think it’s something we cannot do on our own. We shall ask help from a colleague of mine, the testing tool that will keep track – much better than a worksheet does – for all use cases, their results, which version we tested and who was the tester. And we can run reports on that to update steering committees.
I know a few of those tools and between us, I like the freeware ones: they are friendly and quick to be ready to work.
I am not that arrogant on selecting who could test me. Anyone can test me, it could be either a dedicated structured team led by a professional Test Manager or the trusted terminal key users working in the lab.
In case of complex architecture, especially with equipment or process automation, I would like to be tested by professionals, as the end-to-end process of information is structured, delicate, mission critical and could be even responsible for your health. I can’t get rid of Asimov’s Three Laws and safety always first!
Tests could be even executed by automated scripts, the good thing with them, is that I can manage my time and run them as many times as I like.
Testing is a good way to train your team as well.
My testing world is not bounded to a comfort zone, is open to questions, exceptions handling, feedback and improvement on operational procedures: is the right place to brainstorm.
As a result of testing we will have to work together on the Configuration Change Control
- Testing can generate a change request because of an unexpected/wrong behaviour, defect, missing configuration, requirement mismatch, etc.
- Test is reported in Test Tool as failed
- Test manager will prepare a case description and will go to the TOS Lead as this may impact other areas
- Test manager will request the TOS Lead to assign the right configuration resource:
- Internal: case is reported in the internal case management tool
- External (my creator): case is reported on vendor case management tool
- The configuration resource will develop a solution in his dedicated environment (as per environment descriptions) and perform the unit test
- The change will be installed in QA and the test case will be switched to re-test
- QA will perform the test and approve the change
- Test is passed in the Test Tool
- The configuration resource will give the change to the build master informing the TOS Lead as well.
- Build master will store the change into the ChangeLog and install the change in Configuration environment
- The case, eventually, will be closed
After the initial rollouts, the testing team will prepare for planned and well-structured rollouts.
The scope is to align all environments to the same configuration level. All existing configuration will be replaced by the latest version.
During the configuration phase many changes and fixes will be available or waiting for approval. Every environment is dedicated to a specific part of the configuration and accessible by specific team members. The same dataset will be reloaded in all environments after the rollout.
Before I forget, data migration quality shall be deeply tested as well as the preparation of the testing dataset, which is another important effort you have to spend to ensure the effectiveness of our tests.
Wow…. Nice chat, thank you for your attention.
I hope I did not scare you, but I like to play fair: if you don’t test me well enough, you might not like me, as I will be playing my own understanding of the music sheet. But if we play enough in test, our symphony will sound great and our live performance will be able to excite the most demanding audience.
Let’s open the curtain.
Yours faithfully
TOS