For those of us who began our testing careers awhile
ago, let’s not put a number on it, we have perhaps worked in a variety
of domains using a variety software development practices. The most
popular we used was perhaps some form of Waterfall. However, regardless
of the methodology at hand, serious software testing often proved to be
a collage of scientific, philosophical, highly analytical,
genealogical, research-oriented and statistical practices. Some of us
have even watched our once purely analytical approaches embrace a more
technical approach with the popularity of test automation tools.
we were honest with ourselves, we all knew waterfall or any modified
version was not working for testers. We were one of the final phases in
the process and almost 100% of the time our pre-planned timelines were
robbed by under-estimated planning and development times. We were often
like neglected children not being afforded any early attention to help
us combat our forever shrinking timelines to perform our job properly.
Being the dedicated professionals we were, we continued to use practices
from the traditional testing toolkit to do our job.
Now we have
Agile which promotes the idea of having team spirit with non-testing
professionals to build better software at a faster rate. Admittedly, I
was a traditional testing professional who became suffocated the more
companies embraced the idea of immediately responding to customer
demands and then being so-called Agile. This is when I began to realize
all of my test automation innovations would prove to be a valuable
asset to support the agile software development phase we are now in.
have often worked for small development companies where we were often a
very tiny team of QA professionals with a ratio of 1 QA per 8
developers. Test automation was a way of life for me and helped me to
become agile prior to the methodology being introduced to the
development world. I realized investing and designing test automation
frameworks, regardless of the tool, provided me with a reliable virtual
tester. I began to strategically expand my automation efforts over time
so with each short release cycle now called sprints, the Virtual Tester
could provide greater and more thorough regression test coverage which
often saved us many times from releasing embarrassing mistakes.
agile gained in popularity, I adopted TDD methods before I even learned
there was a methodology to support it. With a robust framework, one
could develop functional test cases that now could validate the software
met the business requirements. The mentality changed from the
automation script should find bugs to the code is not ready until the
script can pass without fail. This method allowed us to be very
proactive in our test efforts and to further find innovative ways to
streamline the test management process, the test development process and
of course the test execution process. Exploratory became a process to
learn the ins and outs of a feature which flushed out the early bugs and
allowed for us to design and develop testing methods. The framework
grew and matured year after year allowing us to always add new
functionality, refactor old functionality because the maintenance had
become quite minimal. The innovations even allowed us to reuse the
framework across multiple applications.
Then companies began to
mature their agile practices. They were growing from quasi-agile
practices to pure agile practices (Dancing With Pigs, Timothy Krosnan).
For the first time in my career, I realized, I had to completely let go
of the quasi-traditional toolkit I had been using and develop and adopt
an agile testing toolkit.
As I said earlier, we learned the
waterfall and its many variations were not working for testers. All the
iterative approaches failed testers and the testing process. I had
believed so much that I was ahead of the curve and then I realized I was
and yet I wasn’t. I was still trying to use antiquated practices which
were impossible to implement and maintain in a pure agile team.
Furthermore, there wasn’t a lot of guidance out there on how to make the
transition and how do we perform the important tasks we believe needed
to be done in these short time blocks with a collaborative team. The
only true reference was Lisa Crispin’s Agile Testing book. Being a
tester who has worked with a variety of domains within a variety of
industries, believe me when I say, you always have to learn to use a
toolkit to build your own methods and practices that fit the industry,
the company and the team you are working in. So I began a new adventure
to learning how to leverage techniques and tools to streamline the test
management process and marry it to the test development and execution
Believe me the tools are there! I know many of you are
not technical QA but you must learn how to use them (or collaborate with
those who can use them) in order to make the job possible. We still
need time to be analytical, to research, to develop statistics and to be
philosophical. So we need to eliminate and streamline as much of the
waste as possible. We have to learn to master these tools to capture
and maintain only what we vitally need. I remember talking with my
brother about the difference in how men and women communicate. His
analogy was “men only require the headlines while women require the
story under the headlines.” Using this analogy, we need to learn to
capture only the required headlines that allow us to completely
communicate the plan, allow us to make it readable and visual and
furthermore re-usable! How many times have you invested the time and
energy developing tedious, long drawn out test plans that no one reads
It is not easy retraining the mind to see outside the
box. It is not easy for all of us to develop the technical capabilities
to implement some of the changes. So we collaborate, we leverage
development and we make it so our test management process works
seamlessly with our test case development and execution processes.
of us working in industries who are required to report to external
governing entities or collaborate with them to provide solutions, like
the financial industry, well we still need those tedious documents.
However, I would challenge to find ways to eliminate the waste by
learning how to better capture the information and reuse the information
provided within them. The technical world is growing and evolving
again and we must never be shy to grow and evolve with it.