SOGETI UK BLOG

Testing-Automation

This blog was originally published on 26th Janurary 2015

Test automation is often perceived as  ‘expensive’, ‘costly’ or ‘difficult’… but it shouldn’t be. There is a lot of automation software that is easy to learn, cheap or even free to use.

Nowadays, organizations are working more and more Agile, often through Scrum – which means that the rate of deployments are going up and so is the frequency of Regression Testing. In the first two or three sprints, it’s rather easy to keep up with the delivery rate of new features. This is because the product is still relatively small, and there isn’t much requirement for Regression Testing.

However, after the third or fourth sprint, the product takes more shape. By this time, the features become more mature, comprehensive and elaborate, thereby demanding extensive period of Regression Testing.

The Regression set gets bigger and bigger and the time spent on Regression Testing increases almost exponentially, resulting in a longer waiting period on the feature to be completed; thus, increasing the time-to-market. This could be solved by automating the (regression) tests. In my opinion, this is the obvious choice… but it isn’t for all businesses! Often times, companies spend prolonged period rationalizing the pros and cons of Test Automation. So, my suggestion would be… just do it instead of  speculating too much!

Start doing !

As stated above, this is something I hear way too much. Using of tools are  ‘expensive’, ‘costly’ or ‘difficult’.  I think differently, there are many tools that are easy to use , cheap or even free to use.

For example Selenium is a free-to-use tool, which one can download as an add-on for Firefox. It’s a very easy record and playback tool for websites and one can start using it within minutes. So, apply, engage and implement. When working on a product that involves websites, the testers should download Selenium or another similar free tools the moment they start on a sprint. Why? It’s because the team starts learning right away.

There are other free or cheap tools, each meant to achieve its specific goal:

For example

Type Name
Unit test JUnitMockitoEasymock
Performance JMeterLoadUI
User interface / Web Selenium IDEFirebug,Firepath
Security ZAPWebscarabBurp Suite
Services SoapUICURL

 

There are tools that one can use for functions other than Testing. Following is a list of some that I know:

Type Name
ALM TracJiraBugzilla
SCM SVN
Build tools MavenANTGradle
Continous integration HudsonJenkinsBamboo
Analyses SonarCubeFindbugs
Deployment HudsonJenkinsLiquiBase

Usually, the tool(s) used by teams differ and I feel, they should have the freedom of selection.

Learn

In my Testing career, I found that the “old school” testers are habituated to Manual Testing and have challenge embracing Automation. So, if the learning curve starts with Automation, it will get too difficult for such Testers and they might lose interest and be inclined to go back to their comfort zone i.e. Manual Testing.

Therefore, start with tools that are cheap and easy to use. Due to the low costs, the team will be able to switch between tools more easily and they won’t need programming skills or even a training to start working on it. Give the team room to explore, fail, experiment and learn, so they can make a better choice of tools that are really beneficial. Thus, making Automation more cost-efficient. This is a long term thinking game.

“Don’t make the mistake to start with an expensive suite of tools. You probably don’t even need all its features, but you surely will pay for it.”

Share & Grow

When using tools and test execution gets automated, people get the hang of it. They will have a better understanding of Automation and will create new ways to improve existing test cases or even see new opportunities for the use of better or other test tools. Make use of this. Let teams and people share their knowledge with others. If they like their tools, they’ll probably want to talk about it, tell other people and teams how good their tools work. Support this and let them share their knowledge, encouraging peer-to-peer learning.

So, start small and simple, apply, engage, learn and share. Don’t try to build Rome in a day!

 

Jos Punter AUTHOR:
Jos Punter is an Agile Tests expert who is enthusiastic and doesn’t like status quo. Always looking for a way to improve, looking for a better or an other way, innovate, change, adapt and get better. Jos loves new technology and gadgets which supports him in achieving his goals.

Posted in: Automation Testing, Big data, Digital strategy, Human Interaction Testing, Infrastructure, Innovation, IT strategy, Research, Scrum, Test environment      
Comments: 0
Tags: , , , , , ,

 

T-shape-Mainimage

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Want to work in an agile team like Scrum, Kanban or DevOps? Become a T-shaped professional.  Great chance that you will hear that. But what is a T-shaped professional ? How can you become one?

Well a T-shaped professional is a person who is specialized in something like testing, programming design, analysis or whatever specialization they like. But they don’t have tunnel-vision as they have an attitude to look further than their own specialization and like to broaden their knowledge. Furthermore, they like to share their own knowledge with others. To know more in-depth analysis about what a T-shaped professional is, click here.

But how can you become one for free? Well, first and foremost it’s all about you broadening your knowledge by always looking for help.

This article will help you become more of a T-shaped professional. Below are some insightful posts I found on imgur. These posts inspired me and I hope they will inspire you too.

 

Credits: http://imgur.com/gallery/UnyAh
Credits: http://imgur.com/gallery/BL6Vs
Credits: http://imgur.com/gallery/Zw0OJ


Free Books

Here’s a  list of free books. Both links bring you to a repository github.
Books link 1

Books link 2

Online schools

Here’s a list of online schools that teach wide variation of scripting and programming languages.

tshape-1 tshape-2
tshape-3 tshape-5
tshape-6 tshape7


Tutorials and other useful links:

Click logo for tutorial Other useful links
tshape_1  

 

http://www.cplusplus.cohttp://www.learncpp.com

http://xoax.net/cpp/crs/console/index.php

http://www.tutorialspoint.com/cplusplus

tshape_2jpg
tshape_3jpg  

https://www.youtube.com/course?list=ECFE2CE09D83EE3E28

http://www.learnjavaonline.org

tshape-5jpg
tshape-6jpg
tshape_7Part 1: Open in Youtube 

 

Part 2: Open in Youtube

 

Part 3: Open in Youtube

 

 

 

 

 

 

 

http://www.codecademy.com/en/tracks/javascript

http://www.yuiblog.com/crockford

https://developer.mozilla.org/en-US/Learn/Getting_started_with_the_web/JavaScript_basics

http://superherojs.com

http://www.codecademy.com/en/tracks/web

tshape_8jpg 

 

http://www.phptherightway.com 

http://www.codecademy.com/en/tracks/php

 

 

tshape_9jpg

 

https://www.python.org

https://developers.google.com/edu/python

http://www.learnpython.org

 

 

 

tshape_9

tshape_10jpgLisp 

 

 

tshape_11

Swift

 

 

tshape_12

 

Learn how to test, software made by all of the above programming and scripting languages.

 

Use their free templates.:

http://www.tmap.net/downloads

 

Available in Dutch,English and German

As you can see the list is not complete. Leave a comment if you want to add more useful links, videos, wikis, etc.

 

Jos Punter AUTHOR:
Jos Punter is an Agile Tests expert who is enthusiastic and doesn’t like status quo. Always looking for a way to improve, looking for a better or an other way, innovate, change, adapt and get better. Jos loves new technology and gadgets which supports him in achieving his goals.

Posted in: communication, DevOps, Digital strategy, Human Interaction Testing, Internet of Things, IT strategy, Microsoft, Open Innovation, Research, Scrum, Security, Social Aspects, Testing and innovation, TMap, Transformation, User Experience, User Interface      
Comments: 0
Tags: , , , , , , , , , , , , , , ,

 

Testing-AutomationTest automation is often perceived as  ‘expensive’, ‘costly’ or ‘difficult’… but it shouldn’t be. There is a lot of automation software that is easy to learn, cheap or even free to use.

Nowadays, organisations are working more and more Agile, often through Scrum – which means that the rate of deployments are going up and so is the frequency of Regression Testing. In the first two or three sprints, it’s rather easy to keep up with the delivery rate of new features. This is because the product is still relatively small, and there isn’t much requirement for Regression Testing.

However, after the third or fourth sprint, the product takes more shape. By this time, the features become more mature, comprehensive and elaborate, thereby demanding extensive period of Regression Testing.

The Regression set gets bigger and bigger and the time spent on Regression Testing increases almost exponentially, resulting in a longer waiting period on the feature to be completed; thus, increasing the time-to-market. This could be solved by automating the (regression) tests. In my opinion, this is the obvious choice… but it isn’t for all businesses! Often times, companies spend prolonged period rationalising the pros and cons of Test Automation. So, my suggestion would be… just do it instead of  speculating too much!

Start doing !

As stated above, this is something I hear way too much. Using of tools are  ‘expensive’, ‘costly’ or ‘difficult’.  I think differently, there are many tools that are easy to use , cheap or even free to use.

For example Selenium is a free-to-use tool, which one can download as an add-on for Firefox. It’s a very easy record and playback tool for websites and one can start using it within minutes. So, apply, engage and implement. When working on a product that involves websites, the testers should download Selenium or another similar free tools the moment they start on a sprint. Why? It’s because the team starts learning right away.

There are other free or cheap tools, each meant to achieve its specific goal:

For example

Type Name
Unit test JUnitMockitoEasymock
Performance JMeterLoadUI
User interface / Web Selenium IDEFirebug,Firepath
Security ZAPWebscarabBurp Suite
Services SoapUICURL

 

There are tools that one can use for functions other than Testing. Following is a list of some that I know:

Type Name
ALM TracJiraBugzilla
SCM SVN
Build tools MavenANTGradle
Continous integration HudsonJenkinsBamboo
Analyses SonarCubeFindbugs
Deployment HudsonJenkinsLiquiBase

Usually, the tool(s) used by teams differ and I feel, they should have the freedom of selection.

Learn

In my Testing career, I found that the “old school” testers are habituated to Manual Testing and have challenge embracing Automation. So, if the learning curve starts with Automation, it will get too difficult for such Testers and they might lose interest and be inclined to go back to their comfort zone i.e. Manual Testing.

Therefore, start with tools that are cheap and easy to use. Due to the low costs, the team will be able to switch between tools more easily and they won’t need programming skills or even a training to start working on it. Give the team room to explore, fail, experiment and learn, so they can make a better choice of tools that are really beneficial. Thus, making Automation more cost-efficient. This is a long term thinking game.

“Don’t make the mistake to start with an expensive suite of tools. You probably don’t even need all its features, but you surely will pay for it.”

Share & Grow

When using tools and test execution gets automated, people get the hang of it. They will have a better understanding of Automation and will create new ways to improve existing test cases or even see new opportunities for the use of better or other test tools. Make use of this. Let teams and people share their knowledge with others. If they like their tools, they’ll probably want to talk about it, tell other people and teams how good their tools work. Support this and let them share their knowledge, encouraging peer-to-peer learning.

So, start small and simple, apply, engage, learn and share. Don’t try to build Rome in a day!

To read the original post and add comments, please visit the SogetiLabs blog: Test automation – Don’t try to build Rome in a day

Related Posts:

  1. Test levels? Test types? Test Varieties!
  2. Use Scrum and halve the test department!
  3. Six corner stones of a Test Center of Excellence
  4. Is it a good idea solving test environment problems “later”?

 

 

Jos Punter AUTHOR:
Jos Punter is an Agile Tests expert who is enthusiastic and doesn’t like status quo. Always looking for a way to improve, looking for a better or an other way, innovate, change, adapt and get better. Jos loves new technology and gadgets which supports him in achieving his goals.

Posted in: Automation Testing, Business Intelligence, Opinion, Scrum      
Comments: 0
Tags: , , , , ,

 

Jos1

Imagine a project manager in a large organization. Let’s call him Charlie. He’s good at what he does. He likes to be in charge and have control over projects. He knows how the work should be done, when the work should be done and what kind of work should be done within a given time frame. All and all, he is responsible for the outcome so he better be on top of everything.  He steers the project by controlling the scope, cost and time and ensuring the quality level, also known as the devil’s triangle.Generally his tasks have to do with:

– Budget stuff
– Inventorying stuff
– Resource stuff
– Planning stuff
– Delegate stuff
– Stakeholder management
– Monitor stuff

Jos2

Then one day the company read some research on Agile (State of Agile) which concluded that similar companies use a form of Agile about 88% of the time. This made Charlie’s company curious. Management wondered: “what’s so good about this agile way?” The research survey answered this question with a top 3 of reasons:

1. Ability to manage changing priorities
2. Increase productivity
3. Project visibility

This all sounds pretty nice but what is Agile exactly? Charlie wonders. So he googled around and found the website Agilemanifesto.org where he found these 4 values:

– Individuals and interactions over Processes and tools
– Working software over Comprehensive documentation
– Customer collaboration over Contract negotiation
– Responding to change over Following a plan

Clearly stating: “That is, while there is value in the items on the right, we value the items on the left more.”

Charlie finds this a little peculiar; this is not how he was used to working in past projects. Most of the time it was done the other way round and how on earth can these 4 values and 12 principals be used in projects?(http://agilemanifesto.org/principles.html). There must be methods or frameworks out there to put this mind-set in to work?

So he read the research of the state of agile a bit more. And he stumbled upon some statistics.

Jos3

Charlie told his company that if they wanted to work Agile, then scrum or a hybrid version of scrum would probably be a good way to start. The research showed that a lot of of companies (73%) working in an Agile way use Scrum or a similar method.

Charlie again searched the internet for Scrum and found a lot of information. Yet he was surprised, where did his project manager role go?

Jos4Clearly this must be a mistake; a project can’t run well or succeed when the project manager can’t perform his duty or tasks. Who else will be in charge and who will control the what, the how and the when?

“It seems these all were divided over the 3 roles, Charlie”, said a member of his company. “Look” and he started to write this down on a whiteboard.  “This is how it was”

Jos5

As a project manager, you are in charge of the project team members and need to be in control since you are responsible for what has been done, how it’s been done and if it’s all been done in time. He added a new drawing – “And this is how it’s going to be”.

Jos6

1. The product owner – Controls the what and the when
2. The scrum master – He doesn’t take control but he rather coaches and facilitates the team  so the team can focus on getting things done.
3. The developer(s) – Decide the how, heck they are the ones who have to build it and they know how to build it. So why not let them be in charge of how to build it.

Charlie nodded -Ok- and said “but my tasks, my tasks, they are still my tasks, they surely are needed, right?” “Let’s have a look at your tasks then” the co-worker replied. And he started to summarize.

“Your tasks involve budget,inventorying, resourcing, planning and delegating; monitor this so you can answer to the stakeholders if everything is going according to plan.  If it’s not going to plan, communicate that. Discuss with the project team the work you delegated to them and set things straight.

Project managers tasks mapped on the scrum framework

Jos7

How does this process work? First there is a vision of something to create. Within the company there are stakeholders with all kinds of needs, dreams and want to haves for this new idea. It’s pretty hard to manage all these things so Scrum came up with a product backlog (PBL). This is a log with all the stuff the stakeholders come up with to put on there. Yet a log with all these “needs” is still hard; to work with, so they created a product owner (PO), one of the 3 roles that exist in Scrum. He is responsible for the product backlog and he has to communicate and fine tune with the stakeholders what will be on it. Most of the time by ROI

So tasks that normally would be done by the project manager are performed here:

– Stakeholder management
– Inventorying (PBL)
– Plan (PBL)
– Budget  (PBL)

Now that the PBL contains a list of wishes, sorted by which wish has the greatest value to the company, it shows which item(s) to build first. Now a PO doesn’t develop himself; he has a team of developers (or: development team) to build the code. The developers take the most important items of the PBL first and put these on the sprint backlog (SBL) so they can realize them in a sprint. The amount of work they manage to do each sprint is decided by the development team, not the PO and not the Scrum Master (SM). The DT delivers a shippable product increment every sprint, which they present/demo to the PO and the stakeholders. The work done can be monitored in several ways: via the scrum board, daily stand-up, the sprint burn down chart or the demo. This means that other parts of the project manager’s tasks are performed as well:

– Stakeholder management
– Inventorying (SBL)
– Plan (SBL)
– Monitor  (SBL)
– Delegate

Jos8To complete the scrum team, it needs a scrum master. A SM coaches the team and the organisation in the ways of scrum and keeps the team shielded from outside distractions. He facilitates the team so the team can focus. The entire scrum team is responsible for the outcome and output of the product development. This is why they use the triple constraint a bit different. Quality, time and cost are fixed,but scope is the variable factor in scrum.

So as you can see, there isn’t much left for a project manager to do. All his responsibilities and tasks are already performed by the scrum team. So what can Charlie still do?

– Could he become a scrum master?
– Could he become a product owner?
– Could he become part of the Human resources organization?
– Could he help the organisation work with scrum?
– Should he keep on working on traditional projects?
– Should he change his way of working?
– Should he give up and quit his job?

What could, should or must he do? Leave your opinion in the comments and let’s discuss. I’m very curious

Sources:

Source: State of Agile, 8th annual survey 2013

The scrum framework: https://www.scrum.org/Scrum-Guide

Jos Punter AUTHOR:
Jos Punter is an Agile Tests expert who is enthusiastic and doesn’t like status quo. Always looking for a way to improve, looking for a better or an other way, innovate, change, adapt and get better. Jos loves new technology and gadgets which supports him in achieving his goals.

Posted in: Agile, project management, Scrum, Software Development, SogetiLabs      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , , , , , , , , ,

 

Scrum-master-tatoo1. ScrumMaster role without an Agile mindset.

The role of a scrummaster is a very important one. Then why is it that this role is still given to people without an Agile mindset and/or experience?  The project manager often gets picked for this role. This choice is in itself an obvious one for organisations that are still transforming from a more traditional way of working. The role of a scrummaster is a managing one, so a project manager is the obvious choice, no ? Wrong! Project managers want to control how the work is done, when the work is done, and what kind of work is done within a certain timeframe. You can’t blame them; over the years he is held accountable for the outcome of the project and, therefore, he wants to manage the team. Now in scrum the whole team is responsible for the outcomes and is self-managing.

So don’t randomly pick a Scrummaster; if possible let the team be a part of the selection procedure. Don’t  go for the obvious project manager pick. Make sure that the person is a servant leader who knows what Agile and Scrum means. As a result he can coach and teach others the way of scrum within and outside the team.  If you can’t find any, send people who fit in the description and have an Agile mindset, to a Scrummaster training. I did this as well; it really gives you new insights and, besides that, is fun to attend to.

2. Scope is Fixed.

Wrong! Scope is not fixed. What a lot of people forget is that the big difference between scrum  and traditional ways of working is the way they approach the devil‘s triangle. In scrum the scope can change. Traditionally, scope is seen as fixed. The time, cost and quality are accustomed to change. So make the team aware that Scope is flexible whereas time, costs and quality aren’t.

3. Product owners can’t make decisions alone

“Hi, I am the product owner.  I got great ideas on how to improve this application and have innovative new ideas that really add value, yet I have to constantly ask my superior or his manager if they have time to check that they feel the same way” is not what you want to hear as a Scrumteam.  The risk is that the PO will become the bottleneck for the team.  This will result in a team that will lag behind in creating new value for your organisation just because of the fact they have to wait way too long for any decisions to be made.

Make sure that people outside the team don’t make the decisions for the team. In Scrum they aren’t responsible for what is being delivered, the team is. The product owner is part of that, and he should be given the needed mandate and the responsibility he deserves.

4.  Team isn’t a team
Then why do I stumble upon dedicated teams within Scrumteams? One for the documentation, one for coding, and one for testing. And they work like this 1st Sprint is about creating the functional documentation, 2nd Sprint is about realizing the documented functionality, and the 3rd Sprint is about testing the documented functionality. Or they put the 3 phases in 1 sprint. By this, testing will be done less adequately because of the time shortage you will create. And does this sound familiar ? It should because it’s waterfall put in the Scrumframework.

Teams should be multidisciplinary teams and work as one. Scrum is about teamwork, collaboration,transparency,keeping it simple, etc. So, don’t create teams within the Scrumteam.

5. Scrum team is too large
The bigger the team the better, right? You can work on more stuff to be done and in less time. Wrong! If a team gets bigger then 9 people it’s harder to communicate, collaborate, and the team loses its dynamics and this will result in less kaizen moments.

So that’s why you need competent team players who like working in multidisciplinary teams  and don’t mind working simultaneously on new functionality. The size of the teams should be around 7 plus or minus 2.

Overall:

Try to follow the simple rules scrum describes (https://www.scrum.org/Scrum-Guide), there aren’t many. Keep aligned with the agile-manifesto. Make sure you have an experienced Scrummaster who knows how scrum works and spots the signs of “waterscrum”. Get a Product Owner that can handle the responsibility and has a mandate so he can make decisions. Create a multidisciplinary team.

Jos Punter AUTHOR:
Jos Punter is an Agile Tests expert who is enthusiastic and doesn’t like status quo. Always looking for a way to improve, looking for a better or an other way, innovate, change, adapt and get better. Jos loves new technology and gadgets which supports him in achieving his goals.

Posted in: Agile, Collaboration, project management, Scrum, SogetiLabs, waterfall      
Comments: 0
Tags: , , , , , , , , , , , ,