I use a tool to create nice screen captures. It is LICEcap. That tool records some animated gif. I always use the animated gif and not the lcf format.
When opening the application, you can see a window with a transparent layer. LICEcap records what occurs in this part of the screen.
There is a button on the bottom right with the text Record that you click when starting a new screen capture. Then you see a dialog, where you can put some options and a name for the output file. Just pressing save in the dialog and the tool starts with recording what you are doing.
A nice tool that makes my life better. Developers understand the bug reports better when they see a nice animated gif.
I found a quote that can be applied both in my personal life and in my life as software tester.
When nothing is sure,
everything is possible.
It applies in my personal life. I do long distance trails. This weekend I took for a walk of 50 km. In august, it will be 100 km.
But it also applies to software development and testing. Sometimes I do not feel confident about the quality of a software version. Suddenly, it gets better and better. It is also possible that it get worse.
A few days that I had no time at all to do anything for the daily challenge. However, I also can say that I performed 2 tasks. Be it, that I posted it on twitter. The Challenge of yesterday was easy.
11: Take A picture of your team.
So I took a picture of our team while we where in our planning and design session. That was an easy task and I posted it on twitter. This is the picture that I took.
It was not our complete team, because we are in holiday season this and next month in Belgium, but half a team is also good. In a few weeks, our team is also divided into two, because we are too big to be efficient. Now we are with 12 people. Way to big to be successful. We are hiring an extra software tester and then we can move on with two complete teams. For the moment we are lacking a software tester.
The next challenge is also not that difficult. It is:
12: Doodle a problem.
We have a problem. Part of our team is in another location and therefore it is not easy to have communication. Therefore I doodled a problem that I see at this moment and also in the near future when we are divided in two or maybe three teams. One team will be on a different location as the other, so I see a problem there with inter-team communication.
And it is true, we are already working with slack, having skype meetings and so. But still, it is not so easy to talk to each other if you are in a different location. I always go to the other location on Fridays. That is helping, but not enough.
Yesterday, it was a very busy day with very limited access to my desk. So I was not able to continue with the challenge of the day. This morning I saw a tweet of Kim Engel about day 7 of the challenge.
I did not know that extension, so I did have a look at it and installed it in my Chrome browser. After the extension is installed, a little color wheel is present in the toolbox area of my browser. The first thing I did is clicking on it. I saw some weird names that I did not recognize at first. But after a little searching, I found a article on Wikipedia about color blindness. The weird names where also mentioned there, so this are types of color blindness.
I never did think about color blindness when testing. But is can be a problem, specially for males. Because our machine is mostly operated by males, it is worth looking at it. The red-green color blindness is between 7 and 10 per cent of the male population in most countries according to the article.
To look what the spectrum extension does, I googled an image with a colored wheel on it. And I played a little bit with the check boxes.
Let’s try Deuteranomaly. Persons with deuteranomaly have a mutated form of the medium-wavelength (green) pigment.
The red is completely gone and it became a kind of brown. Also some colors in the green spectrum have changed.
Interesting, because in our interface we have a feature that we can simulate what our hardware is going to do. In this way, our customers can setup the machine without production first and simulate what is going to happen. But what is detected is put on an overlay with green color, and the color can not change.
That is a problem if you can not see that kind of green, specially if you are detecting colors that are displayed in the yellow spectrum, because those people see it as the same color.
Thanks to the challenge, I found a new tool and found some bugs. This means that I now completed Challenge 7 and 19.
Challenge 7 was for me an eye-opener. It is not because I can see some items on the screen, that everybody sees the same items in the same way. I think that the spectrum extension will be used a lot more in my testing activities.
The next Challenge of the 30 days of testing is to perform a crazy test. What is crazy? I was thinking and it was maybe time to have a capacity test on our machine. Capacity tests are for us not that easy because it needs a lot of equipment. But Let’s try do do it anyway.
Normally my test setup in our lab is just the machine. I can place product at the back side on it, and in the front, there are 2 outputs, one for good product, and one for bad product. Yes, the machine I have to test is a sorting machine. We sort food. And because we do not want stones or glass in our daily food, we developed machines for taking that out of the food chain. I do not want that, so a lot of testing is needed. But today, I had a challenge to do.
Let’s go crazy and let’s drive to our other plant, where we could use a feedback loop. So we can do a capacity test with it. After that was installed, I needed some test product. We have square cubes for that, but also Lego bricks. Nice, lets put a lot of them on our machine. After that was done, I saw that the spread of the product was nicely spread over 2 camera’s in our system. That was not what I wanted, because the system was not stressed that way. Maybe it was time do do something different this time.
I too a little of carbon and tried to manage the stream on our shaker. And it worked! Now the stream of bricks are just over one camera. That is what I wanted. Now I can stress a part of our system. Let’s see what happens then. I first started without any sorting. That went well and did not notice any problem. Then it was time to do something more. What if I sorted the Lego bricks out of the square cubes. Lego is rectangular and we also have little square bricks. Our detection can handle that. So lets do that.
After the parameters were set correctly, the output changed. Yes it works! The rectangular bricks can be sorted out of the square ones.
Then a warning popped up in our logs. He, what is that? The warning “Shape processing SW too slow” together with warnings about cameras. But there was more, some warnings about cameras can not be true. There is no shape processing attached to some cameras in our machine. And they are also mentioning problems. That is not good at all. No, it is a bug! Because this test was so spectacular, the team was also looking what we did, and they all agree, that there is a problem in our system. So I think it was worth the effort. I only found 1 problem this time. A problem that I never had found if I did not use the feedback loop.
Unfortunately I can not always use this system, because I have to share it with other departments.
Sharing a blog post about testing on day 4. It took me a little bit of time, but I found a blog post that I can share with my team. Not just a post, but one that I think we are suffering to.
One of our problems the latest time is that suddenly all stories are done. Mostly one or two days before sprint ends. This because nearly all stories are picked up by our developers. I think that at this moment, it is because we have a very huge team. In a few weeks we are going to split them up in 3 teams, so we are going to have new challenges then. But at this moment, we are slowing down because most of the stories are implemented just in time. And then the testing still needs to be done.
A few weeks ago, I found a blog post from Maaret Pyhäjärvi, about The Squeezed Testing problem, is that not the problem we have in our team? I do think so.
I posted the link of The Squeezed Testing problem, a blog post from Maaret Pyhäjärvi, to our teams slack channel. In a few days or weeks, I can have replies from it, because of the holiday season, there are not that many team members in the office in July.
Today’s task is to listen to a podcast. Because I already listen to many podcasts when I am driving to work. It is easy to pick one. I just take the latest podcast that I listened too. I choose an episode of Test Talks. Episode 103 with the title Five Test Automation Secrets.
Listen to a testing podcast
Central guest in this podcast is Paul Grossman. I am not going to explain all he told in the podcast. If you want to know it, I suggest that you go to the podcast and listen for yourself.
But, there is always a but, I want to talk a little bit about one thing he mentioned. Paul discussed a question that every manager will ask sooner or later. Why do you want to automate? Manual testing is cheaper, we invest in expensive tools, and then the tests break and costs a lot of money.
I have at this moment more or less the same issue. We do want more test people, but our managers will not spend money on people who “add no value”. Like Paul explained, what is the situation if we did not automate? How would things be? Then again the money talk comes out. Tools are expensive, and with that money we can buy a manual tester for a year. But how much effort do we put in bugs that are not easy to reproduce manually? Or bugs that need for example 1000 iterations before things break? With our machine that runs 7/7, 24/24 such iterations are valid things. The machine, and the software on the machine may not break. If we break, then sometimes the supply chain is stopped and at some customers, then the whole batch is thrown away, because it they can not take a risk that there is a needle in the food. That may not happing.
Still, our managers are not convinced. So the next month I am going to plot out what money we saved by finding bugs.
The second day is not an easy one. Not because the task to do today is that difficult, but because it is Saturday. For that I did yesterday at work already a little bit of work for today’s task. A little preparation was needed. What is today’s task? Let’s have a look on the paper.
Take a photo of something you are doing at work.
I took a little foto with me in front of the machine that I was testing yesterday. Wednesday next week is the demo, so I do have to find a lot of bugs, otherwise our developers do not know what to do in a few days.
No really, beside working on my desk and automating some integration tests with python, I also have to test with real product on a real machine. There are some tests that I simply can not automate, so I can do some functional tests on the machine. But there is more, I also can not do all tests on the machine in our lab. We have now the opportunity to test at our clients site in a real environment. At this moment, our client is sorting peas with our machine with a rate of 5 ton per hour. These volumes can not be tested in our lab.
Buy one testing related book and read it by day 30.
For me it was easy to pick a book. Because I recently bought one, that I never read past the forewords. So this challenge is for me a trigger to really start reading the book.
The book I choose was More Agile Testing written by Janet Gregory and Lisa Crispin. My challenge is to read more or less one chapter a day. The book contains 25 chapters. I hope to find some useful tips that I can use in our team. Not only in our team. We are creating 3 teams starting from our next sprint. This because another project has been finished and now al resources in my company are placed on our product. So 2 more teams can be formed. That there are challenges, that is for sure.