Tag Archives: Information

Oct 04

Document complex test setup information

Posted on by

Testing systems which require complex and time consuming setup on the backend, initializing parameters, setting system conditions and flags, and using test tools can be challenging and fun, but often as testers we usually have a lot to cover and want to spend the majority of our time testing – which is what we should be doing.

Often in the chaos, we’re learning how and where to set up variables, conditions, flags, tools etc. to enable us to test our conditions and scenarios and observe what’s happening with the software we’re testing, while recording the results of our tests. During all of this, we often forgot to document and take note of the specific and complex setup required to test.

Sure we may remember how to set things up tomorrow, or the day after, but chances are, with the amount of things we’re testing, and the different types of test’s we’re doing, we wont remember them for long.

It may seem like there’s just not enough time to document complex test setup information, but taking some time to do so in whichever medium your project, team, or company uses, will save you and others on your team a lot of time and effort when it’s time to revisit the features. Take those fifteen minutes, you’ll be glad you did.

Dec 07

How We Deliver Information Matters

Posted on by

I work in the software business – a lot of you reading this probably do as well. I help test, develop, and deliver software applications – and a whole lot of stuff in between. As I always tell my team, other teams, and stakeholders at my company – my team of Software Testers (me included) are information service providers.

To quote Michael Bolton – we provide quality related information to our stakeholders.

I deliver information in numerous ways – in test reports, bugs reports, emails, meetings, stand ups, slack, video calls – you name it.  Note: Now keep in mind, I deliver different types of information via different means – for example I don’t report bugs in Slack.

Many years ago I realized that how I deliver testing related information really does matter! It matters in terms of how it’s received, by whom, and what types of action is taken on it. How I write something, the wording I use, and the language I use matters. How I say something, the tone I use, and the body language I show matters.

Now imagine you’re looking to buy something that you’ll use in your home, you do your research, and finally come to a decision about the item you’ll spend your hard earned money to purchase. You’ve done your homework and are convinced that this item is absolutely amazing. You place an order and a few days later your item is delivered – but the box that arrives is wet, torn, dented and in terrible shape. You open the box and find a set of instructions about your item – but the instructions are poorly written, making it incredibly difficult to understand. Furthermore your item is wrapped in plastic that is hard to remove and after all that unwrapping, you find the item has some scratches on it. Sure the item itself may still be the amazing product you had ordered a few days earlier but lets face it – you’d probably be extremely disappointed considering it’s condition and how it was delivered.

How you report bugs – what you write, the information it contains, how you write it matters. The same goes for test reports, crash logs, information logs and how you deliver this information.

If you’re the person paying for something, whether it be a product or service – how it’s delivered will matter to you and will play a big factor in determining whether you’ll want to continue paying for it. If it’s delivered and looks sloppy, rushed, and inconsistent, chances are you won’t continue using and paying for it. On the other hand, if its clean, consistent, and you can see that time and effort was taken to deliver a quality service or product to you – you’ll likely be happy and will continue your using it.

It’s something to consider when determining good practices on how you expect yourself and your team to write bug reports, test reports, provide updates at stand ups, and other status meetings.

That being said, write and advocate for bugs well, put in time and effort into how you’re presenting your test reports, status, findings, and quality related information to your audience – because it matters and can go a long way. Eventually it will become a habit – a good habit!

 

 

Nov 29

Working With Testing Partners

Posted on by

This article was originally written for the QA on Request blog and was first published here.

Working with the right testing partner is important, but working effectively and efficiently with that testing partner is just as important. It is how you’ll be able to make the most of the service being provided to you.

When working with external testing partners, keep in mind that the really good ones don’t just think of themselves as your “testing partners”; their actions should reflect it as well. They’ll regularly communicate important testing updates and results with you, and work with you to help you get the information you need. But it’s not all just on your testing partners, there are things that you can do as well to get the most value out of testing.

Additionally, when working with your test partners – each test request, information need, client, and situation is different – meaning that what you do and to what degree, to get the most out of testing, will vary.

Communicate your information needs

Clearly communicate what it is that you’re looking for from your testing partner for each of your test requests. What does this mean? Testing is an information providing service that is designed to provide you with quality related information about your product based on your needs. Are you interested in knowing about the bugs in your product so that you can focus on fixing them? Are you interested to know the state of your product so that you can make a good decision about releasing it to market? Do you want to know how your product stacks up to your competition? Do you want to know how your product will behave during daily business usage? It’s these questions that you have – your information needs, that testing will provide you with details about so that you can make good, informed decisions regarding your product. It’s also both possible and perfectly normal that at different times throughout the development of your product, your information needs will be different, so let your testing partners know what your needs from testing are at different times within your product development lifecycle.

Testing priorities

Good testing partners will work with you to prioritize areas of your product that you require information about. Take the time to work with your partners to prioritize features and areas that should be covered. Testing can be an infinite activity but budget isn’t – it’s to everybody’s advantage to focus on the highest priority areas first. Your priorities can change as well throughout the course of a longer test period.

In the case of test requests that last a longer, there may be types of important information and bugs that testing has uncovered that gives you an insight about your product that you didn’t have before. Consequently the focus of what you’d like your testing partners to work on can change as well – let them know in these cases.

High risk areas

A good tester and test team will consider what your product is, what it’s meant to do, who your user base is, and based on the answers to these questions, can begin to define the high risk areas of your application. Nonetheless, external testing partners are often not present in product development and status meetings and may not always have the most up to date business, industry, and market information as quickly as your internal team. Work with your testing partners to review high risk product areas, and to give them this insight so that they consider it in their test design.

Now perhaps you are aware that the development of the latest and newest features of your product, which you’ve asked your test partners to focus on, has likely resulted in some important and previously functional areas of your product to become unstable or nonfunctional. In this case, let your testing partners know about this now high risk area.

Platforms and devices

With the emergence and popularity of mobile devices, and the abundance of software platforms that users will expect your product to work on, and making decisions about which platforms and devices to test on have that much more significance.  Are there particular platforms and devices that you absolutely want covered during testing? Let your testing partner know. Are you interested in learning more about platform and device market share information so that you can make a good decision about which devices to cover during testing? Speak to your testing partner and let them work with you to help provide these statistics.

Features that aren’t ready to be tested

Software product development is a continuous task and a good development methodology will often incorporate testing efforts as part of the development activity. If testing in this scenario is being done by an external testing partner, keep them in the loop about what features are not yet ready to be tested, as the developers may still be working on them. This will save you the time of having to go through bugs that aren’t valid from your perspective, but may be valid from the tester’s perspective if they are not aware of features or dependent features that are not yet ready to be tested.

Specifications documents

Are there specific requirements, specifications, or user flows that are important to your business for which you have documentation? If yes, it will be a good idea to provide these details to your testing partners so that they can account for these scenarios and provide you with information and cases where they may not work as desired.

Do your specifications documents consist of hundreds of pages? Unless for some reason there is value to have your testing partners go through it all, give them the essentials they need to do their job well – which is to provide you with important information about your product so that you can make good decisions about how to proceed with it. After all, you’re paying for actual testing, not having your test partners read tons of pages that will have no value or impact on testing, and will only eat up your testing budget. Keep in mind, each situation is different so consider your needs and what works in each particular situation.

To wrap it up

These are a few tips you can apply to improve the working relationship you have with your testing partners so that you are able to get the most of your testing budget with the information that testing will uncover about your product. Your testing partner is not just there to find bugs in your product, they should be a valuable member and contributor to your team, and help you quickly find bugs and other important things that matter the most to you.

Aug 16

Interview Basics

Posted on by

During the past few years in some of my respective roles, I have been part of the hiring process. I’ve helped define the the companies needs for test roles, identified skills and experience we’re looking for, reviewed candidates’ profiles, interviewed potential candidates, and have spoken to their references.

I’ve had candidates who’ve come prepared and done well, and on the other end of the spectrum, I’ve had candidates who’ve came to the interview extremely unprepared wasting both my time and theirs. It shouldn’t come as a surprise that they didn’t do well or get the job. There are some basics to an interview that I would’ve thought to be obvious to everybody, but in my experience they aren’t. Below I’ve listed a few basics things that anybody interviewing for a job should come prepared for and with.

Research the company

This is so basic yet I’ve had some candidates who’ve come into the interview not knowing anything about what we do. If you’re answer to the commonly asked question “what do you know about us?” is “not much”, you’ve crossed yourself off the list of potential hires. For me personally, when somebody answers the question in that manner, the interview is over. It would take a lot for the person to catch my attention and interest, and make me want to hire them after answering like that – it hasn’t happened so far. Visit the company website, check out their Twitter account, their LinkedIn profile – find out what they do, what and who their business is, and what their clients are saying about them.

Know what’s on your resume

Numerous times now I’ve asked candidates regarding something specific from their resume, whether it be a tool or technology they’ve listed, an experience with a particular project, or some form of education they’ve listed, and they seem dumbfounded by my question and are unable to answer it. It’s important to be aware of what you’ve written in your resume, people read it and will want to know more.

Bring a portfolio

I’m always puzzled when somebody comes in for an interview completely empty handed as if they just strolled in for a casual chat. I highly suggest you bring a portfolio with the following: a pen, a paper to take notes, a copy of your resume, and anything else that may be relevant for the interview.

Ask questions and take notes

It’s important to come prepared with questions for things that matter to you. When a candidate doesn’t come prepared with any questions and doesn’t think of any during our discussion, it makes me wonder whether they are really interested in working at the company and being a successful part of it, or if the person is just looking for paycheque. You’ll be spending approximately one third of your day at the office with the team, five days a week – don’t you want to know more about the work you’ll be doing, how you’ll be doing it and whom you’ll be doing it with? Some of the questions may get answered at different points of the interview – so prepare more than just a few. Also take notes. There is a lot of information, topics, and details discussed during an interview and chances are you won’t remember them all. You’ll need these notes so that you can review them once the interview is done, and if you’re offered the job, there are things you’ll want to keep in mind and consider.

Dress well

As the saying goes “Dress for the job you want, not the job you have”. You don’t want to come in looking like you were just called into the office for a chat while taking an afternoon stroll. I won’t write much more about this as I feel that it’s a given (not to mention common sense).

Answer questions like a real human

What do I mean by this? There is a lot of information about the type of questions and how to answer them on the internet. There is nothing wrong with reading up on this in an effort to help you prepare. I actually encourage it, but don’t memorize and practice answering questions with “typical” or “standard” answers you read on the internet. I can’t speak for all interviewers, but I like to hear real answers from real humans based on their experiences, their knowledge, and their skills. I like honesty, and originality in responses – it makes for a much more interesting and informative discussion for both parties. Don’t tell the interviewer what you think they want to hear, tell them from your perspective and in your words what your answer to the question is and feel free to explain why.

Practice and learn about interviews

Read up on interviewing well, practice, understand the different types of questions that can be asked during an interview. It takes time and practice to become really good at being interviewed. You may not do great at every single interview as there are a lot of factors at play during an interview, only a handful of which you can control, but that doesn’t mean you won’t learn from each and every one and if the lessons you learn are applied well, it will only make you better. The more you learn and understand about interviews and questions, the better at them you will get. There is a lot of good information out there!

 

Mar 23

I Don’t Need Explicit Written Requirements to Test

Posted on by

I’ve been in Software Testing and Quality for almost 10 years now, and a disturbing trend I tend to hear every now and then, are individuals on the test team complaining and whining that they are unable to test because there aren’t any written requirements available.  I’ve seen these same individuals refuse to begin any testing effort (not even willing to launch the system) without having the written requirements in front of them, and waiting for somebody to produce these requirements before even launching the system, not realizing the valuable time they’ve just wasted, time that could have been used to test.  Of course, I believe a big part of this approach and expectation could be due to their uninformed belief of what software testing (and their job) really is – but more on that later.

Even before I practiced and got better at approaching situations where I was asked to test and told there were no written requirements, I believed in getting the information I needed in order to test.  In the last few years I’ve began referring to it as “information hunting”.  This information could be anything relevant to the situation at hand, from the manner in which to access the system under test, to who the end users of the system will be.

If I find myself in a situation where there are no written requirements, I am going to go “information hunting” to find out more about the project and testing situation I am in.  If I find myself in a situation where there are written requirements, I’ll be sure to read & analyze them and I will also go “information hunting”.  You see, there is SO MUCH more to software testing than just the requirements. I’ve seen many systems in the past, with tons of written requirements and numerous test cases mapped to each of the requirements, yet when I actually used the system myself and tested it – it was less than positive experience using the system and there were many problems present, despite of all those test cases that had been mapped to each of the requirements and “passed” by whomever was assigned to run the tests.

Now going back to what and how some people on test teams view their role and job – some people just don’t see software testing as anything more than validating the requirements – but that’s not software testing.  Software testing is about providing important information about the quality of the system under test.  One of the many things I’ve learned from Michael Bolton is that you don’t need explicit written requirements in order to launch a system and begin to question it, observe its behavior and learn about it – so that you’re to provide important information about the quality of the system you are testing.  This is such a huge part of Software Testing that I believe is missing on many software test teams – the understanding and appreciation of the skills required to be a valuable software tester, the use of the brain, and actually thinking while interacting with the system under test.

When I go “information hunting” I want to learn and get more information about the current test situation (every test situation is different) that I find myself in.  I carefully put together and analyze all of the information I am able to gather about the testing needs and the system, so that I can create and share my test approach with my managers and project stakeholders – and carry out good testing.

I like to find out the reasoning justifying the cost behind the development effort.  What are the information needs of my stakeholders for this specific test effort at this specific time?  What is the purpose of the system and what are the goals that the system is setting out to accomplish?  Who will be the end users of the system?  How will the users use the system?  Why will they use the system?  What will they use the system for?  When will they use it?   Who are the developers with whom I will be collaborating with and can/will they answer my questions about technical changes and possible impacts to consider in my test approach?  Who can I work with to discuss the risks?  Who can I work with to discuss security and performance expectations?  Which other systems and components will be impacted?  There is more information I may look to seek out depending on the specific situation and circumstances surrounding the system under test (for example test environments, remote team members, third-party involvement).

Using the information I hunt down, I am able to think about the system and how I am going to approach my assignment of testing it.  The answers to my “information hunting” questions have a direct impact of what I test and how.  I am always thinking when I test, while I observe my interactions with the system, and the behaviours I observe within it.

Within the past few years I have also studied and learned different test skills, the use of judgement, oracles, and heuristics and to incorporate them into my testing, in order to help me find and report important quality related information.

I don’t need explicit written requirements to start testing, nor do I heavily rely on them in order to do my job well and to be a valuable contributor to the team.