Dealing with time pressure

There hasn’t been a project that didn’t have any form of time pressure. So we can easily conclude that we need to deal with this pressure. Can we always do this in the same way? Or even bolder, can we always do this? Well, maybe we can, maybe we can not… At least I’d like to share with you how I usually deal with time crunches in my job. Believe me, the testing job has a lot of time pressure. The tester is always on the critical path of software development and in Agile software development, the timelines are getting shorter.

Everything you do in software development should have added value. If not, it’s waste. To remove some of the pressure on your work: prioritize! Make sure that you have finished the most valuable tasks first. Whenever you hit your deadline, you must provide useful information. Of course you want to do all you planned, but that often isn’t possible.

If at any time you think that you will not be able to make your deadlines, discuss this with the people involved. Let them know as early as possible that the scope needs adjustment (also do this if you have spare time). Let others help you to make the decisions on what is important! Communicate your commitment and your expectations.

Last but not least, dare to ask for help. It is not weakness to ask for help, but it is a very valuable strength. Most people are willing to help you, but they only know what to do when you ask them. This will lower the pressure on you as a person and allows you to deliver quality work.

Advertisement

Why testers do not automate their tests

Test automation exists for quite a while, but it isn’t practiced consistently. In the years that I am in software testing, I’ve heard a lot of arguments on why testers do not automate their tests. The ones I hear the most are:

• Test automation will take away my job.
• I don’t know where to start.
• I cannot write code.

Test automation will take away my job

You as a tester think that you will lose your job when we automate testing? In short: No, it won’t! Testing is an intellectual process. Before you can automate anything, you need to think of what you want to automate. The test automation can only check situations that you defined. Remember, the test automation cannot think for itself and additional manual testing is always needed.

I don’t know where to start

Well, at the beginning of course! Start with investigating on test automation, what can it do, what has worked before and might also work in your situation? Since automating test is an investment, you need to find out which parts are important enough to automate. Product risk analysis (a good practice of structured testing) will definitely help you to define the risk-full and important parts of the software. Often repeated manual test cases are also a very likely candidate for test automation. Watch out not to start too complex. Work on some simple test automation to prove your business case on test automation and then expand.

I cannot write code

This is no reason not to automate tests! Who said you have to do it yourself… You – as a tester – can help decide which test scripts need to be automated. If you do want to do it yourself, you need to invest. At least know some basics in programming. Most frameworks that can help you do test automation don’t require in depth programming skills, but the basics will help you enough to do some valuable automation.

A good assessment is about improving

Improvements require an assessment, either formal or informal.  A good assessment tells you what you are doing right and which areas are open for improvement. If you do not plan to act on the improvement areas, then why do you do an assessment? So the target for an assessment is twofold. First you need to know where you are, next you need to know where you want to go. The road from where you are to where you want to be can only be defined by improvement actions.

So how do you do a good assessment of any situation? You need to ask questions and more importantly, you need to listen to the answers and make sure you understand them. Every situation you want to assess, has its own context. So get to know the situation and the context. The clearer the view you achieve on a situation in its context, the better your assessment. When you define  improvement actions, you need to determine where you want to go. This target situation, needs as much context and information as possible. The best way from A to B can only be defined if we have a common understanding of A and B.

Beware when you define improvement actions! Not every action is suitable for every situation. In other words: each problem has multiple solutions. The solution must solve the problem and it must fit in the context. Only then it will prove to be valuable. The solutions that work in every context are usually abstract. These will not actually help you to achieve your goals, but are a good starting point. When making these solutions more concrete, you need to change them to fit the current context. Sometimes when you try to do this, the solution will not fit your context. So is this the right way to go? Yes, since knowing what not to do is also valuable.

At Polteq we always use assessments in support of improvements. The available improvement models contain important areas for testing. The models also provide a lot of questions to assess the areas. But we do not stop there, we keep asking questions outside the model! The areas with their questions provide nice guidelines, but a good assessment depends on the assessors. The assessors must take the context into account and therefore questions in the model can become either more or less important. While assessing, we try to capture the situation in its context. This allows us to write specific improvement actions which are fit for your situation.

How do you find the right improvement actions?

How to sell software testing?

In the last two months I was testing software for Enrise via Polteq as a part of their development team The Impediments. Testing for them has been nice and instructive. The people at Enrise did not stop asking questions. Most of the questions I answered immediately, but some took a while to find the right answer. The question that lingered the most was: “How do we sell software testing to our customers?” I have to say that I’m very glad that Enrise asks this question! It shows me that Enrise sees the value and the importance of testing. The high quality software that Enrise delivers, can only be delivered when there is time set aside for software testing.

So how do you sell software testing?

• Sell a project (testing is part of the project).
• Only provide guarantee for production incidents when the customer pays for testing.
• Make the customer aware why you value testing.

Basically, you do not sell testing, you sell quality!

Software development is practiced in teams. Testing is a set of tasks that need to be executed in the teams, so there is implicit time for testing. You need to see that testing is essential to quality software and the time needed to test has to be allocated. The software may appear more expensive to your customer, but this will pay off! In the long-term, you will see less disturbances of production when the software is professionally tested. Investing in quality up front is worth it.

You’re probably thinking: “How will testing add to the quality?” Well, in many ways… I’ll give you three:

1. If you plan to test, you will need testable requirements. Ask questions on user stories until you have clear what your customer actually wants to have. Developers usually make more assumptions and think about the solution, where testers think about value for the customer. More questions in the beginning will result in an easier development process and a smaller chance on defects.
2. A tester tests software instead of checking if the software works. A customer will use the software to see if it works, where the tester tries to find the edge cases and out of the box situations. A negative age is an unlikely situation, but a typo in a birthdate is quite plausible… The tester thinks of these situations, so when these typos arise in production the situation has already been covered.
3. Testing is about mitigating risks. This implies that the risks need to be identified. Testing will create a better view on risks. So even risks that are not mitigated, can be communicated to the customer. Then it’s up to the customer to decide what to do: Invest more to mitigate these risks, or live with the risks?

In short: if you want quality products, you really need to test!

*This blog is also posted at Enrise

What went wrong?

Recently I discovered some strange defects. The defects could not consistently be reproduced and seemed to appear randomly. So what could I log into our defect management tool? “Every now and then the software seems to be unstable and give these errors” After some discussion with the development team, we decided to log the errors and assign them to me. I tried to find the root cause of the problems, basically the question was: “What went wrong?”. Following I will describe my search for the strange errors, which all appeared to have the same root cause.

Bug : This process sometimes terminates unexpectedly

So how to reproduce the termination of the process. First execute the process and see if it will work. After running the process 10 times without problems, I got bored by manually testing the process and decided to automate the execution. A loop of 1000 times executing the process still did have an abnormally terminated process. A positive side-effect was that we could now easily generate test data, since this process was the starting point for some other processes. When other people observed the ease of data generation, they wanted to use my script too. From that point on, the defect started to re-appear more frequently.

Having more appearances of the defect, it is time to check the logging again. The logging stated: “Could not insert record into …”. Ok, this was as it was with the previous appearances, but when restarting the same process, it would work. So why couldn’t it insert the record in the first place?  Suddenly I had to think on a course I attended on concurrency. The database sometimes locks a table when writing in it, to make sure there is only one edit at the time. When I distributed my script to more people, the process started to run in parallel in stead of in a single thread.  This was the cause of the problem! This proved to be the cause of all the inconsistent errors and could easily be resolved now by correctly implementing a lock-key mechanism.