Can be summed up as follows:
And don't forget:
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:
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:
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!
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.
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:
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!
The LEAN simple rules:
I love these rules. They apply to testing just as much as they apply to software development.
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:
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.
Test Process Improvement is the continuous improvement of the quality and the efficiency of the testing process, in the context of the whole software development life cycle.
But, test process improvement is not testing. Why should you invest in it? Aren't you wasting time that you could be using to find bugs?
My organization invested in continuous TPI.
One major outcome was to increase the efficiency of the automation execution and analysis process. In many projects, this decreased from a 5 day duration to 1 day! This has freed up time for more manual and customer-like testing.
So yes, time was invested in TPI, but at the end of the pipeline, we now have more time to invest in more effective testing.
TPI is a cost but spending that cost in the right area will produce a return. The key is to pick the right test area to improve!
Recently, two new engineers joined my team. They were straight out of university and had no formal testing experience (other than an hour of making sure the code does what the professor asked – not really testing).
This afforded me a great opportunity to stop and think about how best to develop people new to testing into truly stellar testers. So what was my training plan?
This was their first month.
Then they had to use what they learnt.
Then, it was time to walk on their own.
Within 2 months I was receiving feedback from testers and developers at other sites around the globe praising the contribution of the new testers. Now, 6 months on? I have two great testers who I trust. They find good bugs, high priority bugs. They are great at critically analyzing the software under test and I continue to get regular feedback praising them.
At the time, it was quite a turnaround to invest so much time and energy in development. Previously, most people joined and started bashing away at the tool within hours of setting foot on company soil.
The investment has paid off and we continue to prioritize their learning in parallel to their project work today. These two engineers have a very bright future in testing and will easily surpass me and their more "experienced" peers in a very short time! Success!
How did you learn to test? How do you train testers in your organization? Please let me know, I'd love to have some external input.
Note1: The ISTQB Foundation Certification by no means equals testing proficiency. Frankly, in my opinion, the foundation exam is more about terminology than anything else. However, it does give a sense of achievement and is something to work towards. Also, I found for engineers who are completely new to test, it was an effective discussion trigger. They would frequently have discussions between themselves regarding the topics covered in ISTQB as well as asking me questions regarding the actual practicality of testing versus the theory. From that aspect, I found it very valuable. The cost? Book + Exam Fee – not bad and the engineers felt a sense of achievement and career advancement.
The ultimate expectation of a test lead is to:
"always do what most needs to be done without waiting to be asked"
A test lead position has both technical and managerial elements.
A test lead:
- is a domain expert of the software under test
- is a testing expert
- has testing experience to draw upon
- has project planning capabilities
- has excellent communication skills
- actively manages all stakeholders
However, the test lead also has responsibilities towards his/her team to:
- energize
- empower
- support
- communicate
- coach & mentor
The most important test lead function is to get his/her people excited and inspired - to energize them!
The second most important test lead function is to develop the skills and capabilities in his/her team so that they can get the job done efficiently and effectively!
A test lead is only ever as good as his/her team and it is the test lead's responsibility to get the most from the team.
A successful team = a successful team lead!
Test leads:
- get things done individually and through others
- use scarce resources to the best advantage
- cope with change and uncertainty
- achieve and deliver results individually and through others
- assess and proactively manage risks
- allocates testing resources where they are most effective and needed
- gathers evidence to support quality judgments
- coach and mentor
- delegate
Delegation is a vital tool in a test lead's arsenal. A test lead cannot do everything themselves. They must trust their team and delegate tasks to them. Delegation is extremely effective when executed well.
Delegation Hints & Tips
For delegation to be effective, test leads must also give authority to their team members and ensure that those team members have the resources necessary to complete tasks effectively.
The seven steps to effective delegation are as follows:
1. Communicate the task.
2. Set the task in context.
3. Determine standards.
4. Grant authority.
5. Provide support.
6. Get commitment.
7. Keep in touch.
Visit your team members and check their progress on a regular basis.
Use a formal system to track assignments and due dates.
Motivation Hints & Tips
Motivated team members are vital to the success of the project and the team.
To motivate your team:
- Personally thank people for doing a good job. Do it timely, often, and sincerely.
- Take the time to meet with and listen to people - as much as they need or want.
- Provide people with specific and frequent feedback about their performance. Support them in improving performance.
- Recognize, reward, and support the promotion of high performers.
- Provide information on how their work affects the greater scheme of things in the company. Show them that they make a difference!
- Involve people in decisions, especially those decisions that affect them. Involvement equals commitment.
- Give people a chance to grow and develop new skills, encourage them to be their best.
- Provide people with a sense of ownership in their work and their work environment.
- Strive to create a team that is open, trusting, and fun. Encourage new ideas, suggestions, and initiative.
- Learn from rather than punish mistakes.
- Celebrate success!
Remember: For the most part, YOU determine how motivated and de-motivated your team is!
Lisa Crispin & Janet Gregory propose the following ten principles for agile testers:
I believe that these principles are relevant to all testers, not just agile testers.
Lisa & Janet define an agile tester as:
"a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development."
Again, this isn't unique to agile testing. In my mind, all the high expectations we have of agile testers should also be applied to any tester.
Why have lower standards for testers not involved in agile software development?
Reference: Agile Testing – A Practical Guide by Lisa Crispin & Janet Gregory
"Eliminate Waste" is the fundamental principle of LEAN.
Waste is defined as anything that does not create value for a customer.
It's essential to learn to identify waste if you are to eliminate waste.
If there is a way to do without it, it is waste!
The 7 wastes of software development are:
My translation to testing:
Unneeded test infrastructure encompasses extra test features/tools that are not utilized in the test effort but are nice to have (kind of like extra features, they are nice to have but not used). Similar to software development, it is best to not commit to extra test infrastructure features until they are actually needed.
Passing tests do not add value to testing when the main objective of testing is to find defects. Passing tests do not find defects.
Eliminating waste increases time available for activities that do provide value and allow testing to be as effective as it can be.
Within a week of hearing that Professional Tester is back on the shelves, I had signed up for a subscription.
A European-based testing magazine with the aim "to provide practical help and inspiration to testers everywhere" – fantastic!
However, it may be too early as the magazine is just finding its feet, but I am fighting disappointment.
Number 1 = 15 pages, decreasing to 13 once ads are removed.
Number 2 = 19 pages. Okay, it's meatier. It has a couple more articles.
The articles have interesting elements – but they're not rocking my world!
BUT, it's only number 2 and a magazine is only as good as its contributors so I'm putting out a call to those that read my blog: lets share our knowledge!
Let's make this magazine something that works for us! There is a large test community in Ireland who are knowledgeable and experienced and this magazine is a great opportunity for you to contribute!
So contribute!
Exploratory testing combines learning, test design, and test execution into one test approach.
We apply heuristics and techniques in a disciplined way so that the actual testing reveals more implications than just thinking about a problem.
As you test, you learn more about the system under test and can use that information to help design new tests.
Exploratory testing should start with a charter of what aspects of the functionality will be explored.
It requires critical thinking, interpreting the results, and comparing them to expectations or similar systems.
With exploratory testing, each tester has a different approach to a problem, and has a unique style of working.
However, there are certain attributes that make for a good exploratory tester.
A good tester:
Successful projects are a result of good people allowed to do good work.
Good testers are continually looking for ways the team can do a better job of producing high-quality software.
They help the developer and customer teams address any kind of issue that might arise.
Creativity, openness to ideas, willingness to take on any task or role, focus on the customer, and a constant view of the big picture are just some components of an effective testing mind-set.
Good testers have an instinct and understanding for where and how software might fail, and how to track down failures.
In my opinion the difference between a good tester and a great tester is that a great tester has the soft skills to influence and communicate in a manner that they become vital to the project, whether they are fighting their way in or are enthusiastically welcomed with an open door.
Let's be honest, not always will everything line up wonderfully for us so that we can do the great job that we know we can do. But blaming the project removes our ability to control and influence the situation so that we can bend to our will.
Great testing requires a toolbox full of soft skills, including:
We often don't sufficiently prioritize the development of these skills in our testers. It's much easier to make the case for ISTQB training expenditure than a soft skill class.
However, if we are to develop great testers, we must invest in soft skills as well as technical testing knowledge.
I've just finished viewing another Sogeti Webinar, "Applying TPI®NEXT to your situation".
Sogeti is a commercial business and I have links to them:
They're not concrete links – I don't benefit in any way financially from them (although I'll never say no to a free book). But they are links nonetheless.
So having "come clean" with above links, I want to take this opportunity to thank Sogeti.
They are doing an incredible job of educating the test community in Ireland with their free webinars!
Every time I attend a webinar, I learn something, my pre-existing opinions may be challenged, or I look at something in a new way that opens up exciting ideas and opportunities to build on.
Each webinar is recorded so if I have a conflict and am unable to watch "live", I can catch up later.
If you're not viewing these webinars, then you are missing out!
Check out: http://www.sogeti.ie/en/News--Events/Events/ for their upcoming scheduled webinars and http://www.sogeti.ie/en/Resources--Downloads/Thought-Leadership-Presentations/ for their archive.
