URL: http://www.youtube.com/watch?v=vqwyMaHcjQE - My notes below on the attached url
Testing in Agile Scrum
Covering: Sprint Planning & Sprint ONLY
Testers role in Agile: Tester is the headlights for the product.
Key activities in sprint planning & Sprint:
1. Pre-req:
Learn about product
Learn about users
Learn about Technology
Learn about environment
Learn Learn Learn
Sprint Planning:
Role during sprint planning is to prepare how you are going to find information about the status of the product and reporting on it.
During sprint planning, focus on Testability of the product:
3 Elements:
- Observability: How easy is it to identify the state of the software. eg Log outputs
- Controllability: Can the product be put into states, control state
- Simplicity: Are they implementing complicated code
- Highlight impacts to testing of what's discussed
- Highlight how you could test certain features
- Highlight are you feel will be difficult to test (Maybe special tool/interface is required)
- Ask how features are going to be implemented
- Highlight features which are easy to develop but challenging to test due to (Data required, tools etc)
- Bring to the meetings any Design documents with ambiguous statements etc, alert developers of areas of concern.
Sprint:
Outline Risks,
Outline notes
Develop Informal test ideas and build towards formal test ideas on top of that
Do testing on Developers build to tackle easy defects (90mins sessions with developer)
Build respect with Developer
Test alongside with developer
Keep developers in flow of their work
Be PIT crew for Developers
Be careful on spending too much time on tools (Tool supported testing)
- Test data generation tools
Saturday, 16 November 2013
Sunday, 20 October 2013
Using Elicitation Techniques in Test Design!
[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!
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!
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)