Category Archives: Deployment

Return of The Script

The last years Exploratory Testing has gained a lot of followers. In the world of Agile development fast feedback by testers is really welcome.

There are people who have doubts about the structure and knowledge transfer, because there is no script. For an experienced tester, a note about a data life cycle test is enough. Writing out tests for creating, reading, updating, and deleting data is boring for me.

Exploratory is about finding information and using it during the same activity. This can be achieved with a script. Let me tell you some Exploratory stories.

Exploring while scripting

The search

Laptops are light and small compared to desktop computers. On the other hand, for the same price I get more RAM and hard disk space in a desktop computer.

SSD or Solid State Disk is a hard disk, which is used frequently in computers. I needed an extra hard disk for my data. The challenge was to prevent my SSD from overflowing of data.

I opened a text editor and noted all kinds of information. My SSD was my default drive to store my information. I had to redirect all data to my HDD or Hard Disk Drive.

In the past I had changed this in the Windows registry, but I did not like this. It could lead to errors. I preferred to change the direction of the data using a command or a dialog.

Like a lot of programmers, I searched on the web. I found some articles and blog posts. In the meantime, I was copying links and making notes how to reproduce the steps.

The script

The first time I executed the script, I was about to copy all the steps in my notes. This is a waste of time, so I just added my observations in the script.

For personal reasons I changed the script on a few places.

network cable out
[current PC] copy all files in Kid on external hard disk
check on Appdata 08:25
[current PC] make a copy of the mail program and game subdirectory in the subdirectories of Appdata of Kid.
08:56
[current PC] remove all stuff from the mail program (after check?)
09:30
network cable in

Network cable out of new PC
[new PC] check %APPdata%
mklink does not work properly.

environment variables => no appdata found/
[New PC] old files app data
[New PC] copy all mail program and game program subdirectories to app data.
[New PC] make extra copy of files
[open Thunderbird] remove all files.

Network cable in new PC
check game
check mail program
network cable out of new PC

In case of problems:
- restore old files of mail program and game.

The details

There are some parts which need some explanation.

network cable out

So long the current PC is connected to the internet, the mails will be downloaded all the time. During the move of the files  of the mail program I might miss emails.


[current PC] copy all files in Kid on external hard disk
check on Appdata 08:25

The reason I chose an account of one of my kids is the small amount of data, which is used by this account. This is easier to restore than the huge bulk of data on my personal account. Hoarded as charged.

Appdata is a specific place for Windows. In this subdirectory there are subdirectories for programs to store information. E.g. for a mail program the address book and the mails are stored over here.

At the end of the line, I wrote down the time of the action.


network cable in

Network cable out of new PC

During my review I noticed that this was quite confusing. I added new PC in the last line. Looking at my script, the problem of downloading mail on my current PC was back. I remember that I left the network cable out.


[new PC] check %APPdata%
mklink does not work properly.

environment variables => no appdata found/

There was a step missing in this script.  The precise use of mklink was not included.  I had used this command and described the following steps in this script. However there is still enough information to reconstruct the process.

Here things go wrong, because appdata could not be found., I did not note the time, but the message is clear.


[New PC] old files app data

This is short for copy files from the old PC to on the HDD on the new PC.


check game
check mail program
network cable out of new PC

The most important thing of changing stuff is testing whether this went right.


In case of problems:
- restore old files of mail program and game.

This was my contingency plan.


While blogging I noticed that the other files to be copied were not mentioned. I forgot to include this step. Probably this was  too obvious at that time.


Debriefing or telling, what I did, is a way to discover what went wrong.


Who said: “You cannot change the script”?

Exploring while debugging

The command mklink was not the proper solution for my problem. I removed the created account and all files. This time I switched my search results to video.

After a while I got a script to make the proper redirection: when I saved the files, then they would be saved on my HDD. My first steps went right and then nothing happened. It did not work.

Time for my clean up again: remove the created account and all files. Then I could start in a clean environment.

There was a bug or error in my script which I had to remove. But what went wrong?

I opened the video to the browser and watched it again. All the time my thoughts were like “Yeah, it is in my script”. Imagine me nodding all the time.

Then something was mentioned in the voice over: I had to wait. Imagine me saying: “Oh”.

I only watched the first part of the video and stopped. I assumed that the change in my configuration would be immediate. Computers are fast. In this particular case the change took seconds.

The next time I repeated the steps in my script. I waited long enough at the crucial step. Then my files were saved on the HDD instead of the SSD.

You should always listen to the end of the message.

Exploring while planning

Years ago, I was a test coordinator for several projects. Several components would be changed and the question was: can you test whether everything went right?

I had serious doubts about the number of actions and their consequences. My goal was to explore the deployment. Less surprises means less tests.

It took me little effort to convince the project manager to have a meeting about the deployment plan. I volunteered for the chairman. Some of the questions about this meeting are answered in thhee Q&A.

You do need think about the implications of the things you create.
– Jemma Simmons

Q&A Deployment Plan Meeting Part 2

[Note from the author: after some fact checking I discovered that I used the Red Card in a wrong way in this blog post. The red card must be used to raise issue like low volume or high temperature in the room, which can lower the quality of the gathering of information. For normal interruptions the yellow card should be used.

This basically means that I had to rewrite the blog post on certain points. This task was more complex than I had expected. The whole flow of arguments had to be restructured while preserving the spirit of this post. So I only added this note.]

Facilitator: Thank you for joining in once again. Han Toan has already answered a lot of questions about Deployment Test Meeting over here. These questions were raised after reading his writing about his Deployment Plan Meeting.

Questions are still coming in. I’ve got green cards from numbers 38, 95, and 12. Number 38, you can ask your question.

Attendee number 38: Did you take the communication styles of the attendees in the meeting into account?

Speaker: During the preparation of the meeting I sent a concept version of the Deployment Plan to all the attendees. So the techies could study all actions and make notes on it.

The project leaders also brought their hard copy. They used it to note down important actions. I would not be surprised, that it was also used for time tracking: will all actions be discussed during the meeting? There were also managers carrying small notebooks.

One of the biggest advantages of the beamer was, that changes were shown. Next to verbal clarifications.

 

Facilitator: I’ve got green cards from numbers 95, and 12, and 23. Number 95, you can ask your question.

Attendee number 95: A Deployment Plan looks like a scripted test case. People say, that there is no need to make a test case, if it is used once. So why the hassle?

Speaker: I consider the Deployment Plan as a checklist of ordered and dependent actions. Still people might consider it as a time consuming artifact or test case.

Due to the complexity of the system and the number of involved parties it is handy to have some kind of script ready for use. Weeks before the deployment there was enough time to think things over.

Let’s assume I have the idea to have a dinner with my team. There are practical things like the location and time period. But there are also other things to take into account: is the food not too hot by the use of peppers? Or is vegetarian food available? If this is the first time, then it takes some time to arrange it.

 

Facilitator: I’ve got green cards from numbers 12 and 23. Number 12, you can ask your question.

Attendee number 12: At the beginning of the meeting I would start with introductions. I missed that part in your story.

Speaker: To me it is a logical step, so I skipped it in my writing. But I agree with you, that a round of introductions is needed. I think, that it is good to realise, that you work with human beings with needs and feelings.

 

Facilitator: Number 23

Attendee number 23: Were enough technical people attending?

Speaker: It was a prerequisite for the meeting. Technical actions had to be discussed. A manager can be helpful, but a techie knows the implications.

To be frank with you, I have to add, that one system administrator was not present. I talked with him about all relevant actions for him. Then I got the assurance, that I could call him during the meeting.

 

Facilitator: A yellow card from number 38.

Attendee number 38: Were all involved managers involved?

Speaker: Yes, they were. It was relevant to get fast approval for additional actions. During the meeting a techie could look at his manager for approval.

 

Facilitator: At the moment there are no more questions on the stack. This is your last chance. Okay. I see number 2. Number 7 and number 9. Number 2.

Attendee number 2: What was your Lesson Learned from this meeting?

Speaker: During the meeting I also updated the Deployment Plan myself. This way costed me a lot of energy, because I also wanted to see, how people reacted. The next time I let someone else update the Deployment Plan.

 

Facilitator: Number 7.

Attendee number 7: Why do you share this story?

Speaker: For me it was a logical step to set up a meeting and be a chairman. It looked effortless to lead this process. It was not completely the case. What is important, that I want to share the steps and actions I took.

 

Facilitator: Number 2.

Attendee number 2: Why do you share this QA?

Speaker: This is my way to exercise answering questions. It is a quite thorough one, because it can strengthen my story. Sometimes I use the answers, the next time I tell my story.

Furthermore it shows, how K-cards can be used.

 

Facilitator: There are no more cards on the stack. I hope you had some refreshing blog posts about a deployment plan and a meeting. Next time there will a blog post about more technical stuff.

Have a nice day (and fruitful Deployment Plan Meeting:).

 

Q&A Deployment Plan Meeting

[Note from the author: after some fact checking I discovered that I used the Red Card in a wrong way in this blog post. The red card must be used to raise issue like low volume or high temperature in the room, which can lower the quality of the gathering of information. For normal interruptions the yellow card should be used.

This basically means that I had to rewrite the blog post on certain points. This task was more complex than I had expected. The whole flow of arguments had to be restructured while preserving the spirit of this post. So I only added this note.]

Facilitator:  Thank you reading “In Case Of Emergeny Press 1“.  I’ve got green cards from numbers 95, 27, 38, and 23. Number 95, you can ask your question.

Attendee number 95: Did you consider Inspection according to Gilb and Graham?

Speaker: I am familiar with the Inspection according to Gilb and Graham. Frankly I did not consider this method. The question should be rephrased as
“Would you choose Inspection according to Gilb and Graham?”.
Looking backwards it is too far fetched. The people should receive proper training and there was just a block of few hours. Another disturbing element is mentioning the most biggest issues first. This can lead to a lot browsing forward and backward through the deployment plan. This can be quite disturbing.

Facilitator: Number 27, you can ask your question.

Attendee number 27: What was your role in the project?

Speaker: My role was a test coordinator.

Facilitator: I’ve got a yellow card from number 68. Number 68.

Attendee number 68: Why did you call for this meeting? It is not your task.

Speaker: I thought, that it was important. The next step is to make things happen: I planned in the meeting and I became the chairman.

Facilitator: There are no more yellow cards for this question on the stack. So we move on the next green card. Number 38.

Attendee number 38: Did the suppliers provide any deployment plans?

Speaker: All the suppliers provided deployment plans.

Attendee no 38: This looks like a time consuming operation. Was there any reluctance?

Speaker: One supplier did not see the benefits at first. Then he made a Deployment Plan after some talking.

Facilitator: At the moment I’ve got one green card from number 23. Number 23.

Attendee no 23: why did you need a deployment plan?

Speaker: I asked my test team the same question. One of the testers told me, that experience taught, that these plans were necessary. A few months before I personally witnessed a rollback.

Facilitator: we have a red card. Number 3.

Attendee no 3: What is a rollback?

Speaker: A rollback is, when the backup is restored. In this particular case also the old system was reinstalled.

Facilitator: we have a yellow card. Is it about the rollback? Okay. Number 17 go ahead.

Attendee no 17: Do you need to test it? The system, which was rolled back.

Speaker: Of course

Facilitator: There are no more yellow cards on the stack. I’ve got green cards from 54, 65, and 78. So number 54, you can ask your question.

Attendee no 54: Which format did you use for the Deployment Plan?

Speaker: I asked and got permission from one of the suppliers to use their Deployment Plan as a starting point. The advantage was, that it was familiar to the employees of this supplier.

Facilitator: I’ve got green cards from 65 and 78. So number 65.

Attendee no 65: Why do you call it an emergency? Nobody got hurt.

Speaker: How do you call a situation with a person cutting someone’s tent? And what would happen, if this person is caught in the act?
How do you call a situation with a system, which cannot be used right after the deployment?

Attendee no 65: [nods]

Facilitator: I’ve got green cards from numbers 78, 95 and 24. Number 78, you can ask your question.

Attendee no 78: Looking at your technical background it seems easy to be a chairman. Do you know everything?

Speaker: I do not know everything. I cannot know everything.

Attendee no 78: Did you not feel vulnerable?

Speaker: At certain points of the meeting I was vulnerable. Quite vulnerable. But I was also confident, that we could make a deployment plan as a group. Sometimes I had to ask for support and I got it.

Facilitator: No yellow cards. Number 95.

Attendee no 95: So technical knowledge and experience are not necessary?

Speaker: The important thing is to have a safe environment. A place, where people can voice their thoughts.
In order to discuss all actions I chose a business way of meeting. Please stick to facts. And we’re all here to accomplish something like a group.
I watched for body language. If I was not sure, then I stated the action, looked to the person and became silent.

Facilitator: I’ve got green cards from numbers 24, 38, and 23. Number 24, you can ask your question.

Attendee no 24: You added a new blog category: A leader ships. Did you ship? A Deployment Plan is just an artifact.

Speaker: I once read something along the line like System must solve the problem. If the deployment is bad, even the best system cannot solve a problem.

Facilitator: I’ve got green cards from numbers 38 and 23. Number 38, you can ask your question.

Attendee no 38: What have juggling and testing in common? You are talking about a hobby and job. These are two separate things for me.

Speaker: I have question in return: would you please summarise both stories in 4 words?

Attendee no 38: What about: good planning withstands emergency.

Speaker: So you plan the emergency?

Attendee no 38: I need some What If Scenarios, if things go wrong.

Speaker: So you want to make a scenario for every possible situation like overloaded network, a comet paying a visit, etcetera. There are a lot of scenarios to ponder upon. I suggest: Plan to anticipate emergency. In this case: complete rollback.

[To be continued here.]