Attracting Girls To Engineering

Statement “girls are not interested into engineering” is wrong.

Take me as an example. I had loving parents, but they had strong opinion what kind of toys are meant for girls. I beg them, but still never got a car or train to play with. Never understood why I cannot wear pretty dresses AND play with the trains?

Later at school we had craftsmanship lessons. Girls did cooking, knitting, crochet, weaving, boys could build something from wood and they took plumbing lessons. One thing I was interested in, but never were allowed to try. Because I was a girl.

At university one of my professors once told me: no way you wrote this code yourself!

It was so frustrating… I did not get chances to show what I am capable of OR every time I delivered something, my work got questioned just because I have no penis!

Based on my experience here are seven simple suggestions how you can attract girls to engineering:

  1. give chances to girls to try
  2. do not question results what they deliver. no comments that they could do better. they will do better after some time of practice
  3. invite not just one girl, but all her girlfriends. it is safer to fail, if your friends are around you
  4. find a role model. tell stories about women, who was the very first programmer, did very first debugging, wrote code to fly to the moon etc.
  5. listen when a girl talks
  6. make no suggestions if she does not ask for those. let her figure it out for herself
  7. if you see somebody doing opposite what I wrote in 1-6, call him/her out, tell that it is wrong. tell to the girl, that it is wrong

Gmail And Dots

This week I was on the phone with my insurer. It was Saturday and I had to say my name, my address, my birthday and my bank account to identify me as me. I asked insurer in future to contact me via e-mail because during workday I mostly cannot answer the phone, because I work as a trainer with full class of students.

  • she: please spell your email address
  • me: kristine dot <rest of my gmail address>
  • she: your phone number
  • me: we are on the phone right now, you know my phone number
  • she: sorry, I have to register this kind of information. this is for Saturday calls only.
  • me: ….. +49 <numbers>
  • she: do you have a dot in your email address? is there any capitals?
  • me: (i spelled it and you did not listen) it is gmail address, it does not matter. And email addresses are not case sensitive.
  • she: no, you are wrong, it matters!

I almost forgot about this conversation, but today got reminded by Netflix scam story. I wrote a year ago how handy it is that Gmail finally decided to ignore the dot and sell it as a feature. I was thinking as a tester, not as a user. But James is right, Google never informed me that I have infinite set of email addresses. If users does not know, and services, who collect my email address does not know it, then we are back to: it’s a bug not a feature! again.

As a tester I will keep using Gmail dot ignorance feature, but as a user I will pay more attention and write a mental note to myself about possible misuse.

 

 

Today I Learned

Last September I joined trending and became one of the ISTQB trainers. I have a whole story “why?” and I plan to share it one day, but today I want to talk a bit about learning.

How I see learning from the trainer side is pretty ugly – mostly students do not want to learn. It is trendy to talk about learning and training should be safe place where to learn, but in many cases ISTQB is something where they have been sent by a boss or something, what they think they have to do, to get a next shiny job title. I try hard to make trainings entertaining (I carry different testing games with me) and informative (learning materials, stories from the past), but sometimes it is simply not working. Sometimes I am happy that at the end of the day everyone simply memorised what negative test is and why we should do it. Most challenging are the ones who refuse to understand some definitions or concepts, for example, difference between validation and verification. Most frustrating if this is a person who has 20 years of experience in IT. In those moments I ask myself, is this really for me? But then I remember my “why?” and everything is OK again. Part of that “why?” are students, who are engaged and eager to learn everything I can share with them. They did some research upfront and have clear vision what they need. It is highly rewarding to work with that kind of students. Discendo discimus – while teaching we learn.

In trainings I invite people to embrace failures, to share experiences, to learn from each other, to use synergy. To help them to do that, I point to my own mistakes. Something like the picture on the top of this post. Few month ago I put whiteboard into our home kitchen. We use it as drawing board, as shopping list, as design board for next game we will program and sometimes I write citations. I guess, now till end of my days, I will spell “intelligence” correctly. Not always I was so cool about my mistakes. Few years ago I would feel ashamed and embarrassed, would try to hide it, put a lot of energy to deny it. Today I share it with the world. I know who I am and spelling mistake will not make me less me. I better put my energy to think why did I spell it wrong? Am I writing too less on an analog information carriers? Do I assume that software will catch all my spelling mistakes?

Since this month we have new colleague Dani. One thing what he did, he created channel in our company slack #todayilearned to share our learnings. It has became simple but effective training for me to identify what did I learn new today. Sometimes it is simple stuff, like, how to spell “intelligence” or that I am afraid to sit in the car which moves faster than 210kmh on busy autobahn, or that people who smell lavender fragrance make less typos and are more productive (I sent this fact immediately to my colleague with whom I used to share an office and passion to lavender). Or sometimes it is realisation that not everyone reads and spends on learning about a software as much as I do. I moved away from digital transition because I was sick of explaining software development basics again and again. Now I explain them on weekly bases 😀 . I like to think that I can assume correctly about previous software development experiences of my respondent and explain missing parts accordingly his/her level of understanding. And almost every second time I fail, because of aiming too high. People try to write an essay without knowing the alphabet! Yes, even in 2018 you have to explain, with patience and empathy, what is a smoke test, what is a negative test and regression test to a developer with 10 years of experience in software development. And this is OK. We all make mistakes, take wrong decisions and can use it as learning possibilities.

 

 

Explaining Software Testing

Michael Bolton is good in summarising fundaments of software testing in a tweet. In my eyes this piece of information deserves a little blog post.

The last sentence is something what teach my ISTQB FL students – you cannot assure that there are no bugs, but you can collect information about bugs you have found. You can analyse them and create set of actions how to secure your software developing process from reappearance of that kind of bugs.

Most of developers want to know if a feature does work or not, but we as testers can only say that Version A did work on Machine B under Circumstances C.  Project managers and customers want to know if it will work on production. We as testers cannot assure it, because we did not test on production. Based on tests on similar environments and under similar circumstances we can suppose that it can work.

Sounds very logical, but it can escalate very quickly, because DEVs, POs and PMs think that testers are there to save the word and to give certificates that the software they are working on, works perfectly as described.

If you still get asked:

– “What do you do whole day long if you cannot tell me will it work or not?!” 

In heated situation like this it is too late to explain semantics, fundaments of testings or why software development process is complex. You should done it as soon as possible you could, when you started to work on a new feature, on new project, in new team or new company.  Remember – one of most important skill of a tester is communication skills. We need those not to be able to talk about the weather, but for explaining what is testing and how testing can help to DEVs, PMs, POs and all others. Daily.

Michael suggests 4 step plan how to learn fundaments of software testing:

  1. Learn how to test: How can a trainee improve his/her skill sets in testing?; To The New Tester
  2. Declare your commitments: A Tester’s Commitments
  3. Recognise that all testing is heuristic: Heuristics for Understanding Heuristics
  4. Learn to tell the testing story: How is the testing going?

Looks simple, but as you start to read the linked resources you will understand that studies can take years. Take deep breath. To be able to explain testing to others, you have to learn it first for yourself. Do not panic if it does not work on a first try. Make experiments, try new approaches, improve your skills. One day you will master it!

My son, my hero @arat.gym _____ Father and son #fatherandson

A post shared by Arat Hosseini (@arat.gym) on

More Agile Testing > Test Automation

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning, Testing Business Value, Investigative Testing. Comming soon:  What Is Your Context?, Agile Testing in Practice.

Part VI: Test Automation

Books

Articles, Blog Posts, Courses, Videos, Code Examples

MORE AGILE TESTING > INVESTIGATIVE TESTING

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning, Testing Business Value. Comming soon: Test Automation, What Is Your Context?, Agile Testing in Practice.

Part V: Investigative Testing

Books

Articles, Blog Posts, Slide Decks, and Websites

More Agile Testing > Testing Business Value

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning. Comming soon: Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part IV: Testing Business Value

Books

Articles, Blog Posts, Slide Decks, and Websites

More Agile Testing > Planning

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing. Comming soon: Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part III: Planning—So You Don’t Forget the Big Picture

Books

Freeman, Steve, and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
Galen, Robert, Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-Time Delivery, Dorset House, 2005.
Gottesdiener, Ellen, and Mary Gorman, Discover to Deliver: Agile Product Planning and Analysis, 2012.
Hendrickson, Elisabeth, Explore It! Reduce Risk and Increase Confidence with Exploratory Testing, Pragmatic Programmer, 2013.
Hüttermann, Michael, Agile ALM: Lightweight Tools and Agile Strategies, Manning Publications, 2011.
Whittaker, James A., Jason Arbon, and Jeff Carollo, How Google Tests Software, Addison- Wesley, 2012.

Articles, Blog Posts, Slide Decks

More Agile Testing > Learning For Better Testing

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction. Comming soon: Planning—So You Don’t Forget the Big Picture, Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part II: Learning for Better Testing

Books

Blog Posts and Online Articles

Courses, Conferences, Online Communities, Podcasts

More Agile Testing > Introduction

Two weeks ago on Slack, we talked about collections of good resources and Lisa wrote that she and Janet created a good one, but it is not available online. I volunteered to digitalise it and she agreed. Since then I am checking links and reading articles. What can I say – it is an AMAZING collection! Thank you, Lisa, for your kind allowance to publish the list online.

This is the bibliography list created and published by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole TeamFor more details on their work, visit http://agiletester.ca.

Part I: Introduction

Books

Websites, Blogs, Articles, Slide Decks