The meetup was held at the Orient hotelin the rocks, and the place was pretty full. I thought I was smart to take a seat in a couch in the back, but the open window (non-closable) made my fingers stiff and body shaking throughout. =(

Evening kicked off with some networking and a beer, followed by opening notes with club news and testing news. I particularly like the short testing news highlights. Don’t forget to follow up on the highlights!

The Presentation – Journey of Acceptance test driven development

Devesh and Priank told us about Acceptance Test Driven Development, ATDD (slides here). All in all, the presentation was a good mix of technical/practical aspects of ATDD and the more in-depth understanding of why its a good practice for collaboration and shared understanding. The guys know what they are doing in their work, but capturing the most important parts into a 50 minute presentation is not easy. But they kept the crowd engaged and got good questions that they answered very well.

The name ATDD can be hard to grasp or accept, and that is usually caused by the acceptance test part. They mentioned it later in their presentation, but I would like to point out already, that ATDD is pretty much the same as BDD and Specification by Example, they are all example based models for specifications. Also, there are problems calling them acceptance tests, as the notion of rejection checks is a better term in general. There is also already some discussions going on in the meetup thread on this topic.

The presentation was going to start with what ATDD really is (according to their own agenda), but they started off with some slides on why projects fail. Surely there are plenty of reasons for that, but for me that was kind of like selling ATDD as the silver bullet, it is not! Sure, projects are more prone to succeeding with good collaboration and communication, and ATDD can help with that, but that’s where I would stop suggesting ATDD for not getting failed projects.

Then we got to know how ATDD and TDD work together, TDD solving the “Are we building the product right” and ATDD solving “Are we building the right product.” While these statements might have some connection here, I would rather not see TDD and ATDD being referenced as equivalents of validation and verification that traditionally are tied to these sentences.

They continued by saying that the most important parts of ATDD were really the conversations and ways tog get shared understanding of the product between stakeholders. I completely agree here, and I would actually have wanted them to continue with this bit a little more. The end of the presentation had plenty of great gotchas for benefits, challenges and anti-patterns for ATDD, but unfortunately these bits were cut short because of time. Be sure to check those slides.

Instead, we got to see some live code examples of scenarios running cucumber in an example with webdriver. We also got to see them run off a live test suite from a current project of theirs. This is a nice way of showing off some of the technical aspect of the practice. The example of the web form was also good to see how to actually write the examples sensibly.

However, the automation is also a way to easy alienate parts of the audience that 1, is not technical enough and 2, that dont have any web ui in their product contexts. Anyway, examples like this do have a pedagogical way of showing off the concepts for better understanding, so they are valid in this broad intro session on ATDD. But it is really important to remember that the type of automation one wants out of ATDD in their project need to have plenty of context considerations before adding all those layers of UI testing. The simple code examples can be found here.

There was also a section on how to create good acceptance tests by making them SMART, however this is something usually referred to when talking about SMART goals or objectives. I cannot find references to SMART acceptance tests, so I would like to get that clarified.

I think the presentation was worthwhile, and i am happy I took the time to go. I picked up some new things, like the poltergeist headless browser. But it should also be said that it was an introduction to ATDD, so having heard about it many times, no new things were really covered. As we have a very diverse crowd of both test managers and non-technical folks, I think many people at the meetup had also never heard of it.

My 50 cents on ATDD

Naming – I use the three names ATDD, BDD, Specification by example interchangeably, as I have seen benefits of the different names in different contexts. Although it is important to note that the three have different background and differ slightly.

Cucumber/Gherkin is a nice tool for the living documentation, and there are plenty of implementations of it for different languages and fixtures.

If you dont have any business stakeholders valuing the gherking specifications, they might just be a waste in terms of yet another abstraction layer to maintain. I have seen projects that just as well name their Junit methods in a good way without having the extra layers.

Don’t ever think that ATDD/BDD/SBE is the silver bullet for any quality issues you might have in your product or project. Use it as a tool for communication and complement with other types of testing related activities as well.

]]>https://happytesting.wordpress.com/2014/07/21/sydney-testers-meetup-37-journey-of-acceptance-test-driven-development-sydtest/feed/0SiggeA new teams encounter with DET/TET as a framework for testing – Part 4-Facilitationhttps://happytesting.wordpress.com/2013/07/09/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-4-facilitation/
https://happytesting.wordpress.com/2013/07/09/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-4-facilitation/#commentsTue, 09 Jul 2013 20:37:07 +0000http://happytesting.wordpress.com/?p=808]]>First of all, I want to be clear that this series of posts have nothing to do with my work at Atlassian. These posts are experiences from previous assignments with Jayway, and I am just now gathering my thoughts on it.

Facilitation

The effort of having 12-14 people involved in testing 2 hours/week needs to be prepared and facilitated. This is something that I usually propose, and the need was acknowledged rather quickly in this team.

It ended up being a rotating task within the development team to take on the facilitator role of the week. However, it was usually natural for some person to be facilitator when it came to different focus areas. This also meant that some people got the facilitator role more often during the time I was there.

I personally coached the facilitator of the week through preparations and all the way through the test session, debrief and meta debrief. Here are some aspects of facilitation that we considered.

Plan focus area

Together with PO and dev manager discuss and decide on the focus area of the week. Also important to isolate parts of the focus area suited for test pairs. By planning of focus area we include scoping of test ideas as well as framing the testing that needs to be done.

Set and publish agenda

For the team to know what shall be tested next time, and have the possibility to opt-in/opt-out, the agenda was sent in the beginning of the week. This also usually triggered spontaneous responses with some test ideas, which was nice to see.

Participants

The opt-out/opt-in systems both had the tendency of being fragile to changes, meaning it was hard to know who was actually taken part of testing until very close to the session. This caused frustration when it came to planning the test pairs and which areas to test. To mitigate this, we decided always to have a thought-out 3-bullet strategy for last minute changes. Ex:

Combine test areas

Pairs can become triplets

Scope out focus areas

This strategy also became usable when certain aspects of focus areas turned out to be blocked for testing for some reason, like environmental or lack of test data.

Pairing

There are some aspect for the facilitator to consider when in the creation of pairs:

Personal profile/role (dev/support/business)

Relevant test environments

Physical place

Test environments

Facilitator is responsible for relevant test environments to be in place. Usually this also included setting up new environments as part of preparations of test session. This was the biggest reason for having the weekly facilitator role, since it became really visible early on that the preparations were crucial for session success.

Another aspect we had to deal with was the need for specific client test environments. When this was needed, we had everyone specify which types of environments they already had installed, and created good test pairs accordingly. These included operating systems, java versions and browsers among other things, that needed to be covered.

During testing

I have seen very clearly that the facilitator really should not be involved in a test pair himself, and that was also the case in this team. Being able to hover the session, the facilitator could help pairs with test environments and data, as well as point them in new directions if they end up stuck. That last part demands some skill and test idea generation before the session.

Also, during one session, the environment accidentally got too much tampered with in certain areas by a pair, and the facilitator then pointed the others to avoid that contamination.

Debrief

The facilitator usually knows more about the areas under test, thus will have a central role in the debrief. It is important to have this in mind when facilitating the discussion about the code that you wrote yourself, your baby. You are stakeholder in those discussions, and will be biased.

The debrief that I promote is a two step activity. Directly after everyone has been testing, there is a need to get the time to express the most emergent things. So every pair gets a very brief time to answer the questions “how did it go?” and “what did you end up testing?”. Usually these questions are not needed to trigger something to be reported, and the most common case is that you have to cut them off for everyone else to get the brief moment. After the first round, its time to actually dig into the details of every pair, decide what are bugs, improvements or other relevant things. I usually encourage discussions, but they also need to be moderated if you want to get through everything that was found.

Sometimes we saw the need to set certain things aside for a triage by dev manager and PO. These included decisions that needed more information as well as pure business decisions.

]]>https://happytesting.wordpress.com/2013/07/09/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-4-facilitation/feed/2SiggeA new teams encounter with DET/TET as a framework for testing – Part 3-Running with the basics!https://happytesting.wordpress.com/2013/06/24/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-3-running-with-the-basics/
https://happytesting.wordpress.com/2013/06/24/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-3-running-with-the-basics/#commentsMon, 24 Jun 2013 11:50:43 +0000http://happytesting.wordpress.com/2013/06/24/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-3-running-with-the-basics/]]>First of all, I want to be clear that this series of posts have nothing to do with my work at Atlassian. These posts are experiences from previous assignments with Jayway, and I am just now gathering my thoughts on it.

Basics

The basic principles of DET (Session, People, Focus and Reporting) are pretty easy to follow, so just doing it basic style will give some value. This is of course a place for a disclaimer, since running with the basics here would be similar to scrum, easy-to-follow rules that are just not so easy to follow. The sections below are about some aspects of the basics that we tweaked to fit the context.

Session

With a quite large team, the sessions needed to have a stated agenda to explicitly highlight the time box. This is and example:

At first we dedicated Friday mornings 10-12 for sessions, but this was revised to 9-11 with an extra buffer for decisions afterwards. Changing start time to 9 also removed the friday daily standups (usually 9-9.15), but this was anyway just waste since everyone was testing those days.

Test time was revised from 1h to 1h15min after a couple of sessions, since the overall feeling of not finishing got better by just adding 15 mins. A later reflection from the dev manager considers the extra need for time being mainly about getting used to the whole format of testing. However, I think that there are more variables here:

Complexity of focus area

Depth of testing

Form of reporting and note taking.

People

A big part of running the sessions are the people involved, and managing pairs towards focus areas. The most important thing here is the pairing. The biggest achievement with pairing is the focus of the people involved. It is the responsibility of both persons in a pair to actually start testing, which will give the session a kick-start. Also keeping the focus on testing during the whole session is a win.

A hard thing was to actually know which people that were taking part of testing, to be able to plan the pairs. We tried both opt-in and opt-out solutions, but this will be something that never gets good without discipline from the team. Fortunately enough, the development manager kept pushing people to take part in testing, preferring the opt-out alternative.

Since we had quite many people involved in testing, we discovered a limit for this team of 12-14 people involved in testing at the same time. This is quite a lot of people, which includes 2 facilitators and a maximum of 5-6 test pairs/triplets. The limit was mostly caused by the amount of test results (bugs/questions/notes) we could handle in the debrief and to be acted upon. A possible solution for this is to follow up the debrief with a smaller and more focused triage meeting, which we did on some occasions.

Focus

Because of the nature of the product, it was never hard to find new areas to focus on. The bigger problem was to prioritise the important area of the week. This depends on many different factors such as:

Areas where code has changed, development focus

Areas where it always is important that no new things arise, customer focus

Areas where findings will be acted upon, management focus

We also learned that the preconditions for DET in regards to focus on new functionality had higher demands on the facilitator.

Reporting

Debrief meetings can take some time when not used to it, but it took about 2-3 until they kept to the time box.

Because of the big group of people doing debrief, we do it in two steps. First every pair gets to say just a couple of things to summarise their session. After that we go through every pairs session notes and discuss bugs and improvements. It has proved valuable to keep the discussion with the same vocabulary for issue types as used in the bug tracker, i.e. Bugs, improvements and documentation. Here we also considered adding new types at a later stage to fit other purposes that we saw.

The company uses the Atlassian tool suite extensively, so it was a natural thing to do to have the written reporting from sessions on the wiki and bugs in Jira.

If there is anything above that needs clarification, please leave a comment. Or you can continue with next post:

]]>https://happytesting.wordpress.com/2013/06/24/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-3-running-with-the-basics/feed/2SiggeA new teams encounter with DET/TET as a framework for testing – Part 2-Intro workshophttps://happytesting.wordpress.com/2013/06/19/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-2-intro-workshop/
https://happytesting.wordpress.com/2013/06/19/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-2-intro-workshop/#commentsWed, 19 Jun 2013 13:15:48 +0000http://happytesting.wordpress.com/?p=784]]>First of all, I want to be clear that this series of posts have nothing to do with Atlassian. These posts are experiences from previous assignments with Jayway, and I am just now gathering my thoughts on it.

The workshop

To get everyone on-board with what we were doing, I started off with a workshop on testing and quality in general. This is important because I want everyone to be on the same page in regards to why testing is carried out and what to expect from it. I carried out the workshop two times at the different locations with all of the developers with some participating support and business consultants as well. As this first round of changes mainly targeted the developers, these were the ones that just had to take part. During these workshops, I also had most of management take part.

I have done this workshop a couple of times before, mainly as a one-day-one time introduction and tutorial to quality, testing, exploratory testing and DET/TET. With this team I had some more knowledge about the context which I could use to adapt the workshop for a better fit. For example I was able to change some of the material with domain language that people are familiar with.

For testers, people that work with testing most of their time, the actual content of this workshop may be on the basic side of things. However, I have created this workshop for teams that have no testers. Also, a big part of the value here are the team discussions about quality and testing of their own product, which may not have been part of discussions earlier. Furthermore, previous discussions most probably did not involve any facilitation.

The basics of DET (Session, People, Focus and Reporting) are the focus of the second part of the workshop. By allowing people to dig in on their own product with the premises of DET, usually creates a space filled with curiosity and playfulness. Also, carrying out an actual test session with a relevant focus area automatically gives payback through bugs found, apart from the obvious healthy discussion around the product of course.

Important factors

There are a couple of things to consider especially when carrying out the first test session in the workshop. Most things that usually are important in DET are also important in the workshop, but remember that the goal of the workshop is to get buy-in for future testing in the same format.

Preparations for testing! Environments, focus areas, test data etc are needed, or-else the whole session will be filled with this which will give a less positive experience of testing.

The above needs preparation done by someone in the team, which needs coaching on everything that is needed. And to understand that it takes time.

Focus areas that are easy to test, preferably things that everyone involved is familiar with.

Areas where bugs can be found, since it is more fun to test if bugs are found. =)

Not over-do the reporting. Usually I have first-timers report with pen and paper on a easy-to-use template.

If time is limited, rather have more debrief time than squeeze too much testing time into the session.

]]>https://happytesting.wordpress.com/2013/06/19/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-2-intro-workshop/feed/3SiggeA new teams encounter with DET/TET as a framework for testing – Part 1-Contexthttps://happytesting.wordpress.com/2013/06/17/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-1-context/
https://happytesting.wordpress.com/2013/06/17/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-1-context/#commentsMon, 17 Jun 2013 14:27:30 +0000http://happytesting.wordpress.com/?p=777]]>Over the last year I have been asked many times about how to implement DET/TET at a new company. Since most of my experiences have been within Jayway where the concept is accepted, I have not been able to answer that question in a good way. This is my story of implementing DET in a company which had not been using it before or very much any other formal testing. Since i got the question, this company is not Atlassian, but my last assignment before my move.

In this first post I want to give some context about the assignment, the company and product and what we ended up doing. In the following posts I will highlight specific aspects that were relevant for this implementation in the new company.

Background

I was brought in as an Agile testing mentor to this company, which actually has no dedicated testers. There were a couple of reasons for bringing me in, examples include the workload of support people and embarrassing bugs found by customers. In short, you could say that they have grown out of their product in terms of overview and need for better ways of working than before. Since it shows as a quality drop, they figured they needed some better testing.

The company

It consists of three main groups of people; developers, support group and business consultants. Developers work on a big backlog of both new functionality and maintenance releases. This is run in a pretty good Agile fashion by the PO and development manager. The business consultants are the ones that best know the product domain, helping customers with configurations and business development using the product. The support group also includes operations, which helps installing new customer environments. They are actually the ones that mostly carry out tasks similar to testing when reproducing customer issues and solving them.

The company is distributed across two main locations, but with people working at all customer sites as well. This was an interesting challenge all along for me, although everyone were very used to this way of working. Main tools for collaboration included Skype, teamviewer and the whole Atlassian suite.

Most people were in very positive spirit towards what I was doing all the way from the start. They all appreciated the efforts and were very willing to invest themselves into the process. This helped me very much when introducing new ways of working.

The product

The product is an enterprise java based application that consists of plenty of modules, services and add-ons which has been developed for many years. This was a challenge in itself when testing because of the needs for test environments, data and preparations. Test isolation also became an issue when the whole team tested at the same time.

Two solutions

Like many projects I have seen, the reason for poor quality is as obvious as you might think; lack of testing and/or the acting on test results. To improve the situation, the solution is quite simple, simply put the testing up on the agenda in some form. As a start, we took on two different forms, targeting development team and business consultants respectively.

Development team had heard about DET and read the original articles. Meeting with a colleague of mine made them want to try it out, but they needed some guidance and focus to make it happen. Another thing to notice is that they had already tried to introduce the DET column in their greenhopper board, but did not have any formal way of working with it. Since I have mostly worked with it outside of the story scope, this is what we went with. And that is just as easy as it sounds. Some coaching on formalising time for everyone to test together.

The other thing that I did was to introduce scenario based testing to the business consultants. With some freedom to explore, they were introduced to a framework for specifying and executing scenarios mainly targeted at release testing. That might be a subject for later posts.

With these two things, I we achieved a company wide attention to quality and put testing up on the agenda integrated with day to day work.

More context?

]]>https://happytesting.wordpress.com/2013/06/17/a-new-teams-encounter-with-dettet-as-a-framework-for-testing-part-1-context/feed/3SiggeFirst week at Atlassianhttps://happytesting.wordpress.com/2013/06/03/first-week-at-atlassian/
https://happytesting.wordpress.com/2013/06/03/first-week-at-atlassian/#commentsMon, 03 Jun 2013 13:24:28 +0000http://happytesting.wordpress.com/?p=768]]>As usual, when the blog is not updated it is a sign that I have been up to many other things lately and the blog is one of the things I needed to cut down on. The reason for the downtime this spring is obvious, I have been busy packing my life in sweden into boxes for a move down-under to Sydney, Australia. Apart from packing, there have also been plenty of other related things to do before leaving the country. I was also featured in Computer Sweden for my move (in swedish). And finally I arrived, joining Atlassian last Monday.

I wanted to share some initial thoughts on this first week, but then I stumbled upon my current flat mate Benjamins blog post about his first week, written a week ago, and it actually resounds very well with my feelings at the moment. So take the time to read it here.

Apart from all the new stuff that just comes with being the newcomer as described by Benjamin, I also want to mention where I am in the company. I will be a part of two teams, the Fisheye/Crucible product team and the QA team. This setting might seem strange to some, but actually its quite similar to how Ive had it before. At Jayway Ive seen the benefits of having a strong specialist team to fall back on for competence development and strategic learning and discussions. And for those things to happen, there is a need for continuos communication and a feeling of belonging also in that team.

QA team – Quality Assistance team

First of all, I think it is important to state that at Atlassian QA explicitly stands for Quality Assistance, which is something that I really care for. And second, in my first week I have actually got the feeling that it is not only something stated, but also something lived up to. I will most probably be writing more about that later. The rest of the team is what Ive seen so far just awesome, and frankly I can feel the pressure of living up to these standards myself. It will be hard work, I can tell. They are also very helpful and all my questions are just taken so well, even those that get pushed back at myself to figure out =). The team already has bunch of things nicely packaged about how testing should/could be done within the company, but throughout the week I also realized that the evolvement on those things is done in an amazing pace. And I like that a lot.

FECRU team – Fisheye/Crucible

Fisheye and Crucible are two of the products that I have never used before. I also have a feeling that they might be the furthest away from the role of the tester in terms of me being a potential user of them in actual projects. But this is something that I am looking forward to exploring. Especially being tools for code review, I will need to learn and practice to actually do code reviews. At the moment I see this as a meta-bonus when it comes to my personal development as a tester, so I will probably also get back to that later on. Apart from the product, also these people have made a great first impression on me. And since most of my time will be spent with them, I hope I will meet their expectations at least later on. Even though my first weeks will be very much learning about all the new stuff, I actually got around doing some testing this week. And it did not only deliver stuff that I misinterpreted, but also gave input for some minor code changes. I am eager for what is happening further on.

ShipIt!

This first week I also got the chance to see the pure dedication of people throughout the company with the ShipIt event. I had an idea myself for something that I could have done, but with some initial investigations I realised that there were already similar things going on within the QA team, so I decided to put the idea on hold so that I can do some more investigations and instead make the next event. Also, I was of course deep into all the newcomer learning stuff this week that I had a hard time focusing enough to be able to develop it.

Sydney

Outside of work I have a huge city to explore, with all its special features and cherry picks. I haven’t had very much time yet to see much, but the things Ive seen so far have just been amazing. All I can say for now, is that I have a feeling that I will like this place. The company harbour view apartment doesn’t either do anything to change that in any negative way.

]]>https://happytesting.wordpress.com/2013/06/03/first-week-at-atlassian/feed/3SiggeIMG_3637ConTest – A local context driven testing communityhttps://happytesting.wordpress.com/2013/02/05/contest-a-local-context-driven-testing-community/
https://happytesting.wordpress.com/2013/02/05/contest-a-local-context-driven-testing-community/#commentsMon, 04 Feb 2013 23:05:40 +0000http://happytesting.wordpress.com/?p=756]]>The other day was the first event of the new local context-driven test community ConTest. It was initiated by Henrik Andersson and House of Test and hosted at FooCafe in Malmö. When I got to know about it, I knew I just had to go there of course. I also knew of a couple of people that would not be able to resist the opportunity. However, I was happily surprised with how many people actually showed up. A good 30 people experienced 2,5 hours of LAWST styl(ish) peer-conference setting with lightning talks followed by facilitated discussions.

The theme of the event was simply Context-driven testing and since it was the first event, Henrik prepared a couple of us to present lightning talks that could be targeted with discussions. And I think that was a wise move, so that the people that have not experienced peer conferences before could focus on good questioning. While not everyone asked questions, I think there was a fair amount of discussions anyway to fill up the time and I think we would have been able to fill a whole day with those topics.

I was honored with the first presentation, focusing on the basics “What is Context driven testing?”. With the short 10 minutes I got, I focused on the basic principles of context driven testing and gave a few examples of how they apply. I thought myself it was a good foundation of discussion that stretched for a good hour where the people that never heard about context-driven got opportunity to wrap their heads around it.

Maria Kedemo shared her thoughts on the context-driven community. She talked about her experiences with CAST and Lets Test, how those conferences really invited people to engage each other throughout the events that are not mainly around speaking but conferring. The interesting people that are there gives incredible experiences. Also, she brought up some of the different medias of how to engage with the community through blogs, twitter, linkedIn and Skype. My comment here is that coaching over Skype is a VERY rewarding experience. If you haven’t tried it, do it soon!

Robert Bergqvist talked about his experiences in a very large project and how he applied context-driven approaches on top of the already existing and non-existing testing practices at a large bank. Since they used a pass/fail approach to test cases, he gathered his own test results in OneNote including questions for clarification, unknown areas and risks from gut feeling. These notes he shared informally with stakeholders in the project and got very good responses.

Martin Nilsson talked about his approach to using exploratory testing as a learning activity in the beginning of a big project, and how the session notes from that session became valuable as a learning resource throughout the rest of the project.

Some quotes I captured throughout the event:

In my context, If its not passed, its failed and will be handled/managed

Different contexts have different meaning in regards to test results. This was a comment on Roberts regression test results where a Failed test is really bad.

I captured the stuff that was between pass and fail

Robert about what he was doing in the project apart from doing his job.

It is never hard to find the risks

Siren Hofvanders (Securitypony) comment on a question regarding different test approaches and how also security testing can be done exploratory style.

Do the testing first and then plan for these extra things

About priorities when mixing scripted with exploratory testing

Future

I must say that everyone there got more excited and up to speed during the two latter discussions, since they were more concrete experiences. With that in mind, I also have good hopes for the coming ConTest events where I don’t think it will be any problems with filling up with experience reports to discuss.

For my own sake, I need to gather ConTest people somewhere, so I created this twitter list, Contest-Foo. As I have never used lists on twitter before I am still not sure what the point is, but I figured it might suffice trying it. So if you were at ConTest in Malmö with me and you are on twitter, give me a shout, I want you here.

As a final note, the proposed hashtag for this group was #ConTest. Whoever has been on twitter knows that hastags are used for multiple purposes, which is why #contest just gives us opportunities to win things. But stay tuned for #foocontest.

]]>https://happytesting.wordpress.com/2013/02/05/contest-a-local-context-driven-testing-community/feed/5SiggeAgile Testing – Unicorn perspectivehttps://happytesting.wordpress.com/2013/02/01/agile-testing-unicorn-perspective/
https://happytesting.wordpress.com/2013/02/01/agile-testing-unicorn-perspective/#respondThu, 31 Jan 2013 23:12:40 +0000http://happytesting.wordpress.com/?p=733]]>So for anyone not attending Agile testing days 2012, unicorns actually became the theme of a great conference through the collaborative work of peers. It refers to the differences and similarities between /the real world/™ and the unicorn world.

If you haven’t read the previous posts in this series, please do. Also do keep in mind they refer to extremes of perspectives.

About the extremes

My friend and Scout colleague shared with me this great analogy when it comes to discussions about things that people care a lot about. At that time a couple of us were talking about the whole global warming controversy, but it applies to many similar debates, like the one about Agile testing. “How come it is so hard for people to discuss these matters without ending up in a ditch and not getting up?” The essence of this being that if you are of a certain belief in a debate that you care very much about, it is very hard to hold the debate on track (or on the road) with factual reasoning in both directions. While in the ditch, the reasoning will just stay the same and nothing in the discussion will move forward after that.

The real world (unicorn world), the recent experience reports

All of the communities that I have written about have people in them that always end up in the ditch. Unfortunately, those are the real believers and caretakers of the communities as well. So as much as they bring the deeper thoughts of communities forward, I think it is important to know and take a distance when something else needs to be considered, like getting your job done in a good way.

With all these perspectives and models of the world, the most accurate stories I believe are most often told by people that are actually working on software projects. Not five years ago, but NOW and within the last year or two. Like Elisabeth Hendrickson points out in her tweet, shelf life on skills within software development has shrunk rapidly compared to 10 years ago. This means that if you are teaching (or preaching for that matter) anything within software development, doing actual project work is essential to keep up with what your peers already know when challenging your ideas.

The practitioners need to tell their stories, and share the conclusions they have made in retrospect. And people have to listen to them and understand these gifts of knowledge. But beware, we actually have that context thing, where every single person has different experiences of what works and not works in THEIR projects at THAT time with THOSE people involved. And the knowledge sharing does not just happen when you share your experience, but when the right person in the room actually takes those experiences and applies the parts that work into their own project.

Thoughts

That is where I think we need to dig to find out what Agile testing really is in practice and what is hidden behind the words. Apart from already established “Agile testing practices”, I think there are still loads of things that remain to be shared in the continuum of Agile testing.

I have been thinking a lot about this, to figure out where I want to take it. This series turned out to be quite a journey for me, since now I got a much bigger audience than when I have talked to people about this face to face during the last year or so. All the feedback I got on the posts is rewarding in so many ways, and I hope I did not step too hard on anyone’s toes.

The single most rewarding discussion around the topic must have been during PotsLightning before Agile Testing Days. The reason for that? We stayed on track without ending up in the ditch for the whole day! Instead we ended up with a nice list of attributes that great Agile testers /might/ need. Thanks to Maik Nogens, Meike Mertsch, Lisa Crispin, Huib Schoots, Markus Gartner, Jean-Paul Varwijk, Matthew Heusser, Stephanos Livieratos.

What is Agile testing?

These are my takes on some kind of definition for Agile testing:

Agile testing is when a context dependent skill set of a team is utilized to carry out testing activities in collaboration with the basis in an agile mindset.

As an Agile tester I have an agile mindset and I am able to apply my personal skill set according to the product and project context needs. If the skills are lacking, I make sure to either learn appropriate skills or cover the needs with something else appropriate for the situation from my own or the teams collective toolbox.

I would like to say that these possible definitions relate very much to context driven testing, but in a sense that the whole team collaborates on all quality work.

So for the skills needed to carry out great Agile testing? Are there any skills like that which are NOT dependent on context? I might give that a take in a later post, however I consider the “must be able to code” skill a very much context dependent skill.

]]>https://happytesting.wordpress.com/2013/02/01/agile-testing-unicorn-perspective/feed/0Siggehttp://weknowmemes.com/wp-content/uploads/2013/01/unicorns-are-real.jpgAgile Testing – Context driven testing perspectivehttps://happytesting.wordpress.com/2013/01/15/agile-testing-context-driven-testing-perspective/
https://happytesting.wordpress.com/2013/01/15/agile-testing-context-driven-testing-perspective/#commentsTue, 15 Jan 2013 21:58:14 +0000http://happytesting.wordpress.com/?p=729]]>The context driven school of testing is a good representation of my personal normal state of mind when it comes to my profession. I really like to hang out with like-minded people that are outspoken about belonging to this community of testers. I also recognize many of the people within this community to be interested in and are practicing good Agile testing. When I started to write this post I also realized I gave it a shot 3 years ago, when I still hadn’t wrapped my head around context-driven. But although my knowledge and experience has changed a lot during that time I still think the post is valid in some sense.

Context driven testers

Similar to the Agile movement, the context-driven school has a set of principles (http://context-driven-testing.com/), followed by explanations to them for clarification. Even this concept might give a never ending loop when it comes to the “there is no best practice principle”, when it is written in the definition which could be seen as the best practice of context driven (topic for another time). What the principles point out is the fact that for context-driven testers nothing is EVER written in stone, but can always be questioned to reveal more information. A good tester should ask as many questions as possible to reveal not only parts of the context but enough of it to be able to act on the information. It is also an outspoken goal to do the best possible testing with the context given and be able to be proud of that work. These things actually overlap some with the software craftsmanship movement (also another topic).

Although testing and software quality is the main interest of the community, many of the context driven testers are also highly interested in other areas like systems thinking, epistemology, philosophy and the like. And surprise, these topics also have their own specializedcommunities.

It is very important for context driven people that quality decisions are made by “management” or “product owners”. The decision is at least never on the lone testers table. “I can tell you whats wrong, but now its hands off for me, since I am not being responsible at all for the reactions of the information in my test results.” This is one of many examples how even though people are criticizing the throwing-software-over-the-wall approach, context driven community still talks about and practices testing as though it is a sport of its own within software development projects.

Agile testing?

There are plenty of things from context driven that relate to how good Agile works. The example I had in my previous post, where my colleague was asked to name the “explore > learn > adapt and then explore again” and he called it Agile, while I was in fact describing exploratory testing shows that to some extent. There is no standard answer to any question in this community, but I am quite sure that Exploratory testing is a good starting point when context driven testers are asked about what Agile testing is.

When it comes to test automation, its really just testing when created, and then its called checking. This is something that I know very many people outside of the context-driven community is having a hard time understanding or grasping. And when I have explained it to developers for example, they don’t really see the point in me trying to rename something they have been calling tests for many years. I know the value of having a good check suite that might fail on a commit, this means I can draw the conclusions myself that the newest software is not worthy my testing yet. There is good value in that, although are called unit tests by my developers.

A couple of years ago tried to explain the value of Specification by example/BDD/ATDD to some of the most prominent people within the context driven community, and I must say that these supportive ways of discovering gaps in communication before code is written did not really seem interesting at all. This is an example of proactive testing activity that I think is very important for successful Agile projects. However this and other pro-active test activities do not seem to appeal to the most extreme context driven people.

Context driven testing is a very tester/testing centric view of software development. As much as the context driven school has developed the craft of testing it still has the “reacting-after-the-fact” mentality. Doing “the best we can with what we get” (cited context-driven-testing.com) is a mentality I can’t do in projects. If something is wrong with how the project is run, I will make a change happen. It is everyone’s job to improve the situation of the project. A big part of this is test activities that support the whole team to being able to create better software in the first place.

Thoughts

If

Exploratory testing is the first and only thing that comes into mind when asked about Agile testing

You think quality decisions must /never ever/ be the testers responsibility

You do not acknowledge quality to be a responsibility of the whole team

No test results are ever good enough if they only consist of red/green or pass/fail information

Your view of testing is highly based on re-active activities and thinking

Is it possible to perform good Agile testing? Will you be a support or a burden to any Agile team you are on?

]]>https://happytesting.wordpress.com/2013/01/15/agile-testing-context-driven-testing-perspective/feed/20SiggeAgile Testing – Project management perspectivehttps://happytesting.wordpress.com/2013/01/03/agile-testing-project-management-perspective/
https://happytesting.wordpress.com/2013/01/03/agile-testing-project-management-perspective/#commentsThu, 03 Jan 2013 00:19:24 +0000http://happytesting.wordpress.com/?p=623]]>Project managers are very different from programmers. But then again, there are also many similarities when it comes to their relationship to testing. In this post I will mention the PMI community as well as facilitation communities Innovation Games and Gamestorming. The biggest reasons for my learning within these communities relates to leadership.

Project managers and facilitators

Like the programmers, also project managers as a community is very diverse. Even worse, their craft extends beyond software development to all other businesses. Realizing this was a huge stepping stone for me when I started to attend PMI seminars and discussing projects and project experiences with the people there.

The same goes for discussions with my father with the background of a Civil Engineer that has done quite a lot of managing construction projects and worked with quality in the same areas. Discussions are usually interesting and fruitful up to the point where we agree to disagree about fundamentals. For example in a software project it is very much possible to change your mind regarding architecture or change the type of database used in the middle of a project. But for a construction, it is not so easy to rebuild the foundation after you have added two stories to the building.

So for the PMI community where the syllabus bible is the PMBOK, I always make sure to mention that I work on software projects. That also scares people away if they know they dont understand software. Unfortunately though, it also attracts way too many people that work with software projects but still don’t know about the fundamentals. It scares me.

Another flavour of project managers are the Agile ones, that I mentioned in a previous post. Many of them are really more of project facilitators working with Innovation games and Gamestorming as their preferred tools. I really like to how they leverage the gaming mindset with humans in situations that otherwise can be about taking tough decisions. The gamers that I have been in contact with in software mostly have technical background.

Agile testing?

The traditional project managers have just recently adopted Agile. Agile as a topic is new for this years PMI Global congress and their Agile additions to the PMBOK were added just a year or two ago, its that new. Now for the project managers involved in software development, they have had to put up with Agile for a while now. Some have succeeded while some just think they succeeded, while listening to their stories its obvious they didn’t understand yet.

Talking to them about Agile testing, you might as well just explain to them what testing is really about. Its not until you work with them that you can really get them to understand what the value of it is. There is also big challenges in trying to explain the new thing about Agile with things related to quality, since the quality bits and pieces within PMBOK does not really fit into the Agile model.

The facilitators as I said earlier stem to the more Agile crowd. The generalizations I made about the Agile wave suits this group very well. An area however that these people excel, is the underlying curiosity of de-mystifying the people parts of things. I myself like the approaches and use them myself when it comes to testing. But as I have explained my approaches to people in this crowd, there is scepticism about the needs for which I am using /their/ games. The thing I have seen is that these facilitators greatly work with a proactive mindset, clouding their judgement when it comes to reactive activities like testing.

Thoughts

If

Agile is not really in your vocabulary

You think project management is a craft that can be applied to software without knowing about software

Your most common focus is about being proactive

Then you don’t really care about anything called Agile testing! You might not even care about neither Agile nor testing =)