Thursday, 5 June 2014

Reading List - 2014

My Top reading list

Reading List

See reading list below:

 

Index

Title

Area

ISBN/Ref

Notes

  1.  

Fish!

Management

978-0786888825

 

  1.  

The Testing Practitioner

Testing

978-0340819807

 

  1.  

The Right Stuff

Testing

978-0099479376

 

  1.  

An Introduction to General Systems thinking

Testing

978-0932633491

 

  1.  

Performance Testing Guidance for Web Applications

Testing

http://www.perftestplus.com

 

 

  1.  

James Bach lessons learnt in software testing


Testing

978-0471081128

 

  1.  

How to Break Software security – J Whittaker


Testing

0-321-19433-0

 

  1.  

How to Break Software: A Practical Guide to Testing – James A. Whittaker

 

Testing

0-201-79619-8

 

  1.  

Testing Computer Software, 2nd Edition

 Cem Kaner, Jack Falk, Hung Q. Nguyen

 

Testing

0-471-35846-0

 

  1.  

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

- James A. Whittaker

 

Testing

0-321-63641-4

 

  1.  

The Domain Testing Workbook - Cem Kaner (Author), Sowmya Padmanabhan

 (Author), Douglas Hoffman 

Testing

N/A

 

 

 

 

End of Document

Saturday, 16 November 2013

Notes from "testing in an agile software development team" - James Bach

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



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!

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