Reading Time: 2 minutes
On Wednesday we gathered at Zagreb STC #15. First of all, I would like to thank our host, King ICT, for hosting and sponsoring this event.
Eight people attended this meet up, with three newcomers. So we started with usual introductions.
After introductions, testers from King-ICT shared their software testing challenges from their daily work. This proved as very useful meet up practice, because this usually sparks interesting conversation about software testing topics.
We moved SOAP UI presentation for next meet up. I would like to state that we have a pending question regarding SOAP UI: How to configure in SOAP UI ssl certificate for testing with https protocol?
Next on table was my hands on presentation of HICCUPPS principles, oracle consistency heuristics that could help tester (or not) to identify is some application behavior bug or not. Those principles are created by James Bach and extended by Michael Bolton. HICCUPPS is mnemonic for: history, image, comparable products, claims, user expectation, product, purpose, statutes. Testers love to use mnemonics. The reason is from learning theory, mnemonics helps you to remember important topics much easier.
I showed how I applied consistency heuristics on Open Office Impress behavior:
Given that I set line width to 0”
When I draw line with that width
Then line is drawn and visible
And line dialog (mouse right click on line, top option) shows width of 0”
Expected: Unable to input 0” line width.
For assignment: please write as comment to this blog your own consistency heuristics analysis for described Impress behavior in order to determine is this a bug or not.
This hands on presentation showed me that we should have similar presentations in future meet ups. Other testers found this topic (automation free topic) very interesting. What is my heuristic for that opinion? The follow up questions and discussions from other testers that were triggered by ideas presented in this hands on presentation, supports this heuristic. And thumb up for Iva, because she prepared for this presentation by creating HICCUPPS mind map. She told me that she uses mind maps in her daily software testing work.
And we agreed for next meet up place and agenda. Believe me, it will be very interesting! So stay tuned!
Reading Time: 1 minute
During my software testing years I realized one important fact. Many software developers and testers claim that they know how to use a number of version control tools: git, SourceSafe, mercurial, cvs, svn, … You name it and they know how to use it.
But still, those professionals produce a lot of project problems by miss using those tools. And by that I do not only mean famous version control anti pattern: delete-copy-paste-my-local-project-to-version-control-repository. Many professionals do not understand basics of any version control system. Basics that enables them to use version control system on a piece of a paper or in their mind. When you hire software professional, do not put under job requirements list of version control tools. Simple statement: “You will need to explain in your words version control fundamental concepts” is enough. We will teach you how to map those concepts to version control tool command lines that we are using in our project.
Yes, I said command lines. Not GUI for that tools. Because, mapping from version control concepts to version control tool is only effective by using command line tools.
So what are version control concepts? You need to understand and be able to explain in your own words following concepts.
Think about those concepts on some practical problem. For example, how would you version control simple document, for example your CV, in your mind. And divide that document in several text files, each section of your CV as one text file. When you will be able to explain basic version control concepts by your own words using that simple example, than you will be able to map those concepts on any version control system currently available.
Reading Time: 2 minutes
Once upon a time, a young tester was wondering through the Twitter forest. He was interested in one part of that forest, part that gathered software testers. He spotted software tester @mheusser, rumbling some strange words. Apparently, one tester had to test forest feature that included 69 different trees.
OH: The number possible test cases? That’s easy. 69!
NOTE: That’s not sixty-nine excitedly, that is sixty-nine /FACTORIAL/. Yay?
i’m going to do some pairwise stuff to get that number down. If I had time, I’d do kaner/hoffman/robinson style model-driven tests.
That is, I would grab live prod data, get an answer, then try to figure out for that id, what the answer /should/ be with my own program.
A young tester only remembered strange but soundly word pairwise. A few years later, young tester took BBST Test Design course. In the last lesson of this course, he heard strange and soundly word again. After the lesson assignment, he finally understood the pairwise testing.
He also learned about the tool for pairwise testing, PICT. Another surprise was that PICT was crafted by forest habitant that he did not like so much.
As with any other tool, you have to know how to use it. PICT has to be used carefully and skilfully. Main feature of pairwise testing technique is to “cut down” number of test cases. Inexperienced tester could think that there is no any tradeoff in that process. But there is.
You have to understand test technique and tool that you are using in order to effectively test features that have explosion of test cases. Otherwise you could easily miss important test cases that were cut off by you using some of the PICT parameters and features. Use referenced links to learn to use PICT in skilful manner.