DevOps is a big thing these days and it is hot. Lot of people are talking about it and as we are going through this journey of adapting DevOps culture, we are learning it.
In recent month or so, I have given some introduction to fellow testers at my organization and shared thoughts at couple of Industry sessions. So I thought it would be good idea to share my slides here.
For further study, I’d recommend reading following content:
- “Effective DevOps” book by Jennifer Davis & Katherine Daniels
- Microsoft’s guide to DevOps
- Continuous Integration blog on Nutcache
- “A Practical guide to Testing in DevOps” book by Katrina Clokie
- Continuous Testing by Dan Ashby
- Moving to weekly releases e-book by Rob Lambert
All the best with your DevOps journey!
Jerry Weinberg is my favorite author on the subject of Software Testing and I have posted about lessons from his Errors book, shared my thoughts on some types of Bugging. Lately I was very happy to finish yet another book by him called “Perfect Software and other illusions about Software Testing” which was on my reading list for log due to excellent reviews.
Now having spent almost 15 years on Software Testing domain and overall 20 years in the pursuit of Software Quality in general, my first impression was that the illusions Jerry will talk about will be one of those that I’m familiar with and/or have dealt with. But Jerry surprised me with his wealth of knowledge and interesting examples from his illustrious journey as a Software professional. I learned lot of lessons and sharing the top 3 with you.
- Pinpointing problems is not Testing
Some activities that I always thought to be Testing’s responsibility are actually in a grey area where these have to be shared between Testers and Programmers. Pinpointing a problem, after it is found, is one of them.
In one of the early team that I worked with required that when Testing reports a bug in the Tracking System, they should mention the first major version it was introduced. For example, if a Tester finds a bug in v 3.4, Tester would check if it existed in v 2.0 and v1.0 (if the answer to 2.0 is no). That is an activity that Jerry calls Pinpointing and suggests to differentiate it from Testing and Debugging.
Even in my current project, because we (the Testers) have the code and are able to debug an issue, our Data conversion issues are reported after pinpointing and debugging. Hence a Tester’s considerable time goes into locating the problem code after finding the problem. This is included in Testing whereas it needs some separate attention.
In Jerry’ words as he summarize this as a Common Mistake and suggests a solution:
Demanding that Testers locate every fault: This is totally a Developer’s job, because developers have the needed skills. Testers generally don’t have these skills, though at times, they may have useful hints.
- Providing Information is hard
Jerry talks in much detail Tester’s role as information provider. He suggests to use Satir interaction Model:
-> intake -> meaning -> significance -> response ->
There are separate chapters dedicated on each of the above and I’d encourage any Tester who is serious about their job to understand this model through reading the book. Different techniques have been discussed to improve information intake, how different people will mean different things from same observation, how to know which information is significant and finally how to make the best response accordingly.
- Product reviews are actually testing
In fact Jerry calls it “Testing without Machinery” and suggests that technical product reviews are actually a way to provide information and thus is Testing. He also lists some “instant Reviews” which is that if you try to review and you hear excuses like below, you know that something is wrong:
- It’s too early to review it.
- It’s too small to bother with. What could possibly go wrong?
- We’ll let you know as soon as we are ready.
- We [tested][tried][demonstrated] it and it works okay.
It’s a treasure of information on those few pages which you can get instantly once you ask for a review. This has inspired me to write more about Peer Code Reviews so you should expect an article soon.
Let me end this with Jerry’s words:
If humans were prefect thinkers, we wouldn’t need to test our work. … But we are imperfect, irrational, value-driven, diverse human beings. Therefore, we test, and we test our testing.
The signs of a growing IT industry in Pakistan are evident with the number of events that happen each year. One such event is the annual conference on Agile which saw it’s 4th edition on October 21, 2017. The Agile Conference Pakistan 2017 hosted by Pakistan Agile Development Society hosted over 300 professionals joining from around the country. ClickChain team from Bahawalpur lead by Muneeb Ali, Contour Software team from Karachi under Owais Ashraf leadership, and half the panelists from Lahore provided the best possible mixture of top IT talent at display during the day. The theme this year was “SCRUM in Pakistan”.
Do use it at Home:
For many commercials and TV programs with stunts, they have a message like “Don’t do it Home”. Naveed Khawaja who is a UK based Agile Trainer and Coach (and adjusted his schedule to be able to join us) mentioned that because he loves Kanban, he does all his personal work through it. He shared examples like:
- His 6 year old daughter using a Kanban board.
- His family using a Ramadan Kanban board.
- His (poor) carpenter being Kanban-ified for some renovation work.
The idea that I got is that if you like something, you can try it for both your professional and personal life. Interestingly, after I attended the 7 Habits training from FranklinCovey few months ago, I practiced the learning both at office and at home.
(more photos at: https://www.facebook.com/bendaoods/)
Purpose is more important than Terminology:
Sumara Farooq in her talk suggested that when SCRUM or any new initiative is implemented in an organization for the first time, the message can be simplified by focusing on the purpose or intent of doing something rather than using the terms. For example:
- A Storyboard is actually there to provide visibility.
- A Daily SCRUM is actually needed for better collaboration
This indeed can change the way you communicate with the real folks who’ll embrace the change if they like the purpose rather than saying that “we need SCRUM from tomorrow”.
Performance = Skill x Will:
Mohsin Lodhi was fantastic in his talk as usual and threw in lot of interesting ideas for anyone who manages people. His main theme was Servant Leadership such that what it is and how to achieve that. As he was setting up the idea, he shared the above formula which I really liked. I have seen many teams under performing because either they lack Skill or they are not Willing to do it. I learned that both of these are important and any leader should work on enhancing Skill of the team and buying their Will to perform.
Selling your idea is the main thing:
The panel discussion which had Naeem Iqbal, Naveed Khawaja, Faisal Tajammul, Shaima Niaz and was moderated by me saw a flurry of question from the audience. The question ranged from difficulties in SCRUM transformation, lack of top management support, collaboration issues, fear of failures etc.
A common theme that I saw in the questions was that you know why an idea is worth (say SCRUM) but you are unable to convince others. I call this a “selling problem” and as someone rightly said:
Selling is not part of the game, it is the game.
Unfortunately all of us, the IT guys think that if a solution is technically good, people would love it and buy it immediately. But buying something is more psychological than technical and we need to learn the art of selling. I am learning it too but have found one thing: if you target on the need of the buyer, you might be able to sell something. For example in case of SCRUM, consider selling cost saving and faster results to management and consider selling self-organization and better prioritization to your team members.
There were lot of amazing people that I met over the conferences and many interesting discussions (including Khurram Ali‘s talk on User Stories, Muhammad Ibrahim‘s research presentation on Scrum and XP) that I saw which I’ll try to cover in future posts. Before I go, want a special mention of Faiza Yousuf and Noorjehan Arif who came from Karachi for the conference and ran our twitter campaign. And yes, #AgilePK and #ACP2017 were the top trends on that day.
Thanks to all members of the organizing team which orbit around Naveed Ramzan, who worked hard to made it a memorable day. And Anum Zaib lifted the level of event host considerable from last year (last year it was me :))
What did you learn from the ACP2017 if you were there? And if you were not there, what else do you want me to cover about this event?
The best answers to “what is the job of testing?” always have a key component suggesting that it is “to provide information”.
Testers job is to provide information for the product under test
They provide information about product under test, to expose risks for the team.
Now if you have been provided information any time in your recent past, you can easily recall that some of it was valuable and some of it was not. Even some information which was provided to you was false, misleading, hiding the facts or inflicted with similar diseases. So how do we, the testers, can provide information which is always always valuable to the person who is receiving information?
I believe the answer is in two parts: a) How do we collect information? and b) How do we process and present the information?
May be I am bit vague above, so let me spend some time to explain myself.
To provide information, you need to have all the information available to you collected from different sources like test results, design documents, release schedules etc. And then you need to process this information for the given need like the occasion, the person or timing of the information being provided. Like providing specific filters to view information from a certain angle.
Let’s dig a bit deeper.
How do we collect information?
Some testers are overly relying on only the results of testing. They don’t like to discuss with Development about how those tests are designed or how the results are interpreted rather they believe that results of testing are the only source of truth.
Then there are others who love documents. All of the information they have is primarily coming from a document e.g. Design document, Project Plan, Release Plan, or some sort of change tracking system like TFS. For them, those documents are the only source of truth.
And there are the third group who like verbal communication. They discuss each and every type of test in daily SCRUM calls and get feedback on Iteration Review results. They discuss release plans with the management rather than looking at what the document suggested at the start. They are of the view that people involved in the team are the only source of truth.
Not many people know that if all the information you have is coming from a single source, you don’t have a complete view. Consider political arguments that happen in your work environment between people who watch/follow a particular news channel.
So if as a Tester, you want to improve your skill as a better information provider, the first step is to widen your input sources. Test Results, Documents, People all matter. And even there are other sources which you know better than me.
How do we process and present information?
So when you are asked “How was your weekend?”, your answer largely depends on who is asking and in what circumstances. Your answer will vary in details and emotions for your jogging partner compared to your colleague; your best friend compared to someone you are meeting for the first time at a business meeting.
Similarly when you are asked “How is the testing going?” or “Are we release ready?”, if you are giving the same answer to every person in every possible settings, it shows that you are not filtering the information you are having and passing it on as it is. Apply different views to the same information given the context and your answers will contain valuable information for the receivers.
What tips you have to improve information gathering and processing steps?
KnowledgeTester turned 5 few days ago!
And as I discussed the journey in first, second, third and fourth year, my first happiness is to see that it is still going. I am, just like many of you, type of a person who “has a habit of starting projects and not completing them”. Though the project of blogging never finishes but continuing it for 5 years certainly can be used as a yardstick to call it mature.
(the original image is here: http://learnchineseinyunnan.com/news/news-wire/2015/08/20/2015-the-fifth-anniversary-of-thanks-giving/ )
The biggest achievement of fifth year is not a personal one but a collective one. And I sincerely hope you know that collective success has more savor than a personal one. And that was the first ever testing conference in Pakistan that we saw happening in April 2017 in a great way. My report on it “Pakistan Software Quality Conference 2017” has been the most viewed post of the year and I’m so happy to have achieved this through all friends specially the support of Pakistan Software Testing Board.
Interestingly that was my top most priority when I recapped fourth year. Now you can easily guess that this year’s priority is to make PSQC a regular thing in our Industry and we are working for PSQC’18 which will happen in February 2018 in Lahore Insha Allah (God Willing). Though we went into a momentary post conference enjoyment mode, where we made little progress in recent months but we are now getting back with two meetups coming soon in the remaining months of 2017.
On the viewership increase, I am seeing a 20% increase in per post views which may not seem great compared to previous years. But you know as the baseline increases, it becomes hard to keep increasing at same pace e.g. think how salary raise in % is tougher as your salary gets higher. But net effect is that views per post are almost at 1,000 now (967 to be precise) in last year. Yes, I can’t believe that this viewership is for the stuff that I’m writing but it’s true 😊
During the last two years or so, due to the community building activities KnowledgeTester was low on providing training to Testers. The good news is that I’m setting this as my second goal for the sixth year i.e. to hold Training along with continuing community activities. Wish me luck.
That’s about it for now and I’m thankful to each of you who contributed towards this success. And I’m sure you’ll be with me in next years of this journey.
Do you have any suggestions on what kind of training we should be offering this year?
“In Pakistan, testers meet up happen rarely and if it happens, it must be appreciated. Stella Technology organized workshop named as ‘Insight into Software Security’ last Saturday i.e. Sep 23, 2017 in their Islamabad office. Main objective of workshop was to provide testers community a space to share knowledge about Software Security.
Continue reading at original post here: https://cymakarim.wordpress.com/2017/09/26/insight-into-software-security-workshop/
Every plan is perfect until the execution happens. As a losing team’s coach once said: “We had a perfect plan on the paper. The only problem is that the match was played on the ground and not on the paper”.
So should we stop striving for better planning? Of course not. Rather we should learn from each execution so that our next plan is better than the previous ones. Taking a hint from this thinking, let me share 3 tips based upon execution failures to improve your test planning.
I have selected the tips based upon 3 layers of what I’m calling Agile test planning. Such that as a Tester, you are required to do “Release Planning” or asked to do an “Iteration Planning” or asked to do an “Individual Tester Planning”.
Let’s take an example of “Release Planning” first.
Many years ago my Employer decided to start offering solutions in the Mobile world. Before that we were only in the Desktop world. Our first solution was for Android and then we worked on a Platform that can produce Apps in Android, iOS or Windows. A year or so after this has happened, I was asked to do some test planning for a release meant for a Client in China. I ‘assumed’ that they’ll need mobile solution as it was our top priority then. So my plan started with Android and then iOS testing on Simulators and Devices.
The plan looked great. Our first iteration started and by that time, I had no interaction with the Client. Client started reporting a lot of bugs and all of them were reported in Windows Desktop environment. I learned that this Client is only interested in good old Windows Desktop solution and doesn’t care about mobile.
The lesson which I learned is my tip # 1 for this blog:
Always ask question rather than assuming things
Let’s now move to “Iteration Planning”.
In a project that I was part as the lead tester, the Product Owner complained that the number of new bugs reported towards the end of Iteration is far greater than the ones reported at the start. My first response was that as more things get ready for testing towards the end, more testing is done and hence more defects were found.
Then I gave it a deep thought by looking at the history of tests we were executed. One pattern was there that certain test plans produced higher number of defects (following the heuristic that Software Bugs are like Real bugs) and the test execution order was left on the tester to pick. Tester knew that this test plan will consume lot of time and energy, so they left these to the end.
The rule that we made afterwards is my tip # 2 for this blog:
Prioritize test execution based upon which tests will fail first
This article can help you get started on Risk Based Testing.
Let’s look at the last one called “Individual tester planning”.
When I was young and raw, I had very ambitious plans for myself assuming that I’ll get all things in my favor. I planned it 8 hours a day with no distractions. Eventually I couldn’t always finish the stuff that I committed at the start of Iteration.
With age and lot of experiences, I have become more realistic about my estimates and always consider it as a 6 hours day. I also account for unknown distractions like network outage, random meeting popping up, sick days and what not. It’s not that I give a pessimistic by including all those factors but I do keep margin for some of them.
The lesson that I learned is my tip # 3 for this blog:
A plan that doesn’t incorporate change is not a plan
What tips you can offer from your execution failures to improve test planning?