Get the right tools for the job.
Everyone in software testing knows what a challenge this job is. That’s what makes it so interesting! But in order to stay on board we need to constantly learn, and to create our own ways of dealing with day-to-day tasks. From conversations with my colleagues and from reading articles online I know that everyone has his (or her) own tricks. I thought I’d share mine. For me it isn’t complicated, it is simply a matter of having the knowledge and tools that help me do uninteresting tasks faster and more efficiently, and to be creative with the interesting ones. As a by-product it also often means that what might initially seem like an uninteresting task can turn out to actually be a fascinating one instead.
I won’t talk about personal traits here, such as curiosity, analytical mind-set or the ability to learn fast. Instead I want to concentrate on the actual knowledge (facts, data, information) and applied knowledge a.k.a., skills that help me to do my job better. I’m not saying they are must-haves for everybody, and I’m not saying this is a complete set! But this list works for me, and maybe it will give you some ideas on how to enhance your own skillset. So, as a wise timelord has said more than once, allons-y!
Let’s start with IT related technical knowledge.
1) Programming Stuff
Programming languages, data types, search and sorting algorithms – this knowledge helps me to understand how the application is written, what constraints are there, what problems are to be expected, and what problems are extremely rare. Examples include buffer overflow, index out of range or memory leaks – problems that are closely related not to business logic, but to the architectural implementation choices of the application designers. Also, knowledge of a programming language like Java for example is necessary to create effective and powerful automated tests, but that’s kind of obvious. Keep in mind that you don’t have to be a brilliant software developer to take advantage of this knowledge. Even the basics can help a lot.
Tips and links:
- Read O’Reily’s “C++ pocket reference”
- Take any introductory course in programming. There are lots of great free courses online. I recommend Stanford’s “Programming methodology” and Princeton’s “Algorithms”.
2) Environment Stuff, and I don’t mean grand Mother Nature:
Knowledge of weak points, quirks and special features of different operation systems can save lots of time and help you search for bugs where you know they might appear instead of relying on dumb luck. This is especially true for mobile OS’s since they are updated frequently, and some methods used e.g. in Android 2.21 are deprecated in Android 4.0 and thus can cause an application to crash or worse.
Tips and links:
- Keep an eye on the main site for developers for the platform your application works on – Microsoft’s MSDN, developer.android.com, etc.
- Ask your developers! They usually know this stuff since they have to find workarounds for it.
- Keep a list of peculiar platform related bugs and revisit it from time to time to update it and get ideas for future tests.
3) Software Design Stuff:
UML is helpful both for reading design documentation and for creating test models. Modelling software under test using diagrams can be a fast, precise and easy way to describe functionality. I use it all the time when I plan the testing of a complicated or high-risk feature. Also, mind-maps are helpful e.g. for the design of test cases or when recapping a scrum meeting.
Tips and links:
- FreeMind is a nice cross-platform Java application for creating mind maps.
- Try different kinds of diagrams in an online tool – e.g. https://www.draw.io.
- Try sequence diagrams, they are awesome. Here is an online tool that renders diagrams automatically from a script you write using a simple language.
4) GUI Design Stuff:
Platform guidelines, general GUI guidelines – as you can probably guess, they help to find GUI bugs. Even if there is a special design team in your company, it may sometimes be the case that designer is not a specialist in your exact platform, so it’s your responsibility to test against platform guidelines. For example, some of the standard interface controls look completely different in android 2.2, 4.1 and 4.2.
Tips and links:
- Find out what GUI guidelines are there for your OS. Ask developers and fellow testers, or search for it on the web (e.g. “iOS guidelines”).
- Keep in mind that the GUI isn’t only about visuals, it’s also about the logic of the interface: how commands are named in the menu, how the application reacts to standard buttons, how windows/activities/dialogs affect each other etc.
- Read books on GUI design in general: e.g. “Designing and Engineering Time: The Psychology of Time Perception in Software” by Steven C. Seow or “Don’t Make Me Think! A Common Sense Approach to Web Usability” by Steve Krug.
5) HTML, XML + XSLT, SQL and Regex
These are things that enable me to do more quick and thorough testing of applications where I can directly manipulate raw data or see server responses. XSLT is a simple and powerful tool to automatically extract data from XML or HTML files, and so is regex (works with any type of textual information). You can also generate test data using regex (though I haven’t done it in years, so no examples, sorry. You can easily search for it when in need). At least basic knowledge of SQL is vital for testing any application that directly uses a database. SQL and HTML enable me to do basic security testing (SQL injections, XSS – you should at least check that “<a href=www.ministryoftesting.com>url</a>” is not interpreted as a URL, or your application is doomed).
Tips and links:
- Try Perl. Regular expressions are practically built-in and you can search online guides easily enough. And it’s always nice to know Perl at least at some basic level, which is enough to write some regular expressions.
- Get familiar with DOM and with the differences between HTML and raw XML. Helps in automation too.
- If you test Android applications, learn to use Drozer.
- Google some examples of SQL and XSS injections and keep a list – this way you can always easily and quickly do some basic security testing of a field even if you don’t know SQL or Java Script that well.
6) Terminal/Console Stuff:
IMHO, Linux and Windows console commands are a must-know for any tester. You’ll need them if you test a web application, or a mobile application with a server part, or any Android/Bada application (to get logs or screenshots and to reinstall packages), or a desktop Java application, or any Linux application, or any server-side application… Well, you’ll just need them. It’s a thing to accept and enjoy! As a bonus, you can do basic scripting in text mode, running applications with parameters and getting results into text files to inspect later. And in a good console application with a history of commands it’s often more efficient to use text commands than to click buttons in the GUI.
Tips and links:
- Learn basic Linux and Windows commands. Just search for something like “shell scripting” and choose any link.
- Install Putty and learn to use it. This is a simple though powerful tool to login to any server you have access to via SSH. The package also includes tools to move files from your computer to the server and back.
7) Risk Analysis:
When I plan testing, whether it is a long term plan or a quicker one for a single test session, I try to keep in mind the risks involved with the features under test. It helps me to prioritise my time and efforts and to give quick feedback for the most risky parts of functionality. My knowledge of risk analysis originates from Rex Black’s book (which I never finished – the first few parts were enough to grab the idea) and practice. I highly recommend everyone who doesn’t know about risk analysis to educate himself on the subject.
8) Heuristics:
When I don’t know which tests to run, I use CRUD, or HICCUPS, or the Heuristic Test Model (by James Bach), or some other idea generator that I know how to use but don’t remember how to name. When I forget what these names stand for, I go to Google or to Satisfice.com and refresh my memory, usually getting new ideas on the way. Tester’s guts and requirements analysis are great things, but knowledge of testing heuristics can greatly widen your approach and coverage.
Tips and links:
- Satisfice.com, of course. If you’ve never been there, you are up for a wonderful journey.
- “Lessons Learned in Software Testing” – a great book, that amongst lots of other things also talks about heuristics at various points. At least I think so. Well, it is a great book any way!
- Find testers’ blogs you enjoy reading, and enjoy! Communication with fellow testers is a great source of ideas even if nobody talks directly about heuristics. These are some of my favourite blogs to get you started:
Bear in mind, these are just tools, not some sacred cows. Some of them you may love, some of them you may hate, and some of them would probably look like a waste of time to you. For me it seems reasonable to select and adapt any tools you like to help you on the job, not to adapt yourself to some tools somebody once said are good. After all, tools don’t make us who we are as professionals. What they do is they help us spend less time on mundane tasks so that we can take advantage of our minds – the most powerful tool there is – to its fullest.
Do you have any thoughts/ideas/objections? Please do share! This is my first attempt in eight years to write down in a structured way what I do and what I use while testing, so I probably missed a lot.
About the Author
Viktoriia Kuznetcova is a Russian tester soon to relocate to New Zealand and start afresh there. She currently works as a software tester for mobile applications at Yandex, a major Google competitor in Russia. During her nine years in IT Viktoriia tried roles of a manual tester, an automation tester, a test lead and a product manager. She is a strong supporter and a practitioner of exploratory testing.
You can follow her on Google+ or on twitter (@miss_hali).
The post Tools for Everyday Testing – Part 1 appeared first on Ministry of Testing.
