Hmm.... I was sort of in a cave after day 5th and now it's action time for me again.
Not that I was totally out of the challenge but could not manage to blog about it. So... here is the list of tasks on my plate and what I did about them (updates for the pending tasks are in brown)
Day 6. PAIR WITH SOMEONE OUTSIDE YOUR BUSINESS UNIT OR OUTSIDE QA
I paired with a free-lance programmer who was helping us with our ongoing project on-the fly. Time was critical and he needed someone with enough knowledge about stuff he was working on. We paired up to develop it and test it on the fly.
I used the MIPing technique (Mention in Passing) to report my bugs/findings and re-tested the things as he kept on fixing them. It was indeed fun pairing with a programmer and contributing right from the coding phase for new feature getting built. We benefited from each other's expertise. My programmer counterpart got the on-boarding that he needed and also learned about the dependencies we had to resolve. I got benefited by watching closely how he quickly developed the components, wrote his unit tests and ways to resolve conflicts.
Day 7. GIVE SOMEONE POSITIVE FEEDBACK OUTSIDE OF QA
The last few weeks have been crazy for us at work since we have been working on some serious stuff and the fun part is the complexity of the solution we have. At times, we can't escape from dealing with the complexities of the software/projects and this whole thing makes testing and bug-investigations even more challenging. The reasons are obvious. The interfaces, dependencies, various states of the systems involved, pre-requisites for use cases and schedule, new features added , subsequent impact and regression add a lot more to already existing complexities.
Among other things we found and fixed, we were struggling to resolve one bug which was hidden deep under the interfaces and lost in the complexities of interfaces. Finally Lars Schirrmeister (our Senior Back-end Engineer) jumped in and decided to get to the root of it.
After spending quite some hours on fixes and trials (Try -- and See -- If it works) he finally found the problem. And fixed it of course. But what was so special about it? It indeed was. The problem Lars identified was found out because of his own understanding of the technology, algorithms and syntaxes. The issue he found out was 'never raised as an error or exception by the system itself' and finding out hidden problem in a code laden with complexity, that does not show up in compilation/debugging at all is indeed an intelligent task. Good job Lars!
It's an honour for me to be working with a such highly competent team and managers. There has always been something or the other I could mention in their admiration. This particular case is one example of it. I'm glad that I could talk about my team with the world because of this challenge. :)
Day 8. HAVE LUNCH TOGETHER AND POST A PICTURE
Who else could be a better date for this day of challenge other than one from fellow participants :). It was great meeting Daniel Knott over lunch to discuss testing and this 20days challenge among other cool things . Feel free to check Daniel's updates on this challenge.
There goes our picture together:
Day 9. AUTOMATE ONE WORKFLOW FROM ANOTHER BUSINESS UNIT (Pairing allowed, but be the driver)
Could not mange to complete this task in time. It's WIP though.
Day 10. PERSONAL CHOICE (Testing related, surprise us!)
I'm conducting a workshop on Impact Mapping for my colleagues, on 13th Oct. The idea is to implement the concept on team level (rather than keeping it limited to Senior Managers, Product Managers, SCRUM masters etc).
My workshop would mostly talk about implementing IM on Story level and writing them with information, enough to build testable features with wider coverage. Won't say it is only related to testing but it would definitely benefit testers working in Agile teams.
Day 11. LISTEN TO A TESTING PODCAST
I listened to DevOps and Technical Testers podcasts featuring Noah Sussman, Michael Larsen, Perze Ababa and Justin Rohrman ( yeh, all cool people :) )
I feel this discussion has come on the time when testers needed it most. If you are wondering about what DevOps is and what roles testers can play in it then please consider listening to it. Highly recommend!
Day 12. PERFORM A CRAZY TEST
Hmmm...this is my kinda topic. Well, honestly I don't remember the last time when I did not perform a crazy test :) The degree of craziness of a test might vary from a tester to tester based on what they perceive it to be.
For me, a test performed with minimal knowledge about application and acting like a 'first time user' is equally crazy test. With minimal knowledge I mean not getting blinded by the specifications and testing things with open expectations. Paul Holland has written an interesting piece around it, please do read it.
On contrary, while testing the recent build of our product, I came across many ways to perform crazy tests with enough knowledge about software, dependencies and solution implemented. And I learned very important thing that a crazy test does not always have to be around the 'disfavoured use' or 'extreme use' of software (please check Product Elements in HTSM by James Bach). Playing around with the configurations, states of a test data, teasing the pre-requisite states of system meant for some desired results or challenging the the implemented solution itself via variety of tests can also help uncover a lot of interesting things. Defects won't always be the outcome here but knowing in advance how system behaves against all such adversities can help build lots of useful tests that can find hidden and illusive bugs. And it may also help to be prepared with fall-back solutions.
It's hard to explain without enough details but for example one can perform crazy test by trying to break the protocol/steps meant to be followed to reach certain state of the system. What happens if state 1 is left buggy and state 2 is still turned ON? What happens if one tries to enter the state 2 without fulfilling the pre-requisites from state 1 and so on...
More on that with publishable examples later...
Day 13. DOWNLOAD A MOBILE APP, FIND 5 BUGS AND SEND THE FEEDBACK TO THE CREATOR
It's last day today and I doubt if I would be able to make it. However, I have a try for testing recent release of IOS 10 and noticed that the spell checker wasn't working as expected. That is, when you select the incorrectly spelled word for correction, the options that you would get would only be for formatting, copy paste etc and there was no 'suggestions' for the possible correct word.
I do have some plans to test some interesting apps though...but time demands me to do something else, more important at this time :)
Day 14. FIND AND SHARE A QUOTE THAT INSPIRES YOU
There isn't just one that inspires me. I have bunch of them in my collection. Sharing some of my favourite though
1. Endow your will with such power that at every turn of fate it so be, That God himself asks of his slave, "What is it that pleases thee?" - Allama Iqbal
2. Your ideal form of influence is to help people see their world more clearly and then to let them decide what to do next - Jerry Weinberg
3. There is no test for ALWAYS - James Bach
Day 15. CONNECT WITH A TESTER WHO YOU HAVEN’T PREVIOUSLY CONNECTED WITH
Connected with Cassandra H. Leung (Tweet_Cassandra) and Abby Bangster (@a_bangser) on twitter. It's always pleasure to connect with like minded testers.
Day 16. SUMMARISE AN ISSUE IN 140 CHARACTERS OR LESS
Take 1: An "issue" can be anything that concerns the stakeholders. (Char 59 + Whitespace 9)
Take 2: The real issue is that I can't give more details about because it is an internal thing. (Char 88 + Whitespace 17)
Day 17. FIND A USER EXPERIENCE PROBLEM
I came across some websites that are offered in multiple languages (e.g. English and Deutsche) the image illustrations were updated in chosen language. For example if the adverts and campaigns and some "How-to"s are shown in pictures and they are only made in one language then it adds to bad user experience of other set of audience who don't understand that language.
Day 18. SHARE YOUR FAVOURITE TESTING TOOL
I like bunch of them meant for different purpose. By the way testing tool for me, is any tool that assists me test better.
Day 19. SAY SOMETHING NICE ABOUT THE THING YOU JUST TESTED
We successfully rolled out a very complicated and critical release to production. Because of the nature of complexity of the solutions and new things we added on the fly, I was bit skeptical about completion of testing but I'm glad that we did manage it well and the code was robust enough to handle my all sort of crazy (and not-crazy) tests gracefully.
Day 20. TEST YOUR PRODUCT FOR A QUALITY CRITERIA, WHICH NORMALLY IS NOT A FOCUS IN YOUR BUSINESS UNIT
I do this all the time to be honest. My checklist for Quality Criteria is pretty comprehensive and we keep adding new aspects to it when we see enough problems of the kind, to count. However, I have added some items to "Compliance" testing aspect recently which we were not doing with special focus before.
Day 5 is about "Coming out of your comfort zone".
Well, it took me a while to figure out my own comfort zone since I have never thought so deeply about it. Whatever has been thrown at me a 'testing task' so far, I tried to get through it like a go-getter. But hey, we all have special likings and comforts towards something or the other.
Thinking about it made me realise that, I sort of feel satisfied with the testing philosophy and knowledge I have received through James Bach, Dr. Cem Kaner, Jerry Weinberg and Michael Bolton (to name a few). My expertise are mainly with helping teams/organisations implement this knowledge/philosophy (especially around RST) in a way that fits better with their contexts. Indeed, it's not as easy as 'one idea that fits all' thing and rather requires me to constantly read, re-learn and understand the ideas so that I can find context appropriate solutions for different problems. But I too want to have something that I can claim to be my own thing, theory and work. Yes, I do teach my classes and workshops with my own methods and ways of explaining things but the key concepts are primarily inspired by the work that has been already done by experts mentioned above.
While discussing testing with James Bach the other day, he told me that as his student, he wants me to "innovate" and bring fresh ideas, perspectives to testing. And that's what I am currently working on. I am reading and researching around ancient Vedic scriptures that I feel would help me bring new ideas to testing or may be to re-learn existing ideas in different light (which is equally important).
That's the kind of stepping out of my comfort zone for me. Unfortunately, it's a long process but I'm sure that it will be worth it. I am excited about what I'm currently working on and am equally excited to bring it on the table for the community to see,comment and feedback.
Thanks to #20DaysofTesting@XING challenge for making me serious about it once again. Until tomorrow then folks...
On day four of the challenge, I am expected to find a testing event (online or in person) to attend.
I have signed up for New Model Testing: A New Test Process And Tool webinar by Paul Gerrard and organised by TestHuddle team of Eurostar conference. And it is happening today :)
Looking forward to attend it. It's always nice experience to learn from Paul and new interesting things he keeps working on.
Oh, and by the way Paul did one interesting webinar on Internet of Things with Tea-time with Testers in past. Feel free to check it out if you like...
That's all for today. Stay tuned for more amazing stuff ...
As a part of day 3 of #20DaysofTesting at XING AG challenge, I was expected to read one blog and comment on it. But the blog I have chosen to comment on has rather encouraged me to write a blog instead of just leaving a comment.
While reading some interesting discussion around testing and “100% test automation” thing, I stumbled upon “No Testing” blog by flowchainsensei (aka Bob Marshall) shared by one of the participants in discussion (thanks Nilanjan).
This is an interesting post I must say, particularly because the arguments and ideas presented by Bob made me ponder and encouraged me to think critically about the value of my own profession i.e. Software Testing, yet again.
The blog is bit old and I don’t know if Bob’s opinions have changed but I would like to discuss around some ideas he has expressed in his blog. I must mention that this blogpost is not a response to Bob in person, I have great respect for his work and I admire his writing around Agile/Software delivery. I decided to discuss the ideas from his blog mainly because I still come across people who share similar opinions. This post is my humble attempt to explain what I think about those opinions as a “passionate tester”.
If I have understood Bob correctly, his key arguments are something like below and I believe that majority of the fans of “no testing” idea share them (more or less):
Alternative to testing:
While I tried to think deeply about the above argument in the list, I felt that it is indeed possible and is being already done by testers who understand what testing really is, who know how to test software rapidly, inexpensively and in a way that would still stand up to scrutiny. It is already being done by testers who know how to do “more with less”. The only difference is, they still call that strategy as ‘testing’ but hey, what’s in the name as long as it does what matters?
I would not hold it against Bob (or anyone else with similar opinions) if they want to find alternative for “testing” (whatever it might mean to them) because it’s possible that what they saw someone doing as “testing” was not more than filling excel-sheets with Pass/Fail and being a bottle-neck for deliveries. If that makes them want to find alternative to ‘testing’ or getting rid of it completely then I can totally understand it.
The good part is, testing is far beyond just a process, profession, phase or strategy for most of the thinking testers today. For us (thinking testers) Testing is a performance as James Bach rightly says. And the number of testers who think this way is growing like never before.
Testing is needed so that testers can earn their living:
This can’t be really true anymore, at-least for the testers who know how to add value with their work and what their worth is in software development. I completely understand the humanitarian aspect here but with due respect I deny that ‘testing’ is needed so that “testers” continue to earn their living. This holds equally true for all sort of professions in software field for you never know what would science discover tomorrow.
Today, earning the respect of peers appears an overrated issue to me, to be honest. If non-testers understand how “testing” helps their work then there is not any reason why someone would disrespect testers. How can someone’s ignorance be someone else’s problem? As a matter of fact, I have seen programmers feeling envy of their testing/QA counterparts for the kind of weight they hold in a team and the way testers get treated as project-trusted advisors. I have seen programmers who do not understand the difference between writing a code “that does what specification says” and to “develop a product that customer would like to buy/use”. Does that mean “programmers” have a respect issue? I don’t think so. Respect issue with testers probably gets highlighted because they are far less in numbers compared to their programmer counterparts (1:4 I guess?) and unfortunately, bad testers continue to outnumber the better ones. Slowly but surely, this is changing for better.
Testing adds little or no value from customer’s point of view
The value testing can add to the project can be best summarized by Bob’s excellent definitions Quality and core purpose of Software Development.
According to Bob, the core purpose of Software Development is, “to create elements of complete products or services. Complete products or services, which attend to – and hopefully meet – the emotional, human needs of a variety of interested people”
Bob’s definition of Quality says, “It is meeting the needs of some several collections of people” and I agree with that in principle.
Meaningful testing caters to ensure exactly those and if that’s not a value then what else is? And most importantly, customer or anyone for that matter would understand this value provided by “testing” only if they know that “testing” has a role to play in it. Do we give up on better practices, making better technological choices just because customer fails to understand them? No, instead we help them understand what they really want and how best we (as service providers) can do that for them. Why to give up on testing then if customer does not know its worth?
Customers are unkeen to pay for testing
I feel that customers are unkeen to pay more for “entire cost of software development” and not just for testing in particular. Customers want a quality product at a price they can afford. Whether to do it by cutting the testing short, with no testing at all or by employing testers who know their job very well, is service provider’s problem. And I feel there is a lot of other waste we need to get rid of apart from bad testing. I would highly recommend checking out “Lean Software Delivery” by Matt Heusser if you are curious to know more about this subject.
It’s possible to deliver software that "just works" without having to “test” it
I admit it is possible as long as our "it works" matches with customer's expectations and user experience. But ensuring that they match is hardly possible without doing any testing.
Some years ago, I had asked same question to Jerry Weinberg and his response was detailed enough for me, not to think about that possibility anymore.
I asked Jerry if there is any method/strategy that can eliminate the need of testing or testers as a role. Jerry’s response below:
You're kidding, right?
This is a pipe dream of managers who do not know how to manage s/w development, just like their dream that some magic method will allow them to get rid of developers. "Tester" might not be a job description, but "testing" had better be part of somebody's job description--and taken seriously.
Over more than 50 years, I have watched managers fall for these illusions. Sure, it would be nice to be able to develop s/w without testing, or without developers. Indeed, it would be nice to become a billionaire without leaving your easy chair in front of the TV. But just because it would be nice, that doesn't mean we know how to do it.
The only times when I've seen s/w developed w/o testing, the s/w produced was not usable, and nobody wanted it. So, I guess if nobody wants the s/w, it could be developed w/o testing.
Heck, I could cook a fabulous meal as long as nobody wanted to eat it and live through the experience.
The times are changing fast and the pace with which science is advancing, I sometimes feel, "Would humans be ever needed in future to build software for customers? What if they build a computer that reads the requirements and delivers the software just like a pizza fresh from oven?"
“No Testing, No Agile and No Software Delivery” attempts to flag up these questions. No soapbox. Just open enquiry.
Some awesome colleagues at workplace (Maik Nogens and Ionut Oancea) have come up with this cool idea of 20DaysOfTesting@XING, on the lines of what Software Testing Club did some days back.
I regret for missing the 30daysOfTesting challenge by Rosie and so have decided to participate in this another opportunity at the workplace itself. I'm usually engaged in such cool ideas from other side of the table (say organisers) and am really excited to get the feel of being a "participant" this time :)
Coming to the point, the tasks for each day of this 20 day challenge are:
Sounds like an interesting bunch, isn't it? Well, given that this challenge starts from today, let me do the fist task without any further delay:
Day 1: TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK
That's me ... having great time with my 3 awesome screens. Usually, I read interesting technical stuff in morning hours. And I was reading some cool shares from our "Software Quality" page on XING. Have you checked it out, by the way? You should!
Naturally, I won't be able to share specific details of the internal things I would do for further tasks in this challenge but I can at least blog about the stuff and the fun I had.
So, I am looking forward to upcoming tasks for next 19 days and I'm sure it is going to be fun. How about starting some similar cool campaign at your workplace and let us all know what 'fun' you had? I look forward to it.
A passionate & thinking tester. Trainer & student of the craft of testing. Father, Foodie and dog lover. Chief Editor and Co-founder of Tea-time with Testers magazine.