Yeah, you read the title right. It was a conference held in Islamabad – the capital of Pakistan on November 14th and it was the second edition. I feel really sorry that I missed the first one but am very happy that I became part this time and they have me forever now. It was a very well-orchestrated event which was attended by about 150 Professionals and representatives from the Academia. Below is a brief summary of the sessions and I do plan to right in detail about some of these topics.
The keynote speech was delivered by my friend and mentor Ather Imran on “Agile Culture”. Having worked in Software Industry for so long and currently being CEO of Sybrid who offers a variety of IT services, Ather was well aware of what an organizational culture is. He explained Agile transformation using the golden circle of Why, How and What. The pick of the talk was when he talked about Schneider culture model and suggested to evaluate your organization to see which culture they belong. Agile cultures are heavy on Collaboration and Cultivation, have some interest in Commitment and don’t like the Control one. Ather then also talked at length that after assessing your organizational culture, how you can mold it to Agile culture and what you need to do to achieve that.
Adeel Ali who is based in Texas, US and has his setup in Bahawalpur, Pakistan named ClickChain, talked about “Technical Excellence” in light of one of the Agile Principles. Being an Agile Excellence Coach, Adeel knew exactly why most of the Agile projects fail and he emphasized the need on improve coding quality and training the developers to accomplish that. He quoted that if you apply SCRUM as a management practice but you still have a messy code base, it will take you nowhere as issues will remain the same.
Next up was Suhail Iqbal who has done all the certifications in the world on Project Management and has a deep understanding of different processes and techniques. Suhail introduced the Lean principles with examples from Construction Industry and it’s similarities and differences with Agile. He also talked about how the Agile concepts are being applied to non-conventional sectors (by which he meant non-IT as Agile originated in the Software world). He also introduced LeAgile which is an effort to combine the both worlds.
The last session before the lunch was by me which was an introduction to Agile Testing. After establishing the fact that changes happen too often now a days, I suggested that having more tests is the only way that you can make changes at a high pace. I introduced the Agile Testing Quadrants, the concept of Three Amigs and emphasized that “Testing is role where every team member tests”. I also touched upon Automaton Pyramid and the importance of having a heavy base on Unit Tests.
After a delicious lunch which was actually an excuse to socialize and meet so many like-minded people, the session restarted with a talk on Emotional Intelligence by Mohsin Lodhi. Mohsin is a leadership trainer with experience much more than the average age of the audience that was attending the session. He in his trademark style explained the importance of Emotional Intelligence and how according to modern researches it is proven that EQ plays more role in the success than in the IQ. Mohsin introduced some personality prototypes and audience most liked Tina the Time bomb who’d explode any time. He then talked about how Self Awareness is the key to Social Awareness and Relationship Management and how can we achieve that. Mastering these will help a lot on Agile world where you have to work in teams and do a lot of communication and collaboration.
Barkan Saeed who is CEO of Vizteck and was one of the brains behind this conference took over the stage with a panel discussion on challenges of Agile adaption in Pakistan. Owais Anjum who is CEO of eMumba was representing OPEN Islamabad was joined with Kashif Mueen of Zigron and Nauman Faridi to talk about variety of topics including the challenge of Self-Organizing teams given that the general belief is that native culture is against that notion. The panel also highlighted the current boom in IT and how organizations in Pakistan can benefit from it.
As I mentioned that I do plan to write more about the above topics and maybe will start with a detailed post on my talk. Stay tuned and also keep an eye on Conference page for official coverage of event with photos and videos.
The success of the conference was largely due to the tireless efforts of the organizing committee with Naveed Ramzan being a notable mention. I am convinced that more success will follow.
Do register yourself with PADS (Pakistan Agile Development Society) so that you get in touch for any future events. Thanks and bye for now.
Knowledge Tester turned 3 last week!
This has been a very rewarding journey. As I talked about in the second and first year, this has been another year of success where reach of the blog has now reached 100+ countries with 1100+ individual followers and per post views have almost doubled this year. I can share more success stories along these lines but thought to also touch upon the challenges in the journey.
(The image is taken from: http://www.shapecollage.com/blog/shape-collage-3rd-anniversary-giveaway-loupe-updates-and-more )
When you start a mission, your enthusiasm is high in the start and that carries you for some time. But as the time passes you re-evaluate your priorities and at times struggle to continue your passion. This was a challenging year as a blogger for me and let me discuss the top most concern.
New stuff to write is difficult to find. When I started the blog, I had many topics on which I wrote my posts. The list started to dry out in the third year. And with so many other bloggers talking about the happenings in the testing world, writing about something new or write something new about an existing stuff became tough.
The thing that rescued me was that as you get a followers community of your blog, you hear interesting comments on and off the blog posts. I think about half of my posts in the third year came from those discussions. They were generated from the Activities or the follow up queries from those events.
So my plan is to focus more on such events in the next year which will mobilize more the Pakistan testing community and that will automatically become the supply line for ideas on my blog.
But as I mentioned above, more and more visitors are coming to the blog and highest referrer is now Google with my blog post on “Exploratory Testing vs. ad-hoc testing” going viral in the mid year.
Thanks are due to all the readers of the blog. A special thanks to Ruma Dak who wrote a guest post for my blog on feedback and allowed me to share a post about ANDing your life on her blog. Connections like these would never have been made without starting a blog.
With this, let us start another exciting year of blogging. What topics you like the most or want me to talk about?
When we are kids, we like to believe that world is a simple place.
Our teacher in playgroup or prep or nursery classes would tell us that “Sun rises from the East and sets in the West”. We like this simple concept because it is in accordance with our daily observation and more importantly it is an easy concept to digest for a kid of just a few years age.
As we grow, we are told that Sun is not rotating but it is our Earth that rotates which gives us an effect of Sunrise and Sunset. As we get into higher classes, we are told that Earth also rotates around it’s own orbit and Sun has many other planets. We are then told that Solar system is just one of the so many Galaxies in the space. We are told that we are living in an ever expanding Universe and we are told of something known as Black Holes and theories of Big Bang. We are told that we are not certain if we are expanding or moving to a certain point or we are just hanging around. This very complex nature of the Universe is simplified for us as kids to believe that world is easy: “Sun rises from the East and sets in the West”.
Similarly when we start our professional study or professional career, we like to believe that world is a simple place. There are some rules that if we follow, we can be successful in our business. If we add these magical lines in our CVs, we’ll get our dream jobs. If we network in these best ways, we can excel in anything we want to achieve. We tend to believe that there are some “best practices” that if we get to know and master them, we’ll be the champions in what we do.
This is as simplified version of the world as simplifying the Universe to Sun rises and Sun sets.
The only best practice is that there is no best practice
This Dilbert strip was taken from here: http://theleanthinker.com/2013/12/31/the-problem-with-best-practices/
What we forget when we are in search of best practices is that world is a complex place. Each individual has it’s own strengths and weaknesses, each of us operate in a different region of the world in contrasting cultures, each of us have different values and different meanings of the outcome. What works for me may not work for you. What we need to do is to understand the situation, apply some practices, evaluate the results and keep tweaking them.
You may be tricked to say that see here is the best practice:
Understand the situation, apply some practices, evaluate the results and keep tweaking them
If you are thinking in this way, this is due to the reason that we don’t want to leave our childhood and we love stories and we love simplified versions of the world. The above is not a best practice.
What are your thoughts on best practices?
Having no tests means you have a challenge with the Quality of your solution. Having thousands of tests means you have challenges of test management.
Yes, like testers and development teams, tests have to be managed.
So often we find claims on different tools’ websites that “we have thousands of tests running all the time to ensure quality” but let me today take you inside the life of that world.
As I talked about this problem of putting some tests to “Ignored list” to make the build passing all the time in my post about Continuous Integration, when tests reach a big number the number of Ignored tests also increase and a campaign has to be launched regularly to clear them. The tests in this list come due to three reasons:
- Tests are failing because test code is bad
- Tests are failing because production code is bad
- Tests are fine; they just take too long or have other dependency (data/hardware) that prevent them to be run on build servers.
For the bad test code, a public shaming (a.k.a. peer pressure) email that list down authors with biggest number of ignored tests help. Keep on sending those emails as the some people are more “shame-proof” than others.
For the bad production code, make sure the issue is reported in bug tracking system and elevate it’s status. Do mention to the team that if we fix them, we get two benefits: a) Bug count reduces and b) test count increases.
For the third category, some strategy is needed to run those tests after the build on regular basis. For example, we ignore all Performance tests from the build as they take too long. Then we run them each week and compare them with benchmarks to see if results are good. Bad results are then shared with the team.
Tests that you think run but they don’t
The machinery to include all tests in your repository is a piece of code and it can have bugs too. When you first write and commit your tests, you assume that they run each time yet they don’t.
In one of the audits that I did on my project recently revealed that about 10% of the tests were “not in the system”. The build files had some commented portion that happened due to some reason and then stayed there. There were some assumptions about the folder and files which were not being honored by all tests after some changes. Bringing them back in the system gave us some additional coverage right away.
What do tests do?
The quality of tests remains questionable as unless you see what each test does, you can’t say how good your tests are. But there is always the first step of doing code coverage.
Having thousands of tests doesn’t mean that you have good coverage and all methods are being tested. In the audit that I mentioned above, we found out that our overall LOC (lines of code) coverage was still 50%. Another thing that we found was that:
Module A has 500+ tests with LOC coverage 70%
Module B has 500+ tests with LOC coverage 40%
So just looking at number of tests, you can’t guess the coverage. A note here is that coverage is also not a perfect measure of quality but as I mentioned it is a good start until you can review each test.
Do you have thousands of tests in your project? What kind of challenges you have to deal with?
The Manager Responsible for Release (let’s call that person as MRR for rest of this post) has to make the decision to ship the product and is keenly watching the Iteration Review. Programmers have finished demoing the implemented features and the situation looks good so far. The testers start their part and this is what MRR get:
“14 new bugs reported in the Iteration out of which 8 were of highest severity. 26 were verified and closed. There are still 4 open Defects.
Out of 18 test plans executed, 13 are passing and 4 are failing with some issues reported while 1 is still to be executed.
Smoke testing was done for each of the 4 builds in Iteration and 3 passed whereas 1 failed.
Performance tests were executed on the Release Candidate build.
That’s all from the testing team.”
Confused as MRR wants to make a decision, the person un-mutes the mic on the conference call and asks: “Tell me if we are good to release the build demoed earlier in the Review?”
The test lead says: “That decision is not Testing’s rather it is yours. But if you ask us, we say may be.”
The MRR loses confidence in the testing team in particular and in testing in general (along with losing the temper).
Does the above scene look familiar to you? That a testing status is entirely a report on the testing activities with too much focus on numbers? And do as testers, we need to change our tactics? I think yes.
What do testers do? They provide information about product under test, to expose risks for the team.
In the above example scenario, does the tester provide information that exposes risks? Obviously not. Let’s revisit it and see how activity report can be used to do this.
What is the risk?
Before you prepare your testing report, you should be very clear on what risks are there in management’s mind. These could be in the line of following statements:
- What if the product it not released on time?
- What if the product is not stable enough to be released?
- What if the product is too slow to use?
What information Management needs about that risk?
Management is looking for information in the report and not data (data vs. information). Let’s convert the earlier data and convert it into information:
“There are 4 open defects and they are all related to View Profile feature. Given that this is our first release where Users will mostly be working with their Profiles, they possess a threat to the release if not fixed. 1 defect is of high severity which allows to view profile of any user through modified URLs and fixing it is of high value but of not much cost. The other 3 defects are related to some cosmetics which are important but can be let go if needed.”
Now the MRR feels much informed and says: “Great. If we can fix that and do a round of regression, we should be able to ship in 2 days”. All say yes and life is good (at least for now).
Can you think of similar statement for the test plan results or smoke test or performance results in above example?
All the jobs of software testing brings some joy to life but without argument, the most entertaining moment is when a tester finds a bug.
In the job interviews for software testers that I have been doing for a long time now, one of my questions is: “Tell me about your best ever bug?” Most of the times, the tester’s eyes would glow and they would share the story in the greatest of details. Those are the moments they remember in details because they enjoyed it.
But why do we enjoy to find a bug? No, it is not due to the reason that it allows us to prove that testers are not un-necessary part of the team or outsmart the Programmers. But it is due to the fact that:
Each bug is a discovery of a land never found by anyone else before. It is that unique path in the application under test which was not traveled before. It is a situation that is never triggered before. It exposes the risks that were never known to the team before and brings a new perspective to the release cycle.
(the original photo is here: http://disneyinfinity.wikia.com/wiki/Joy )
The other reason that makes the testers happy is that a bug discovered before release makes the team safe from it being found by the outside world. A bug found means fixing it will make the release more solid not just by fixing that problem but by making a conscious effort in the area exposed by the bug.
And when you explain the bug to your team members verbally or through a bug tracking system, it adds an element of story telling. Oh boy, telling a story is always fun because you are telling a tale that the listener has never heard of and it is full of surprises. Another similarity that I present to my team members is that:
“A bug is to a Tester, what a verse is to a Poet”
It is a creation from non-existence, a source of pride and a statement never said before.
What has been your most enjoyable bug so far? Do you see other reasons that make finding bugs so happy moments in a tester’s life?