What are some of the biggest changes you notice in IT industry today from how things used to be when you started working in IT?
I would say some of the biggest changes in the IT industry revolve around the cloud, virtualization, and outsourcing. When I first started in IT, these were all things that were completely out of the picture. These days it’s very common for support to be outsourced to other countries, and for businesses to place their IT infrastructure in the cloud. A big part of all of this is virtualization which has enabled businesses to easily consolidate their IT infrastructure into the cloud.
Quality – what is your definition or understanding?
Quality to me, is the ability to provide a product or service to a customer that not only meets their expectations but exceeds it in features, reliability, and support.
What is one technology that you adopted in 2010/2011 that you love? Would it be hard for you to give it up?
The iPhone 4. I use to be an avid BlackBerry user. I’ve been using them since the very first one came out. I have owned every single model of BlackBerry out there. But once I bought an iPhone 4, I never looked back. It’s amazing how it completely changed the way I work. It is just so easy to use, and makes my work day go that much smoother. I don’t think I could ever give it up, except maybe for an iPhone 5.
Raj is the Director of Technical Services and a senior solutions architect for EPIC Information Solutions (http://www.epic.ca) a local IT consulting firm here in Canada. EPIC is the largest Manitoba owned IT consulting company in the province of Manitoba. He is regularly engaged in projects for deploying Cisco and HP based networks, Windows based operating systems, and server products such as Exchange and SQL. He chiefly deals with Cisco, Watchguard and SonicWall firewalls, Cisco and HP switches and other HP hardware including HP Blade servers and SANs. He is also regularly engaged in VMware implementations. Some of the certifications he holds are a Cisco CCNP and CCNA in routing and switching, VMware VCP 3 & 4, Microsoft MCSE and MCT(trainer), and Citrix CCA. He is working towards his CCIE in routing and switching and in addition to this, he manages a large department of engineers. He is regularly engaged in infrastructure engagements in both the SMB and enterprise markets in almost every vertical. He has been in the IT industry for over 15 years.
Some Tips for presenting data
- Use a Microsoft Word document or an Excel worksheet, or develop a good template that works and stick to it.
- Keep it simple. This will help gather accurate data. Identify what metrics you really need to gather first: start small, make improvements and then expand from there but always keep it simple.
- Share information with your test team so they know the data points that are important for gathering metrics.
- It’s good to remind management that the data is a snap shot of when the data is gathered and that it can change. This is really based on what is known as of that day or week. If things change then the numbers change and sometimes it could be drastic.
- Make sure the project team understands the assumptions that are made. It will be hard for the team to understand the numbers without understanding how it was gathered.
- Trust and understanding are not built in one day so be constructive and don’t point fingers “we’re all in this together and we want to make things better for all of us.” The leads have to constantly communicate with the team to build this relationship where their metrics are used to make decisions that impact the organization as a whole. Credibility for the lead and testing team has to be created with data that should or can drive decision making.
- The examples stated above are just examples and can be modified to suit different projects. There is not one set that will always work; based on the need of the project, they have to be tweaked and changed.
- Always compare apples to apples. For example, if there are 100 test cases and its being used in a report, they have to be of similar value (complexity, time taken to execute them, etc. If they are not similar, then break them down into smaller categories by complexity or other criteria).
- Know the data. Unless you know the data you cannot predict or interpret data. You have to be able to identify drastic changes and then question them. Are there really 50 new defects for an old build or did someone pick the wrong value for “build found in.”
- Communication is the key when sending metrics to the team. Bring it up as often as possible in meetings; refer to metrics when having discussions or post audit for projects. Sell your metrics so that eventually people will look at it as important information for making decisions. Starting out, show the value in work by identifying how the metrics will make improvements and then, after the next effort, show that they did or show what didn’t happen, and identify what further steps are needed for quality.,
- Slice and dice data in several ways to show the same data. This will help project team and management understand the data better and what to do with it.
If you would like to recommend someone to be interviewed in this series please email their name or leave a comment here in this thread. I would like to hear who the community would like to hear from.
Also if you have recommendations for questions to be asked please email them to me.
As a leader once in a while we have to step back and look at our team be it our project or department. Where are we going as a team, where are we today as a team and what are some problems the team might be facing. How best to gather this information. There are several ways to do this… talk to each team member, or do a survey, etc. Another great tool that we don’t use enough is round table meetings.
theFreedictionary defines Round-table as a meeting of peers for discussion and exchange of views.
Its really a place for the team to come together and discuss topics and communicate. Its an open forum where we are not generally trying to find solutions or solve problems. Action items can be taken if necessary for future purposes or you can create a parking lot list to add items that you as a leader/manager may want to get more clarifications on. This meeting should be considered as a place where people can bring topics related to everyday work, industry trend related questions.
What are some benefits of this meeting?
- You can get your team to talk to each other. A time which is not related to day to day deliverable but a forum that can be used to talk about things they want to talk about.
- Brainstorming and a place to thrown new ideas and get feedback. If people have new ideas this would be the place to encourage them to talk and get feedback from. This forum may even help them refine the ideas and help implement them.
- Gives a chance to the team to vent. Sometimes just talking helps.
- Give a forum to discuss best practises, review existing processes and talk about process improvements. This wont be the place where actions are taken but it would be a place to start talking about areas that needs changes.
How to organize a good round table discussion?
- As a moderator or organizer always have some topics to start the discussion going. You can gather this from your team ahead of time or you can talk about a topic that is hot or current with your team.
- See if someone volunteers to share topics or present a topic/idea.
- Make sure people understand the purpose of the round table.
- Give everyone a chance to talk. Moderators might have to see that everyone gets a chance and that one or two people shouldn’t dominate the discussions every time.
Post Meeting follow up
Always send notes after the meeting and if there are items you want to follow up make sure you do it before the next round table. Also if you want them to sign up to talk then use this meeting to gather that information instead of sending multiple emails.
Anyone who has been in testing long has at least had, heard or participated in this debate. Debate around what QA is or what QC is? Who is better? There is a whole section dedicated to this in CSTE CBOK.
Anyways I work for a department where we are called QC (Quality Control) and did jobs that were related to QC. We were recently asked to do QA work. There are lots of definitions out there for QC and QA and I will not try to get into those right now.
What I am really enthusiastic about is getting to use both sides of this definition at my work. I know prevention and detection are both important. No matter whether we get good at QC or QA I consider them as tools. The goal in the end is that customers get a defect free product (well at least as much as we can catch before it gets to the customer). For this I am ready to do a QA or QC job. After all when I became a tester my oath was to deliver good products to the customer and I will use as many tools as I can to achieve this. I will look for solutions where problems exist and the answer can come from QA or QC or a mix or processes.
With this I say bring it on and I will be ready with my tool belt.
* What are some lessons you have learned about software testing that you wish you had known long ago or you wish someone had told you about?
I can’t think of any “harsh lessons” but there are things I’d recommend to the younger version of myself if that be possible. Some of these would be about developing certain personal habits, other about trendy tools and technologies.
* Name your favourite book on Software Testing?
“Testing Computer Software” and “Lessons Learned in Software Testing” were the first books I read about my profession. I would recommend reading them to someone who previously did not but my favourite approach is heuristic learning. I prefer to build up knowledge on my own – this way it becomes a part of me.
* Who is your hero?
Applicably to our profession, I really like James Bach’s definition: “A hero is someone who, for the general good, takes initiative to solve ambiguous problems”. (Online reference: http://www.satisfice.com/presentations/why_software_projects_need_heroes.pdf)
Thus, anyone could be a hero and worth praise, recognition, and learning from.
Yet professional tester is a special type of hero who resembles many qualities of Odysseus, the hero from ancient Greek mythology, praised for his cunning intelligence. While being skilled swordsman and archer, Odysseus is most known for his influential powers. He was man of the mean and courage, and a skilled diplomat. He developed and applied in practice many tricks and stratagems including all-known Trojan Horse.
And such should be a modern tester hero – an all-round professional, sharp-minded, avid learner, problem-solver, systems thinker, capable to communicate effectively in all levels.
* What do you do when you are not working?
Work on something else?
For about 27-30 years my biggest hobby has been angling fishing. I also love reading and spending time with my family. I’m a member of online testing community, and I quite regularly write in my blog.
* What is a skill or strength that sets you apart from others?
I had many projects working independently but most of all I enjoyed collaboration in a strong group. I lead by example. I’m passionate of what I do and I’m always striving to excel. This is what, I believe, rather brings me in than sets apart.
* What (or who) inspires you?
I’m self-driven. I’m motivated by challenges and energized by learning from both successes and mistakes.
* How can non-technical people pick up the necessary knowledge they need to be more technical? What would you recommend – classes, hands-on learning, go back to school, etc?
What’s technical? Using TV remote is technical or not? Driving a car is technical or not? Browsing the Internet is technical or not? We need to establish what this “technical knowledge” is necessary for.
We also need to keep in mind that (post-graduate) education is a business, and as any business it uses any means to increase the sales as a first priority. The need of “technical education” might be overemphasized.
On the other hand, in our industry (IT) it’s all about technologies that continuously evolve. If someone feels far behind, taking classes might be a good idea. To keep up and grow professionally I’d recommend heuristic learning (hands-on learning is a big part of it) and collaboration. Weekend Testing movement is a good example of successful implementation of such an approach.
* Tell us about how you got into testing and what is it that keeps you here in this industry?
Early in my career I worked mostly in start-up environments that didn’t have so strict division of roles, so I enjoyed both programming and testing.
Nowadays, I typically work in large-scale projects and with N-tier applications. While as a programmer I’d have to code just some modules, meaningless without the context, as a tester I see the big picture and I explore the product. Such testing is a much bigger thinking and problem-solving challenge, and that’s what I like.
I also quite recently felt in love with heuristic-based testing approach, especially with reverse-engineering testing heuristics taught by James Bach and Michael Bolton. My goal is to become a master in that.
* Any advice for new or young testers?
Do not ossify. Treat testing as a craft and never ending adventure. Look around and beyond your job environment; learn from other testers. Online gives great opportunities for that.
* Quality – what is your definition or understanding?
In testing, I’d stick to Jerry Weinberg’s definition. Generally I use it in the meaning of an attribute or a property. In such notion quality might have either negative or positive meaning.
Albert Gareev is a passionate software engineer who fell in love with testing and test automation and applies his knowledge to make the testing world a better place. He considers himself as part of Context-Driven Testing Approach Community. You can connect with him on LinkedIn, or his email firstname.lastname@example.org, or via twitter @AGareev. He shares his experience and journey at Automation Beyond.
* You were a software engineer before moving to testing. Did that hurt or help your career?
I still consider myself a software engineer. More to say, the headline of my blog (http://automation-beyond.com/) reads: “An engineering approach to Software Testing and Test Automation”. I’m aware of modern critiques of technical education, and seems like title “engineer” doesn’t sound so proud anymore. But let’s stay reminded: “engineer” is derived from the Latin root “ingenium”, meaning “cleverness”.
I have a solid programming background and I still enjoy coding. However, in testing I use it as one of problem-solving tools in my arsenal. Ability to read and write code is important but not critical.
I think I see in what context you meant “did that hurt”. Yes, shaping mindset into a procedure-thinking mode would be rather damaging, and not only for a career in testing. Remember the old anecdote about programmer who was stuck endlessly washing his head because instructions on the shampoo bottle stated: lather; rinse; repeat?
* Personal growth and continuous learning – how important is this in our times?
I certainly consider it extremely important for myself, and I promote it in my family and in my environment.
* Did you adopt testing or did testing adopt you?
By now, I certainly have warmer feelings towards testing, rather than programming. Speaking of adoption, I can’t help but note about automation, which is often treated as a result of extramarital affair between testing and programming.
A fellow ITKE member asked
Is Functional Testing (User acceptance tests (business transaction flows), +ve input tests, -ve input tests) sufficient to determine the Code Coverage? Do we see any additional coverage when we do non-functional testing (example: load testing with the same inputs used in functional testing)? If so, How?
In testing when we refer to code coverage we are talking about how much of the code is being covered/executed/tested during test execution. So the goal behind code coverage is to determine areas that are not being tested and creating tests that can cover these gaps. Structural and functional testing can be used to determine code coverage. Code coverage is a form of white box testing where one looks at the code directly. A mix of white and black box testing is necessary to get maximum coverage. Just functional testing is not enough to do code coverage. There are some code that do not get executed from the front end or UI testing. There are codes in place for recovery, back up, load balancing, etc that have to be covered in non-functional testing.
Here is a link to some information related to code coverage
A trial tool for code coverage analysis