Report for Zagreb STC #6 Meetup

Reading Time: 3 minutes

Yesterday we held our 6th Zagreb Software Testing Club meetup. We have been gathering now for one year! You can read more on agenda meetup here
There where ten testers, three of them where first time at the meetup. We started with tester introduction and what he tested last week. Other testers had a lot of questions during that introduction, so we got debate that lasted for almost an hour. And that is what you should expect from every true tester!  
After pizza, Manuel started his presentation on software testing. It is based on his final faculty work, and it represents one of the rare software testing materials in Croatian language. For me this is excellent starting point for someone that does not know what is software testing. Unfortunately, in Croatia there is a lot of IT professionals that does not have a clue what is software testing. We will encourage Manuel to repeat this presentation on next Viaqa (hopefully with new conference name) conference.
During the presentation, almost for every presentation topic, we had a debate and conversation. I was very pleased with that. From discussion I concluded that we are working in different ‘software testing schools‘. For now we have factory and agile representatives. At work my company legacy is Factory school, and I am trying to introduce Context driven school. In my free time, on my Elance projects, I am practicing knowledge from Context driven school. 
As I do not totally agree with Manuel presentation, here are my comments.

  • unit testing is software design technique, better known as Test Driven Development. Developer use this technique to better design his subsystem. Subsystem can not be done from the first try (unless you are Dijkstra fan). It is created in small iterations, with every iteration committed into version control, and changes covered with unit tests. Developer should prove that his subsystem works as he thought that it would work. Unit tests are that prove. Testers must also test that subsystem. Developer should prove with unit tests that reported bugs were fixed.
  •  code coverage with some percentage does not measure the quality of code. It is more important that developer creates unit tests that prove its subsystem design. And it is also important that testers test the subsystem using their brain and testing knowledge.
  • this video is very good explanation why mentioned metrics are dangerous in software testing.
  • list of testing methods is not complete. I encourage Context driven testing (by Caner and Bach).
  • I like chapter 2.9 because it mentions real testing. However, statement about negative sides of Agile testing is wrong. People who do not know how to apply Agile are responsible for problems with Agile. With chapter 2.9.2 I totally disagree. The truth about Exploratory testing could be find here. (Bolton)
  • Chapter 2.9.3 is about automated testing. I would like to state that automated testing is not only validation (pass/fail). I support idea (Bolton, Bach), that automated testing is a tool in executing testing idea.
  • Chapter 2.10 talks about Factory school. That school was attempt to implement in software testing processes from Toyota car manufacturing process. And I think that is wrong. There are also other software testing schools that were not mentioned. 
  • The most important software testing tool is our brain. I have experience with Mantis that I use in my company not only for bug reports, but also for task management. In my company it took 1.5 year to everybody accept Mantis for that purpose.

In overall I think that Manuel’s work is very good starting point if you need to prepare for some kind of testing certification.In the last minutes of meeting, Zeljko explained to us Cucumber scenario outlines. Zeljko also wrote about the meeting.

In the end, I would like to state that I am very pleased with direction of Software Testing Club meetup! Marko, a regular meetup attender, also wrote his thoughts on meetup discussions. 
See you in two months.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testing in 140 characters (or less) #6

Reading Time: 1 minute

In discussions of software #testing, people often say to me “In the real world, I have to…” just before they describe some way of faking.
— Michael Bolton (@michaelbolton) September 11, 2012

bit.ly/Qdv3o5 @jhunterj @salvius23 And instead of thinking “pass”, think “appeared to meet some requirement to some degree.” #testing
— Michael Bolton (@michaelbolton) September 12, 2012

@michaelbolton One answer: testing that ignores problems and value.
— George Dinwiddie (@gdinwiddie) September 12, 2012

bit.ly/RIEj5g User experience is also about responsiveness, compatibility, support, elegance, flow. Are you #testing for those?
— Michael Bolton (@michaelbolton) September 12, 2012

Bugs are bad, but confusion, misunderstanding, and disagreement are the nests where bugs develop. Give priority to reporting nests. #testing
— Michael Bolton (@michaelbolton) September 13, 2012

If you think #testing is the bottleneck, another problem is that there are things around the bottle that are poorly understood.
— Michael Bolton (@michaelbolton) September 13, 2012

@aquintian If you’re a tester, it’s very unlikely that you have control over schedule, budget, staffing, release date, product scope (1/2)
— Michael Bolton (@michaelbolton) September 13, 2012

@aquintian or source code. So the best you can possibly do is to provide information to those who DO have control over those things. (2/2)
— Michael Bolton (@michaelbolton) September 13, 2012

@aquintian So the question arises, then:on what, exactly, do they base a *demand* for you to deliver a high quality product?
— Michael Bolton (@michaelbolton) September 13, 2012

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testing in 140 characters (or less) #5

Reading Time: 1 minute

Feeling stuck when #testing? To get unstuck, try changing something, anything, big or small, /right now/. Stand up; doodle; change fonts.
— Michael Bolton (@michaelbolton) August 25, 2012

Photo radar doesn’t prevent speeding; it tells us if speeding happens. Awareness of it helps some remember to be conscientious. 1/2 #testing
— Michael Bolton (@michaelbolton) September 5, 2012

In the same way, checking doesn’t prevent bugs; it tells us about some bugs, and may remind some of us to be careful. 2/2 #testing
— Michael Bolton (@michaelbolton) September 5, 2012

“Passing a test” means “meeting expectations”, but we don’t often take time to examine those expectations in the first place.
— Jon Bach (@jbtestpilot) September 5, 2012

Testers; slaying beautiful hypotheses with ugly facts.
— Ben Simo (@QualityFrog) September 6, 2012

Testers: Disturb people. Disturb their thinking. Ask questions that disturb settled lines of thought; provoking new ideas.
— Ben Simo (@QualityFrog) September 6, 2012

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather