Showing posts with label teams. Show all posts
Showing posts with label teams. Show all posts

Monday, 12 October 2015

Testing Skills #5 - Remote Experiential Learning


Many people work with teams which are globally distributed, this has some logistical issues, one being how to implement useful and practical training approaches.  One common approach used is C.B.T. (Computer Based Training).  This is where participants login in and listen to pre-prepared exercises and videos, sometimes with a test at the end.  Another approach is to arrange a video session with an online tutor where they go through the material and the participants can ask questions whilst listening to the tutor.  These are OK as learning tools, but it is difficult for the participants to apply the knowledge learnt to their daily role. 

There is an alternative distance learning approach that I experienced whilst attending an online workshop run by The Growing Agile team (Samantha Laing and Karen Greaves).  I have since this course created my own remote workshop using this approach with some success.  What follows is an introduction to this approach.  Hopefully you can take this and adapt it for your own teams.

The basic principles of this remote training approach is based upon the 4Cs as described in the book “Training from the back of the room” by Sharon Bowman. Each of your learning elements should include all elements of the 4Cs in each module.

For each module of the course I create a workbook which goes through each aspect of the 4Cs.

The first ‘C’ is Connect

Before you start teaching the students ask them what they already know about the topic.  Create activities they can do offline to find out how the topic is relevant to their current role or what they currently know about the topic.

The next ‘C’ is Concepts

This is the traditional learning part, where you can introduce and explain what the topic is about.  You can do this as either a series of written articles or pre-recorded videos.

The third ‘C’ is Concrete practice

Students apply the concepts in practice.  If you are running this remotely you can set up activities and exercises related to the concepts which the students should, ideally, apply to their own working domain.

The final ‘C’ is Conclusions

This is best to done as a small group, maybe as an online video call.  All the students get together and discuss what they have learnt.  This is a great way to reinforce the learning since each person should bring different examples of applying the learning to the discussion and provide a more context rich learning experience.


When you are looking to create any remote learning experiences it is worthwhile making sure that each of your training sessions covers all aspects of the 4Cs. An advantage this learning approach gives is that it requires only a couple of hours of learning from each participant.  They can do this at their own pace and then discuss their learning and how it applied to them during a weekly hour long video conference call with the others taking part in the course.  It is crucial to set your expectations of the participants and get them to give a commitment to spending some time doing the exercises before the video call.   

As an additional option when I ran my remote workshops I set up a closed wiki site so that the participants could have discussions and provide some information about what they have learnt.   Also with permission from the participants I recorded the video sessions  and uploaded them to the wiki so they could go back and watch them later.

Monday, 28 September 2015

Testing skills #3 - Leading Teams

If you are leading a software development team it is a good idea to provide to provide an environment in which each member of the team feels safe, valued and important.  It takes a lot of skill to lead teams without resorting to command and control style of managing the team.  Providing the team a safe environment in which it is OK to experiment a little and be able to learn from failing is crucial to encourage creativity and innovation within the team.   When leading a team in this way you can act as the facilitator and ensure that the bad elements of teamwork do not start to impact the team dynamics.  You can be the sounding board, the oracle, the voice of reason, the mentor, the confidant, by doing this you encourage the team to flourish which leads to success.

As a leader you also need to give the team a clear direction of what you expect the team to deliver, this can change as time passes however, this should always be transparent and visible to the team.  Ask yourself as the leader what do you want from the team?  What is your ultimate goal and then explain that to the team along with your preferred priorities.  Then step back and watch the team self-form around the problem to provide you with a solution.

The principles behind the the agile manifesto has some useful tips for leading and working in teams.
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
J Richard Hackman provides the following five tips for leading teams.
  1. Teams must be real. People have to know who is on the team and who is not. It’s the leader’s job to make that clear.
  2. Teams need a compelling direction. Members need to know, and agree on, what they’re supposed to be doing together. Unless a leader articulates a clear direction, there is a real risk that different members will pursue different agendas.
  3. Teams need enabling structures. Teams that have poorly designed tasks, the wrong number or mix of members, or fuzzy and unenforced norms of conduct invariably get into trouble.
  4. Teams need a supportive organization. The organizational context—including the reward system, the human resource system, and the information system—must facilitate teamwork.
  5. Teams need expert coaching. Most executive coaches focus on individual performance, which does not significantly improve teamwork. Teams need coaching as a group in team processes—especially at the beginning, midpoint, and end of a team project.

Leading Teams: Setting the Stage for Great Performances - J. Richard Hackman - 2002

Friday, 19 September 2014

Agile testing activity checklist

As the barriers between development and test blur when working in scrum teams and being agile, the testing activities can sometimes be lost.  There may be occasions where there is no testing expertise in a scrum team and the scrum team members struggle to know what to focus on regarding testing activities in their sprint.

Since this was becoming an issue with some of the teams I was involved with, myself and others came up with a testing activities checklist based around Lisa Crispin and Janet Gregory agile testing quadrants.

The rest of this article shows this checklist.  Please feel free to adapt and change this checklist to meet your testing needs in agile scrum teams.  The only caveat I make on this is that if you find it useful please let me know.

Testing Activity Checklist
This is an example template for Scrum teams to use as a checklist for testing activities carried out during a sprint


Sprint Number:
Does the scrum team have any testing expertise
Yes / No 
Has the scrum team done any testing activities in this sprint?
Yes / No 


Unit/Component (Q1)

Check
Response
Comments and Justifications
Do Unit Tests exist?
Yes / No

What is the level of unit test coverage? (Sanity, bad input, edge cases, regression etc.)


What is the quality of the unit tests? (per quality key table below)


% Code coverage and have you met your target %? (Which tool used?)
nn%

Has any state coverage been done?
Yes / No

Zero static analysis violations
Yes / No

All check-ins have code reviews?
Yes / No

All check-ins have unit test reviews?
Yes / No

Are unit tests automated in a CI?
Yes / No

How often are unit tests run? (every check in of development code/nightly/other)


Unit testing added to Definition of Done (DoD) 
Yes / No



Functional (Q2)

Check
Response
Comments and Justifications
Functional tests exist?
Yes / No

Have acceptance test criteria has been reviewed?
Yes / No

What is the coverage of functional tests (See below - coverage key)
0-3

Are functional tests automated?
Yes / No

A CI System is being used for automated system tests?


How often are automated functional tests run? (every check in /nightly/other)


Are functional tests run against latest build?
Yes / No

Has manual functional testing been done (exploratory)?
Yes / No

Functional tests added to DoD 
Yes / No




Coverage (Key)
0
We have no good information about this area
1
Sanity Check: Major Functions & Simple Data
1+
More than sanity, but many functions not tested
2
Common cases: All functions  touched common/critical tests executed
2+
Some data. State or error coverage beyond level 2
3
Corner Cases: Strong data, state, error or stress testing

End to End (Q3)

Check
Response
Comments and Justifications
Has exploratory testing been done? (if not give justification)
Yes / No

How much time has been spent on exploratory testing (number of sessions)
nn

How has exploratory testing sessions been captured (Wiki/other tool)

What is the quality of the acceptance criteria (see below for definition of testing quality)


Acceptance criteria tested
Yes / No

Demo criteria tested
Yes / No

E2E customer tests added to DoD 
Yes / No



Quality Key
**
We know of no problems in this area that threaten to stop go live or interrupt testing, nor do we have any definite suspicions about any
**
We know of problems that are possible showstoppers, or we suspect that there are important problems not yet discovered
**
We know of problems in this area that definitely stop go live or interrupt testing

Non Functional (Q4)

Check
Response
Comments and Justifications
Nonfunctional tests exist
Yes / No

Which types of Non Function Tests exist?
Performance, Reliability, Usability, Stress, Spike, Scalability, Endurance, Volume, and Security (e.g., CSDL)


Yes ? No

Have nonfunctional tests been added to DoD
Yes / No



Testing Activities Definition of Done


Check
Response
Comments and Justifications
Has all DOD criteria been met for each quadrant?
Yes / No

Zero open defects in the sprint
Yes / No

100% of all possible automated  checks running (Unit, Functional / E2E)
Yes / No

100% automation pass rate.
Yes / No

Exploratory testing target met (% possible time spent exploring)
Yes / No

CI Builds are in place
Yes / No

Sprint demos and feedback given.
Yes / No



Testing Quadrant Dashboard
This is a simple checklist dashboard.  It is either green or red, have all the activities listed above for each quadrant been completed.  Yes=Green, No=Red.

Q1
Q2
Q3
Q4
 Green = Met DOD for that Quadrant /  Red = Not met DOD for that Quadrant

I have also uploaded a word document version here so you can adapt and change it to suit your needs.


Postscript:

I will be running a Creative and Critical Thinking workshop in London - Thursday 16th - Friday 17th October 2014