Agile Testing and more

I was very happy to see ‘More Agile Testing’ book by the authors of ‘AgileTesting’ . Just finished ordering that and thought to share the learning experience with the first book.

When I got hold of the book, I was into my 3rd or 4th year of practicing SCRUM which is Agile and I had a firm belief that I am doing Agile Testing. But Lisa and Janet changed my mind by stating that “Testing on Agile Project is not Agile Testing”. Let me give an example that I came to explain this.

For example I am a Pakistani and embody all the cultural values that a usual Pakistani  would have. Now if a person starts living in Pakistan and spends a good number of years and then claims that she or he is Pakistani, would we believe? We’ll only believe if that person embodies all the values that would make a Pakistani, not simply by spending some good years here. Similarly Agile Testing is a mindset, a culture.

AgileTesting

So that was my first lesson and then I spent good enough time on different ideas shared in the book. My best three are:

The Power of three (or Three Amigos) concept. In almost all of my talks with students or professionals, I mention this notion of collaborating with all. It was glad to see that in slides talking about the new book, it is mentioned that Testers can pair with Testers, coders, business people, analyst, customers and so on. It is kind of taking the collaboration to the next level.

The next concept was breaking testing efforts in concept of Agile Testing Quadrants. I found it useful that when I work on a project, I lay down this chart for me and see if we are covering all the risks. Michael Bolton has recently talked about improving this model and I’m sure Lisa and Janet would talk more about the testing quadrants in the new book.

The third and last takeaway from the book was the notion of embracing change. The Agile practices were not introduced for fun but they were introduced to be able to deliver quality in a changing world. More and more testers understand how to work in changing project needs, more and more they and the projects will be successful. Exploratory Testing helps a lot in situations like these.

So I am very excited to read the new book as it arrives and will talk more about it soon. Have you read the first book and what are your favorites in that?

PS: By the way, the complete list of Key Success Factors from the Agile Testing book are:

  • Look at the Big Picture
  • Use the Whole-team approach
  • Adapt an Agile Testing mindset
  • Collaborate with Customers
  • Automate Regression Testing
  • Provide and Obtain Feedback
  • Build a Foundation of Core Agile Practices:
    • Continuous Integration
    • Test Environments
    • Manage Technical Debt
    • Working Incremently
    • Coding and Testing are part of one Process
    • Synergy between Practices

API testing perspective

Being in the business of testing APIs for more than five years, I often get questions on how it is done and how it is different than other types of testing. Let me explain some basics in this post and some other day, we’ll talk in-depth.

The user in API world is Programmer. The first thing that makes API testing so special is that the consumers of API are 3rd party or the fellow programmers in your team or organization. Now testers are User’s agents and they should exactly do what a user would do. So the tester in API world would be a Programmer that writes tests, samples, widgets, apps, stuff using the delivered API.

That is why in some teams, one of the Programmers takes this role of tester. Or if you prefer to hire a tester (as we do here), you should look for people with strong programming skills who still want to be testers.

API testing perspective

It’s all automated, by default. Since API testing is not called “Automated API testing”, people may assume that part of it is manual and part automatic as happens in usual test projects. But nay, every thing is automatic by default and there are lots of tools to help you out. So the process of building the test code, running the test code and shipping a healthy build is and should be done automatically. Even best is to incorporate every thing through Continuous Integration. The Unit testing tools along with home grown test infrastructures are the hallmarks of an API testing project.

It has to be a joint venture. Though ideally Programmers, Designers, Architects, Business people should take interest in every testing project but what happens is that the ownership of a Testing project remains with the Testing team in most of the cases. It changes in the API testing world, where Programmers take a good part in designing and coding the test infrastructure and writing unit tests. The Testers then add value by writing more complex scenario tests.

Technology really matters. If you are testing a Desktop API or Web API or Mobile API, the scene changes altogether. Similarly your tools and approach towards API testing will be largely driven by Technology. For example, if GoogleTest is used to test C++ APIs, you might use NUnit for .Net APIs and so on. Normally, the language used to write the API is used to test the API again because the Programmers will use the same language e.g. C++ API will be used in C++ applications vs. REST API being used in Web applications.

Maintenance is the challenge as with all coding projects. Needless to say the biggest pain for any coding project is maintenance. People come and go and API features come and go. The API test code needs to be maintained all the time to reflect the current state of the underlying API it tests. Any techniques used to keep your code base maintainable are applicable for API testing projects.

Have you been part of API testing teams? And what are your main takeaways for others?

Two years of blogging

Knowledge Tester blog turned 2 last week!

As I wrote about my experience as a blogger in the first year, I mentioned that the momentum keeps on building. The second year experience is more rewarding and exciting than the first one. Let me share some of these moments.

First, if the first year was a year of contribution then the second year was certainly a year of collaboration. About one third of blog posts were either guest posts or they were about tester meet up or tester survey. One of the regular contributors Huma Hamid has now started her own blog and I’m so happy to have facilitated that process. Another regular contributor Arslan Ali along with other testing friends including Faiza Yousuf is conducting regular sessions on software testing via Outtabox. Through these blog pieces, I made many new testing friends which I could have never made without Knowledge Tester platform. Such is the power of having a platform.

collaboration

(the original photo is at: http://www.teemagroup.com/newsletter/collaboration-technology-needs-collaborative-humans/ )

Second, the reach kept on expanding. I mentioned blog being visited from 53 countries last year and now this number has reached to 90+. Testing is really a global community. And the number of hits keep on increasing. Though last year it was on a scale of 1:8 which is difficult to maintain, yet there was almost a double increase in the traffic. More importantly, about one third of the traffic is coming from search engines which again means that blog is being hit by people who didn’t know me personally. Now I hope they do.

Third, I am now being approached for more coaching/training sessions than ever. One of the recent examples was a person visiting Pakistan from the UK and needing a quick start on software testing. Along with the other trainer Sohail Sarwar, we spent one fine evening at a coffee shop talking about software testing. That person is looking in a very good shape to become a successful tester. And another example is Skype coaching sessions for a Software Engineering student who is also sharing her experiences about this learning.

Finally, the best moment of the year was when my blog on software testing standards got featured on International Society for Software Testing site and I was so happy to see my name listed along the gurus of the field.

Before I start the third year, I have lot of thanks due to all of you: those who read it regularly and share their thoughts here, those who just read, those who came to the Knowledge Tester events, those who wanted to come, those who keep on supporting me on the mission of making this world a better place through Knowledge Testers.

I am reviewing the popular topics and would focus more on what matters more for you. Do you have any suggestions for me to what to write about?

Amazing Grace and History of Testing

Regular contributor to Knowledge Tester blog, Huma has launched her own blog recently where she talks about software testing and women in testing. This recent piece is worth a re-blog here. Wishing Huma all the best in the wonderful world of blogging :)

Grace Hopper Celebrations of Women in Computing 2014 is just few days away and I will be one among the many volunteers to blog about it. While I am preparing to attend this year’s GHC14, I just found a hard-to-miss connection between…”

continue reading at: http://i-thinq.blogspot.com/2014/09/connecting-dots-ghc14-amazing-grace-and.html

Tester Diaries – Exploring the Exploratory Testing

Hello to the interesting world of Software Testing!

My name is Ridha Malik and I am doing Software Engineering from University of Engineering and Technology, Taxila Pakistan. I have always been thinking how we do testing of any software practically and had many other question regarding this field. I always wanted to get some practical experience in this field after having studied the theory as part of my degree. Knowledge Tester and Majd Uddin provided me an opportunity to do some hands-on testing and learn testing skills.

I performed exploratory testing of Android app Disney Memories HD (). “Exploratory testing is simultaneous learning, test design, and test execution” is what I learnt from the Knowledge Tester course material. As per my understanding, the following things should be kept in mind while doing exploratory testing:

  • Charter ( List down what features you have to test or what your mission is)
  • Set the time for testing.
  • Should test some working software.
  • Output is test cases and bugs.

ExploratoryTesting

The Application under test “Disney Memories HD” is basically a photo editor with many functionalities including edit photo, decorate your photo with stickers, accessories, frames, apply filters, capture live picture with any Disney cartoon character, share photo, setting alarm, creating albums etc.

By following the above mentioned Exploratory Testing technique, I had a full day session divided in parts, where I wrote test cases to verify that functionalities and also found some bugs.

One of the learning for me was that how to write test cases. There are two approaches for writing test cases: on Functional area basis and on workflows or scenarios basis. The approach I followed for writing test cases was through workflows, and I think this approach is very beneficial in writing test cases. It may seem time consuming to some people but it is time worth spending.

The document with my findings is here: Disney Memories App Test Cases and you can see the test cases of this app along with bugs. As I went through this exercise, I thought it will be very beneficial to upload this document and share my experiences for people like me who are new in this field and can take help from it.

Do let me know how useful you found this and I’ll write more about more testing adventures as I undertake them.

The thinking break

The story narrates that a factory was going on loss each year and each quarter. The factory owner was not particularly happy with the local management as the owner was overseeing things remotely. To find out the facts and look for a new leader for the factory, the owner paid a surprise visit. This time rather than doing a board meeting in which managers would impress the owner through dancing power points, the owner decided to do the visit disguised as a worker. The owner moved around the factory floor to see workers were rally putting energy into their work, so the thought of the problem at management end strengthened. The owner then walked through factory’s General Manager and all other Managers room and observed what they were doing. The General Manager was very busy and had a pile of papers on his desk along with some decision making going through as more than one subordinates were there to discuss pressing issues. All the other managers looked similar and very busy dealing with day to day stuff except for one manager. That manager was sitting in the chair leaning backward and his legs stretched over the table and was in some deep thought.

641-01518494

(the actual photo is here: http://www.masterfile.com/stock-photography/image/641-01518494/Businessman-leaning-back-in-chair-feet-on-table )

The owner next day announced that thinking Manager will be the new leader of the factory stating that the “real job of management is to think and not to work”. And your guess is right that the factory’s losses started vanishing and it became profitable in a few quarters.

This story I heard from my father (who spent over 40 years in management roles) on more than one occasions, when I was a student, when I graduated and started my first job, and when I started to manage stuff. Whether the story is real or not does not matter here as the message is a real one and a clear one.

So here is my question to all the managers (including people managers, project managers, test managers, …): How much time you spend on thinking? I’m hoping but the answer could be not much as we are busy dealing with day-to-day stuff. So here is a suggestion that works for me and might work for you; take a thinking break here and there.

Yes along with lunch break, coffee break, tea break, smoke break, chit-chat break, nature call break, add one more break to your work. The thinking break. I’m not inventing something new rather reinforcing an existing advice from executive coaches.

Unfortunately the open cubicle style that normally exists in most of software development places is not conducive for thinking jobs. What I would normally do is take a walk based upon the science that walking helps thinking. Or even a thinking day as my friend Ather suggests in this post. The other idea is to book conference room for some time and sit there and rather than doing a boring meeting yet again, do your thinking job. See more thoughts from others or simply search for thinking break.

PS: As I was about to publish the post, saw an excellent piece written this week on the subject by Johanna Rothman.

Do you have other ideas on how to take a thinking break?

Why Standards don’t help Software world

One of the unfortunate paths of wisdom is that if you have solved a problem in a particular way, the next time you see that problem, you will always apply the same solution. Since Engineering, or even better word would be Manufacturing, world is existing for about two centuries now and we have solved many problems of that world, we tend to use the same approach towards the Software world. Though it keeps on failing.

The most famous example of this failing application is the notion of “working hours as a measure of productivity”. As in a factory, all other factors including Machine, Material, Method etc. usually remain the same, the focus is put on the Man. So if the Factory Worker A spends 10 hours and Factory Worker B spends 6 hours, A is more productive. Peter Drucker spend almost his entire life dispelling this concept for the development work and introduced the term of Knowledge Worker (this is also an inspiration for my blog’s name as Knowledge Tester). Such that for Knowledge Worker, the measure of productivity is not the hours worked but the work produced in those hours. Alas, we still find managers and leaders in software world, who still live in the Factory Worker mentality.

Now let’s move to the standards problem. In my earlier life I was a Mechanical Engineer and then I moved to software quality domain. When I was there, I absolutely loved the Standards and when I was first introduced to ISO 9000 (a standard on quality management), I immediately followed it. It was year 1996, when as part of my final year project, I undertook a study of ISO 9000 implementation in the Pakistan Industry along with my friend and we thought ISO 9000 will solve all the problems. The manufacturing world is a world of repetition, so if you set the pattern right, you’ll almost always get a consistent result.

But this does not improve quality, this just improves consistency.

Take this instance. During the visits to different factory locations where ISO 9000 was successfully applied, one of the managers told us about a non-conformance their auditor reported: (a non-conformance is an incident where a practice is not in accordance with the standard or the plan)

“In one of our steps, we rinse empty bottles before refilling them. When the auditor visited the site, the bottles were being rinsed with water and soap. The auditor reported a non-conformity because the procedure stated that bottles should be washed with water. Using soap was a non-conformance”.

ISO fails in software world

Okay, so when I moved to software quality profession my love for ISO 9000 was still there. I along with the same friend, successfully achieved ISO 9000 certification for the software house we were working for and thought of it is a big achievement. But as we were implementing it and started analyzing what we actually gained on quality improvement front, we quickly realized that ISO 9000 is meant for Manufacturing (the repeating) world. Where as in our circumstances, all of our versions were unique and even within versions, the copies with different clients were customized to meet their needs. We, in software world, live in an imaginative world and every software delivery is a step into unknown. Standards like ISO 9000 don’t help in such kind of knowledge work.

So now when I heard of ISO 29119 which is being proposed as one standard for Software Testing, I know that it will not work. Testing is a piece in the Software Development process that is equally creative and imaginative and works like these are not supposed to be managed through standards.

I have signed the petition to stop ISO 29119. Even if they don’t stop this standard, I’m of the view that this standard will not improve the industry as ISO 9000 didn’t improve the software quality.

What are your views on applying standards in the software world?