Archive for the ‘Uncategorized’ Category

 

The list of things you can do to become successful can be long; learn about new techniques and processes, attend courses and conferences, read blogs, books and articles, collect ideas, create a network with successful people, observe successful people, set up visions and goals etc. I and many others are desperately trying to do all these things and everything at the same time. Except for work and career my life is also filled with a family, a pet, a home, friends and hobbies. I guess you already figured out where I’m heading. All things mentioned above are really great things to do if you want to become successful and you have to start doing them. There are hundreds of these lists so I don’t need to write yet another one. After doing all those things for a while it’s time to switch to another list and spend your time on other things. This is my list:

 

1. Stop learning new stuff.

There are always new techniques, tools, methods and processes to learn and you will never learn them in a true meaning if you don’t practice them. Pick one (1), that you think will suit you/your team/your system/your organization and try it out. If you notice that it doesn’t work for some reason, stop and switch to another. But make sure you understand and remember why it didn’t work. If it works, congratulation! You just became successful in using this new technique/tool/method/process.

 

2. Stop going to courses and conferences. Stop reading blogs, books and articles.

There are many courses and the supply of conferences are great and most of them are very inspiring and worthwhile. The amount of blogs, books and articles are enormous. You will definitely be inspired, get new ideas and learn new stuff. But this is a never ending story. You will never be able to read everything worth reading and won’t remember all your good ideas and how to do things best. As soon as you feel inspired and have an idea of something that you would like to do… stop reading/listening and carry out your idea. Let your inspiration lift you up and give you energy when it’s fresh (it will lose its strength after a while). You will never become successful by learning and reading about stuff, you will become successful by doing stuff.

 

3. Stop hanging around successful people and observe what they are doing.

Successful people can definitely help you become successful. They can give you ideas, new contacts and you can see with your own eyes what successful people do. But I’m sorry, that’s not enough. You have to do the same things as successful people do. Don’t just have successful people in your network, become a part of a network of successful people! Don’t just observe successful people, do what they are doing. Sometimes this can be big and difficult changes, everything from dressing a certain way to communicating with people (both oral and body language) in a different way. This is difficult and you need to practice a lot. So pick one (1) thing you want to change and practice that until its implemented forever. When you’re done with one thing you are one step closer to be a successful person!

 

4. Stop creating visions and goals.

When you have one vision and one goal, stop! It’s easy to want a lot of different things at the same time but if you go for everything it will become too big and when you’re finally done with the last one, the first one will be outdated. But what perhaps is even more important is to specify what tasks you have to do to get to the goal. But hang on… you’re not there yet. To be able to meet you goal and live up to your vision you have to perform all those tasks. Roll up your sleeves and just do it! If it feels like painstaking work, don’t look at all the tasks, just take the first one and make sure that one will happen. Slowly you will take one step at a time to your success, your goal and your vision!

 

 

We are living in a world of information overflow where a career is something both men and women should aim for. At the same time life quality and family is more important than ever. I can see people around me constantly failing and working insanely hard trying to know everything and do everything, ending up being tired and miserable people. In many cases I think it’s a really good thing to spend time on fewer things and do/perform more things. You will learn more and it will sure feel good to know and see all the things you’ve done (and not everything you haven’t done yet)-

Yep, I’m not talking about everyone else here… I’m talking about myself as well. I sure have some valuable lessons to learn from myself.

 

Good luck doing stuff!

 

 

It’s time to empty my “done bowl”, clean my desk and go home! The plan is to spend the next couple of months with a new and exciting mission… being a mother of two.

My “done bowl” is full of colourful notes and I know I’ve done a lot of things. It’s a pleasant sight and insight.

 

After talking to Micheal Bolton over a really nice dinner together with some of my closes test colleagues and reading his blog post (http://www.developsense.com/blog/2012/10/where-does-all-that-time-go/) I did the same thing as him, for lets call her “Maria”.

Maria is frustrated over the frequent deliveries that they do. The test team have to do the same things over and over again for every release; prepare for test run, update environments, run a set up of automated test suits and manual suits as regression test. This doesn’t leave a lot of time for Exploratory testing, good bug investigation or deep testing to find new bugs. It’s also kind of boring with such a repetitive way of working. To get a good overview, a grid like the one Michael Bolton wrote about was used and then another one showing what it could look like if the cycles were every second week instead of every day.

   M = Meetings
   Div = Misc
   P = Preparation
   S = Set up test environment 
   T = Execute scripted tests, incl bug investigation
   ET = Exploratory testing
   R = Test report

 

What a typical month looks like today, with daily deliveries (1 square = 1 hour):

Over one week is spent every month to just update environments!

And almost 2 weeks are spent to test the same things over and over again… and we all know that regression test isn’t the best way of catching bugs.

 

This is what it could look like with delivery every second week:

This sure looks like a more fun way of working for a tester.

I’m not saying the daily deliveries are wrong. There are reasons for why organizations do that. I’m also not saying the testing is bad. The testing is done risk based and the most critical issues are caught. My point is that by making it more visual it can be easier to understand the price for doing frequent deliveries. One may reconsider this decision when it’s so obvious what the cost is. I would also like to add that the best solution might not be to stop doing frequent deliveries but to automate the whole testing process (including update test environment).

 

This is a very easy way of visualizing what you spend your time on. It only takes a couple of minutes to do and it only takes a couple of seconds for your stakeholders to understand.

 

 

 

28 minutes in you can see Linda talk about test reports.
http://oredev.org/2012/sessions/testing-that-made-me-proud

 

 

 

I will do a short lighting talk at Öredev next week. I will talk about test reports that actually bring value.

http://oredev.org/2012/sessions/testing-that-made-me-proud

 

 

I tried a couple of ways of doing “testing days” or really focused testing sessions. The common denominator might be that testing should be done really focused under a short time period. Administration and planning are done to a minimum and bug reports is often enough as documentation once the testing is done. The expectations are usually that a lot of issues will be found that the usual, often requirement focused testing with few testing opportunities, won’t find. Let’s leave this for now… what I want to write about is that I’m starting to find a way of doing this that I really like.

In my example I will tell you how I and one other person (a project leader) did one of these testing sessions. We tested an application, available for both Android and Iphone, which I knew almost nothing about. Let’s call the application “AppX”. What I will show you below is what we did but I changed it a bit to anonymise the application.

 

We spent 2 hours like this:

• 15 min test planning
• 1h 25 min testing
• 20 min test reporting

 

The goal was to test as much as possible and to find as many critical bugs as possible. All testing should be visualized as much as possible, in test logs, notes, pictures etc.

The result was 15 new bugs and this is what it looked like:

 

What we did?

 

The notation I used:

 

I really like this way of working. Why don’t you try it!?!

 

 

 

Software testing is not only about verifying functions. A system is so much more than functions, if it’s suppose to be useful anyway. The system has to live in a context and in a world with many different users with many different needs and behaviors.

 

There are many stakeholders, not only the end users. All these stakeholders have different requirements and wishes for what the system should handle or support. It can be deliverables or qualities that must be in the system to make it possible for these people to do their job. For example, if an operating technician should be able to maintain a good level of security there must be routines and support for back up. Taking new back up and restoring an old back up just have to work. These things are crucial for an operating technician while the market department hasn’t dedicated this even the slightest thought. The market department on the other hand, might be anxious about the coolness of what is delivered in the next version, so they can beat the market by surprise in their next press release. Yes, there are many different stakeholders and many different wishes.

Example of stakeholders and their requirements/wishes

 

How do we do to cover more than just functions?

 

First of all I think we have to look beyond requirements specifications, meet all the different stakeholders and discuss what’s important for them. There is a lot of support in lists of test types like performance test, load test, usability test, installation test etc. Collect a list of your own, with suitable test types and go through them for every project to determine which applies for the test object. My list, of absolutely necessary test types that should be included in almost every project, is:

 

-          Functional test

-          Usability test

-          Platform test

-          Security test

-          Access level testing

-          Performance test

-          Stress test

-          Stability test

-          Installation test

-          Recovery test

-          Storage test

-          Volume test

 

There might be other types of test that can be applicable depending on the project and system under test. There might also be the opposite, several of the test types mentioned above might not be applicable or require very little effort. Often this is related to time and money but also what is valuable to test. But, just by discussing an area you have lifted up the different qualities and then the project can make a decision whether the area should be tested or not.

 

When you come to the point where you have identified all stakeholders and their requirements and whishes, you probably have an enormous amount of work before you. To cover all is impossible and most likely not meaningful. Therefore, your next task, possibly even more difficult, is to prioritize. Whose requirements are the most important? We can look deeply into this but the thing I think is the most significant is to make sure you communicate a lot with all stakeholders.

 

Someone whose list is very long and full of details is Rikard Edgren. The last time I listened to him his list was 77 test ideas long. See http://thetesteye.com.

 

What does your list look like?

What smart test types do you have in mind and which to you think is absolutely necessary for most systems/projects?

 

 

Once upon a time there was this company who struggled with a poorly built system. Every day the users got more and more annoyed on the bad interface. One day enough was enough and the kind boss asked a prominent consultant to build them a new system. The developer consultant arrived with his shiny laptop and started working. It was not long before the consultant started to struggle. The environment and business logic turned out to be a lot more complex than he predicted and none from the company side could give him any straight answers on how things should work. After many weeks of swift coding the system was ready for the users to test. And once again the consultant was faced with the users’ unavailability.

It was time to call in a tester. The humble tester arrives and is quickly introduced to the system and the users. Only two weeks left until deployment and no tests run, the tester decided to use the users as testers. One by one the users were booked for an hour each. The tester arrives to the meeting with a few bullets that needs to be tested and tell the users to use real data when testing. The users slowly start to familiarize themselves with the system and a lot of feedback is recorded by the tester.

The developer is happy to finally receive feedback.

The kind boss is happy the quality will be improved.

The users are happy that their opinions are raised.

The tester is happy that the system has been tested, the users introduced to the system through coaching and that everyone now seems comforted that this new system will save their day.

I doubt 200 test cases could have done a better job in this case.