My TPI Advice

Can be summed up as follows:

• Research all models.
  
• Use models as an "a la carte" menu.
  
• Create a model that suits your context.
  
• Continuously improve the process.
  
• Don't try to do everything at once.
  
• Establish a cadence of continuous improvement.
  
• Lean principles break down barriers, & thus work best when a senior leader champions them.
  

And don't forget:

• Measure where you are before you start.
  
• Decide where to go.
  
• Communicate at all times.
  
• People make it all work!
  

My Task Management System

This is an ode to Outlook 2007 and Dave Allen's "Getting Things Done". Without either, my life would be an unstructured, disorganized mess!

I use Outlook 2007 for absolutely everything, including:

• When to nag
  
• When to test
  
• What to test
  
• Action Items from meetings
  
• Books to Read
  
• Blogs to Post
  
• When to follow up with someone
  
• Status Reports
  
• Time Cards
  
• Mgmt Stuff
  
• Emails to reply to
  
• Reminder to update my goals
  
• Etc.
  

Pretty much everything in my work life goes into Outlook. I know you're probably wondering what about my actual outside-work life? Yeah, that's a different story. Put it this way, had to run down to the shop last night because I forgot to buy food. Boyfriend and dog was not impressed, especially boyfriend, since I only returned with aforementioned dog food. Oops!

For testing and management, I find that having a reliable and trustworthy task management system is essential so that I can prioritize, keep track of where projects are, and not "forget" something I was supposed to do. It protects my credibility and helps me professionally.

So, if I need to test a feature, what do I do? Well, first, I'll look up when the feature is scheduled to be available to test. I'll create a task to represent this. I'll also create a separate task to contact the developer to get background information. And, I'll also create a task related to creating automated test cases for our regression test suite. So, I'll have something akin to the following in Outlook Task Manager:

1. Seek information on software feature by X date
   
2. Exploratory test software feature by X date
   
3. Thoroughly test software feature by X date
   
4. Feed results back to developer and stakeholders by X date
   
5. Add test cases to automation test suite by X date
   

But, what happens if when I first start testing and I find a bug that is so severe that further tests are blocked? I find out when it'll be fixed and update the due dates. That way I can forget about testing this feature until I get pinged by the developer or my task pops up to remind me. I've found this extremely useful when the developer has not fixed the issue. The reminder reminds me to follow up.

I also use Outlook to block-book testing time. I don't believe in multi-tasking when I'm testing. If I'm planning to exploratory test, then I need to be focused on the task at hand. There are too many distractions in day to day life in the office, so I schedule an X-hour meeting in my calendar with the sole purpose is to test. I find this an extremely effective way to test and to uncover bugs.

It doesn't matter whether you use Outlook or some other tool, but use something. The brain cannot be trusted. I can testify to that as I'm driving home and it reminds me to add notes to a bug report. Not exactly the best time, why didn't my brain remind me 5 minutes before leaving the office? Because you can't trust it!

Key take home message: Don't trust your brain! Have a system!

General Systems Thinking

I've always had a knack for taking what I learn in some subject area, generalizing it, and applying it to another area. I never really thought about it and it came in extremely useful when I embarked on a testing career. In my testing career, I was easily able to take my developed expertise in the software under test and apply it whenever I moved onto another project with new software to come up to speed on. I thought everyone did this and it was just how people think and learn.

Then James Bach introduced me to "An Introduction to General System Thinking" by Gerald M. Weinberg. Reading this book was a revelation. Suddenly I was able to put a name to what I had been doing (albeit with limited capability).

At the core of General Systems Thinking is modeling of systems. It suggests that everything around us in the world and everything that we learn can be represented as a model – strip out the details that are unique to that model and now you have a model that will help you get up to speed quickly in another area. Gerry Weinberg does a far better job at explaining this!

I believe it's a vital element of exploratory testing. As you learn, you are building up a model of the software under test, and from that model you will take various routes through your exploratory testing session. You even build up models of testing over time, which model (or heuristic) you choose will depend on your exploratory testing session.

From a testing perspective, if you haven't read this book, I would highly recommend it. It will challenge you to improve how you approach a problem and how you test.

If you have any examples of how creating and applying a model in your testing has been effective, I'd love to hear about it.

 

 

Management Versus Leadership

I'm very excited by the movement away from traditional management, the "because I told you so" school, and towards a more inclusive leadership style, the "lets' look at this together and understand why this is needed".

Management is concerned about achieving results.

Leadership is the process of developing and communicating a vision for the future, motivating people and gaining their commitment and engagement.

Managers have a defined role in an organization. It is formal and has authority by virtue of the position.

While, leaders exert an informal influence, they are role models who have no positional authority but are respected by their peers and thereby have "followers".

A manager can be a leader but a leader does not need to be a manager.

Employing leadership techniques in your management career will aid you in building a team that you can trust and who execute on what matters.

Issues are resolved faster and stay resolved longer when those affected play an active part in reaching the solution.

According to Terry Gillen in "Leadership Skills for Boosting Performance", the attributes of leadership are:

• Vision
  
  • Managers maintain things, leaders change things.
    
  • Leaders have to be able to see in their mind's eye how they want things to be.
    
• Integrity
  
  • Consistency, openness, honesty and respect for people are essential if you want them to follow you.
    
• Determination
  
  • Leaders encounter more obstacles changing things than managers encounter maintain things by they do not give up.
    
  • They are so determined they persevere.
    
• Believability
  
  • Integrity and determination combine with interpersonal skills to add to a leader's believability.
    
  • Another ingredient is enthusiasm. If you are not enthusiastic about your vision and your people, no one will believe in you.
    
• Technical and Managerial Competence
  
  • You need to be good enough to avoid making a fool of yourself and losing too much doing things and managing processes.
    
  • You need to spend a good chunk of your time taking action to support your vision and values.
    
• Interpersonal Skills
  
  • You will have to build rapport with people, influence them and sometimes be assertive with them.
    
• People-Oriented
  
  • Effective leaders enjoy being with people, working with them and development them.
    
• Positive Thinking
  
  • Leaders encounter obstacles. Positive thinking is the starting point of the determination that carries leaders through, over and around them.
    
  • Attitudes are contagious.
    
• Walking the Talk
  
  • Walking the talk is an important part of integrity.
    
  • People can see you mean what you say and that you apply it to yourself.
    

So what does this have to do with testing? Everything!

Whether you are a manager or not, there is a great opportunity to become a leader in your team and in your organization.

Do at least one thing each day to give someone a feeling of uplift and confidence. Support those around you.

More importantly, being a leader means being engaged in the work, enjoying the work, and making a positive contribution. That's a much nicer place to be than just doing what you're told and waiting for the clock to strike home-time!

 

LEAN: Simple Rules

The LEAN simple rules:

1. Spend time only on what adds real customer value.
   
2. When you have tough problems, increase feedback.
   
3. Keep your options open as long as practical, but no longer.
   
4. Deliver value to customers as soon as they ask for it.
   
5. Let the people who add value use their full potential.
   
6. Don't try to tack on quality after the fact – build it in.
   
7. Beware of the temptation to optimize parts at the expense of the whole.
   

I love these rules. They apply to testing just as much as they apply to software development.

Testers Should Drive Software Testability

Software testability is a key aspect to allow the detection of difficult to uncover defects in software. Software testability supports the testing process and facilitates the creation of better quality software.


Software testability can be described as the probability that a piece of software will fail on its next execution during testing if the software includes a fault.


Testing and testability are complimentary: testing can reveal faults (testability cannot) but testability can suggest locations where faults can hide from testing (something testing cannot do alone).


Software testability must be designed into the software as it is developed. Therefore, it is an attribute of the software that requires close development cooperation with test.


Designing for testability requires that software is designed with a greater ability to fail when faults do exist.

James Bach proposes a set of Heuristics of software testability:

• 
  
  Controllability
  
  The better we can control it, the more the testing can be automated and optimized. 

• 
  
  Visibility
  
  What you see is what can be tested.

• 
  
  Availability
  
  To test it, we have to get at it.

• 
  
  Simplicity
  
  The simpler it is, the less there is to test.

• 
  
  Stability
  
  The fewer the changes, the fewer the disruptions to testing.

• 
  
  Information
  
  The more information we have, the smarter we will test.

A given piece of software will or will not hide a given fault from testing. The software testability of software will determine whether that fault is easily detectable by testing or not.


The more controllable the software, the more we can automate. The more we can automate, the less likely that human error will allow a defect to escape into the customer's hands.


Software testability is extremely valuable where functionality cannot be tested using a black box methodology. Software testability is tightly aligned with white box testing. Software testability must be designed into the software, so tester knowledge of any incorporated testability is required.


By including and improving the testability of algorithms in a software product, it will allow the testing organization to add automated and optimized white box tests to the automated test suite which will immediately fail and highlight a newly introduced bug.

 
For example, a particular algorithm when triggered in debug mode could print to STDOUT a specific message communicating that it is executing. If that STDOUT message is not detected by automation, the test will fail, thereby highlighting that the algorithm is no longer executing.


In black box and customer focused software testing, only those aspects of the software that are observable can be tested by the testing organization. The inclusion of debug information on specific software features will increase the ability and ease with which to test those software features which are not observable via black box techniques.


The simple inclusion of debug information will facilitate automated tests being developed to test whether an algorithm is executing or not. These automated tests will execute each and every build so if a regression is introduced it is detected immediately, a bug is filed, and development is made aware of the bug sooner rather than later.


The automation of these types of tests will also free up manual testing time so that a tester's time is spent on testing that cannot be carried out in an automated fashion, thus increasing test coverage of the software product.


By setting the tests up in automation, it also excludes the possibility of human error in not detecting the existence of a bug.


Software is said to have high testability if it tends to expose faults during exploratory black box testing, producing failures for most of the inputs that execute a fault. Defects can be identified and fixed quickly.


Software has low testability if it tends to project faults from detection during exploratory black box testing producing correct output for most inputs that execute a fault. These defects are extremely worrisome as customers using the software believe that everything is going as expected until down the line, suddenly the defect is exposed. This category of error can adversely affect the customer's business and thereby undermines the software's credibility and trustworthiness.


The goal of increasing the testability of software is not just to detect defects but more importantly, to detect defects as soon as they are introduced. Thus, reducing the cost and time to fix the bug and producing higher quality software each build of the release.


Reference: www.satisfice.com

Brain Rules

The best book I've read this year is "Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School" by John Medina.

It is very enjoyable to read, not one of those books where you bribe yourself with a cup of tea and a biscuit if you just finish the chapter you're currently reading. It's easy to get engrossed in the text and not realize that hours have gone by.

The 12 principles are:

1. Exercise
   
2. Survival
   
3. Wiring
   
4. Attention
   
5. Short Term Memory
   
6. Long Term Memory
   
7. Sleep
   
8. Stress
   
9. Sensory Integration
   
10. Vision
    
11. Gender
    
12. Exploration
    

I'm not giving away. A lot of material is available for free at www.brainrules.net. However, you'll get a lot more out of the material if you read the book too.

So the question remains: What does this have to do with testing?

Well, testing is an intellectually demanding task where concentration, focus, being alert is essential if you are to be effective. Based on what I learnt in this book I made some changes.

For example, I am a lark! I am at my most productive in the morning. Why fight that? So I get into work before 8am every morning to absolute joyous silence (apparently larks are rare in engineering and testing – who knew?) and I get a good 3 or 4 hours of productive work done. If I test during this period, I am far more likely to uncover high priority bugs. To allow for this interrupted time, I've rescheduled all my manager-type meetings to the afternoon.

Another example is how I've integrated little walks into my day, even if it's just going all the way to the canteen (a good 10 minute return journey) to get coffee instead of making it on my floor. These little walks recharge my brain and boost my brain power. I come back to my desk and easily refocus and apply myself to my work.

Etc, etc, etc.

Read the book – it really will open your eyes to the physiology and evolutional biology behind how we think and work.