[Improvement in progress - 21/05/14]
Lessons learnt from BCS Requirements engineering course:
Business , Project and External stakeholders, all have knowledge/information about System/Applications. This knowledge can be very valuable and aids in requirements,development & testing.
Having attended the course it highlighted that: Business Analyst gather information about problems to document them, Testers gather information about problems to exploit them. The challenge we all face is understanding the system, the stakeholders and their requirements.
"There are things we know we know. Things we do not know and Things we don't know we know." Donald Rumsfeld
The knowledge from Stakeholders falls into two groups - Individual and Corporate and are grouped under Tacit and Explicit.
Explicit knowledge covers that which is documented in some shape or form.
Tacit knowledge includes Skills, values, culture, organisation history and so on, which are usually overlooked. Tacit information is that which has not been documented or formalised in any way but is current information which still apply s. This knowledge is also just as important to the test team.
Business Analyst using Elicitation techniques to drive out both Tacit and Explicit information. This includes Interviews, Workshops, Observations, Focus groups, Scenarios, Document Analysis.
These are techniques/tools applied in requirements gathering which can be used during test design to generate test ideas.
The Key with using these is to identify who is best to apply which technique to, with a goal of getting the right information.
Workshops with subject matter experts can be very effective in identifying possible problematic areas and tests that can target these areas.
Observations can be used with users to build knowledge and identify tests which users might take for granted. eg a shortcut used in an old system might cause issues with a newly implemented system. Users attitudes can also be examined to assist testers in designing tests. This can be achieve by watching staff using the systems, wandering about the work place or shadowing individuals of teams.
Document analysis which testers usually do is the reading and analysis of source documentation, such as functional specifications, requirements documents, user guides, forms etc to identify test conditions. This involves breaking down testable statements in documents and questions and writing tests against them.
Scenarios can be very effective in breaking down tests into activities rather than individual tasks. Some situations require this due to their complexity and where actions have several dependencies.
Quick summary: Elicitation techniques are used by testers, it is a skill worth expanding to aid in becoming better testers. The better our ability to extract information the more test ideas we could come up with.
NB: Please note this is yet to be reviewed!
Sunday, 20 October 2013
Tuesday, 8 October 2013
Disrupt and shakeup your testing Career!
Introduction
I read an article on linkedin by J.T. O'Donnell about career development and
why we should proactively reinvent our core competency models. This led me to a
comment and an amended quote about career development:
“Careers are not meant to be static," ... "In the
world we live in today, you have to adapt and change. One of my fears is being
this big, slow, constipated, bureaucratic professional that's happy with its
success. That will wind up being your death in the end." (an amended quote from Nike CEO, Mike Parker)
J.T. O'Donnell also stated "Creatures of Career Comfort Today…Professionally Challenged
Tomorrow"
This made me think of the testing role and the need to
challenge what we do.
Being Static
We allow ourselves on occasions to settle into our job
thinking, “I’ll just do this for a while,” which is a dangerous career move.
I’ve identified this as being Static, we do what’s needed
and move from project to project not changing or adding to our core. We are at
times restricted by the projects due to timescales, or rigid client processes
and hence have little flexibility. We end up avoiding the need to evolve and
build our skills in exchange for the immediate gratification of our current
situation. This also includes our skills us testers. We end up testing only
what we are asked to test. The pros of this being we prove we are competent at
that role and gain support/confidence. Cons being we don’t expand our skill set
at such roles and we don’t necessarily provide our customers with our full
testing potential/expertise.
We at times tend to avoid being proactive in our roles
because it requires additional time and effort. It is often said, “We are more
likely to wait until we need the aspirin, than to be consistent in taking our
vitamins.” It’s in our nature to avoid the extra work until the pain is too
intense and we finally have to take action. e.g. A performance tester,
identifying performance requirements, then building their standard performance
test rig to test the requirements provided only.
Being Dynamic
Taking action I’ve identified as being Dynamic. Here we make
a decision to disrupt our skill sets and build some new areas of expertise. We
get proactive and creative when we take action and try new things on projects.
We can also read about new approaches or get new ideas from
blogs or colleagues and aim to implement then in what we do. Being Dynamic
would cause the same performance tester, to come up with new ideas of applying
artificial intelligence to their test rig and creating something new.
Pros being new skill set is obtained and value added to the
customer. Cons, more time consuming and you may not necessary have
time to experiment on projects.
Conclusion
Both have a positive and negative side hence feel we should
constantly aim to be dynamic but also identify the situations where we should
be more static. Ideally we should constantly aim to switch between these per
task assigned. I feel this will make us better testers are we will constantly
be aiming to learn something new and applying it at every opportunity.
J.T. O’Donnell stated the following: “Anyone can be
disruptive in their career/role, but nobody is going to do it for us. The
longer we wait to build our skills and abilities the harder it will be to
remain relevant. If you ask yourself “Why can’t I just do my job and not worry
about this?” your answer is “ Life isn’t
about finding yourself. Life is about creating yourself.”
We can either look at disrupting our career/role as a chore,
or as smart choice. “
My suggestion is to create a mental plan to constantly
challenge/disrupt your role so you don’t remain constantly static or constantly
dynamic and use the tools you have available.
Figure 1 - Tools we have available to us - @cartoontester
What you can do today?
I have suggested examples of things you could start doing
today to start disrupting your career:
1) Review
your current skill set and ask yourself, “Will these skills be relevant in 5
years?” Also brush up on core skills and core company processes
2) Find a
book about a field or industry of interest to read or books on ideas you have.
There are also several testing books if you want to broaden your knowledge.
3) Take an online
course that can be completed at your convenience.
4) Attend a
webinar/conference in something indirectly/directly related to your current
area of expertise. You could also read articles or blogs e.g. Satisfice.com, Developsense.com, Seven Ways
to Find Software Defects Before They Hit Production
5) Identify
a project you can do on your own time that isn’t directly related to your job,
but has an impact on the company.eg learn an Automation tool and use it
6) Identify
a mentor or someone you look up to and set up quarterly meetings with them to
share ideas, issues for them to help you with developing your skills.
7) Start a
hobby to develop a new skill set.
8) Write an
article to share your thoughts, experiences and topics you find interesting.
9) Set a
goal to meet people that are considered experts in their field that somehow
overlap with your own industry and ask them questions about what they do. meet
up sessions are a good start.
10) Identify
something you are doing now, that you could do differently and ask yourself,
“How could I use my skills to improve things?”
Recommended reading/References
Subscribe to:
Posts (Atom)