Webinar: Integrate Test Activities in Agile Projects

Integrate Test Activities in Agile Projects


I attended the webinar from Rik Marselis about integrating test activities in agile projects (slides).
The topic caught my attention because I am currently solving this issue in my job especially around manual test activities.
The existing process used to focus mainly on web tests but has evolved to include unit tests and now also includes manual tests executed by a professional tester instead of just the PO.

The talk started with the acronym QD.

I had never heard “Quality development” as a term before when referring to agile development. Maybe it was implicit but I could relate to QD being described as “Quick Development”, especially when the emphasis was on just getting features out there quickly, to be revisited at a later date to improve usability.

In my experience this does not happen unless there is a blocker as in the new features becomes unusable for some reason or causes too much of a maintenance headache. 

I recently did a short talk at my company about Agile testing and how we are trying to integrate test activities (especially manual testing) into the scrum teams, and like Rik I also referred to the Agile Manifesto.
He, unlike myself, argued that it does not have strong footholds for testing in an agile development project. I would argue that it includes the main parts for testing to be successfully integrated namely, people and interactions, collaboration and responding to change. if these ingredients are not in your scrum team than testing cannot be successfully integrated in my opinion.
You need the team to be interacting and sharing to make testing possible and to avoid duplication of the testing effort. This goes hand in hand with collaboration and responding to change. As issues are uncovered the team needs to work together to fix these/make changes if new requirements are uncovered.


Rik went on to mention the Scrum guide which I have not read in detail and hence will not add anything to right now, but this did yield a couple of valuable pointers.
Testing is described as inspections performed by skilled inspectors with adjustments made asap and each increment being thoroughly tested.
Thoroughly is a word which actually rubs me up the wrong way and Rik seemed to agree. “What does thoroughly mean?” 100%? 100% test coverage is not possible, who decided what is thorough and adequate?


The development teams I have been involved in recently talked about a definition of done in terms of if all development streams are on the same page. We mentioned code/features/stories to be adequately commented/documented/tested (automation and manual).
I understand that in scrum methodologies these sort of guidelines for a definition of done need to be flexible to an extent but using words such as adequate and thoroughly when these are subjective seemed incorrect to me. Maybe more on that in another post.

Add caption



Testing during agile development should be about providing an insight into quality and risks. Defects should be identified as soon as possible, with exploration into root causes to avoid them in the future.
Through exploratory testing we  should yield re-usable test cases as each increment should be thoroughly tested and will therefore need a regression testing phase.
Keep testing transparent!
This is feedback we have had in my current teams that the developers were unsure about what I actually do. We try to combat this by writing test charters and acceptance tests and circulating them for anyone who wants to read them/use them as broad guidance to ensure code test coverage.
This follows onto the next point that was made that testing is a skill that should be integrated into the team, preferably in the form of a skilled/professional tester. Long gone ae the days of sub teams. We need to make the transition of an us vs them mentality and become a valuable asset of the dev team. By thinking outside of the box and like a user, testers can integrate into agile development teams to provide another set of skills.
However testing is not just a developer/tester activity. Test integration also needs the PO to review/test the stories and features, ideally before the actual end of sprint review. This can ensure they accept the result of the sprint as at the end of the day they will make the decision if a sprint was successful.

During planning the Scrum Master can act as a tester helping to define acceptance criteria and making sure the proposed designs are fit for purpose and will create a product of high quality. This process of questioning can minimise rework for the whole team and ensure they are focused on the same outcome.

This small list from the talk highlights the whole team approach that is so important for success.
To be fully integrated testing needs to be part of each step of the way, during planning to identify risks and start planning which tests and test tools may be needed. then while the features are developed, the tester creates and maintains their tools which ideally can be used by the whole team.
The test strategy will not just depend on the project but also on the sprint and tasks associated with this. To make testing more transparent Rik mentions adding tasks around testing to your sprint/scrum boards. I may well do this and try it as part of our next project as the team is growing and it would be nice to offer some guidance on what is needed to perform the tests required for that sprint and let other testers take over the creation of test data/environments etc. Tester in the context here also includes developers, Scrum master and POs.

The pitfall of a test strategy according to Rik, is to focus solely on unit testing or functional tesing only and how to automate them. Manual testing can expose certain scenarios that machine simply cannot and hence we need to consider the user perspective.

It may be useful to think of different testing objectives instead. Objectives of each level of testing need to be considered when defining and executing testing. What should the unit tests cover/ensure? What should the web tests cover? What risky areas should the manual tests look at? Is manual testing focused on usability?
We try to manage unit and business tests during the sprint and automate them accordingly. Also each story or feature has a web test added if appropriate and is tested manually.
We then perform full end to end tests when code is about to go live on our most like production environment (however this still could be closer to the actual live environment).
Throughout this process we run automated regression tests also, because manually regression testing is simply not possible anymore.

Like development we need to look at testing when integrating it into an agile development cycle to be sustainable. integrate activities as early as possible and as many layers of testing as possible. Assign tasks for the different layers to skilled team members, ie. unit tests are written by developers. testing needs to be considered to be a task of the whole team.

With that in mind consider reviews as a form of testing that can ensure quality from day 1.

I took a lot from this talk and hope to put forward the idea of also tasking up testing tasks to make them more visible to the team. I think this could be valuable as it can also be a good training tool and won’t be micro management. Certain tasks can be split across team members (not just testers) and reviewed in a peer review before being considered to be done.
This would offer a platform for learning and sharing in my opinion which is a big part in successfully integrating the testing effort into the team.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s