Nicky Tests Software

So I just went to the 2nd WeTest Auckland Meetup at the Assurity office. I really enjoyed it. Let's break it down shall we? What is this WeTest Auckland you speak of? The idea stemmed from the fact that there's a similar Meetup in Wellington called WeTest.  It starts off with a 15min(ish) experience report then a facilitated discussion.

Last week, I was asked to teach someone how to write test cases. I was up for the challenge. Well, I'll be honest with you - it wasn't exactly a challenge. The guy I taught was a fast learner and had great written communication skills. And I must say, this experience taught me a lot how about how to get your point across and how people learn. I've always been a big believer in learning by doing. That's why I was a avid fan of doing past exams to prepare for the finals at uni. And that's why I prefer having access to a Test Environment as opposed to just having to survive with Design Specs. It's amazing how much you can learn by playing around with something - then seeing what happens.

Breaking Bad Communication Habits I'm sorry. I couldn't help myself. I just had to use an awesome pun to start off this blog post :) My boyfriend and I literally laughed out loud when I read the title of this blog post out loud. And yes, I'm one of those people who are usually the first person to laugh at their own jokes.. no shame.. no shame. I've become an avid fan of the show and I'm pretty gutted to see it end. But hey, I admire the fact they quit while they're ahead instead of milking it for all it's worth. Anywho, let's get down to business. Lately, I've been thinking a lot about communication skills. I mean, I'm pretty sure a high proportion of people believe they have 'good' or 'solid' written and verbal communication skills. But how many people actually do?

Recently, I started on a new project. It's interesting. And I'm very excited about the Foosball table on-site (Note: This is possibly a massive understatement.) Anywho, I floated the idea of mind-maps past my team, they liked it - so now we're using Mindmeister. You see, I'm pretty excited. I wanted to use mind-maps in my last project, but since the rest of my team couldn't gain access to the mind-mapping tool (I was working remotely), we thought we'd skip the idea. It's working out well so far, we've all got access to it and are currently brainstorming how exactly we're going to test the sexy piece of software we have in front of us. I particularly like the part where you start out an idea, maybe expand it into a few branches, then just leave it for a bit as you let your brain process the information.... you then log back into Mindmeister a few hours later, lo and behold, someone in your team has really helped developed your testing ideas. You, t

When I started software testing, I was under the impression that all defects that were found before going live, were fixed. Bar some aesthetic ones which could wait a few days after go-live. You see, I'm really now only starting to grasp the concept of time, priority, resourcing and acceptable risk. It appears that usually because of one of the aforementioned factors; a bug that I reported just continues to exist in the software and contribute to the statistics in a defect report until it is viable to fix it. Now, in raising a defect, I do my best to provide as much information as possible for them to not only fix their defect but also make a decision on whether or not it is worth fixing; and if so - when. And here's a rough outline of what I include: Defect Name Priority Severity Environment Found in Steps to Replicate Description of What's happening Affected Tests Creation Date/ Due Date Build Found in But part of me wonders if that is enough for them to m

In about three and a half weeks time, the first Auckland WeTest will take place. I'm really looking forward to it and having the hard work of Shirley, Jen, Erin and I pay off. Now here's a bullet point summary of why I'm looking forward to this event: a) Reaping what we have sown I'm keen to see it actually happen. When you're planning an event, it's simply an idea in your head that you're shaping to become a reality - but when it's actually happening; then that's another thing altogether. b) Meeting people from different backgrounds and different approaches to testing Our event will give ample opportunities for discussion and to offer your opinion. I'm looking forward to hearing what people have to say; especially those I do not agree with. I want to learn how and why people approach testing in different ways. From this event, I hope to have a better idea of the other testing approaches that are common/popular in Auckland, bas

Aaron Hodder  is an experienced and passionate context-driven tester. Before joining Assurity, Aaron worked at Metra Weather as a Test Analyst for the Weatherscape XT product, a weather graphics presentation system used by TV stations nationwide. Aaron is active in the testing community, having co-founded WeTest , attending the peer conference KWST  and presenting at STANZ on using Lean Visual methods to plan and report on testing activities. Aaron will be giving a presentation at CAST 2013 on Mind Maps - A practical, lean, visual tool for test planning and reporting

Realistically, quality means different things to different people. It depends on the situation. And the context. But in  many cases, it cannot be denied if the product is of an extremely high quality. What one person judges as being of high quality, another may deem it has low quality. Meanwhile Quality can be dictated by a piece of paper which clearly defines it. So yes, I do believe that quality is both subjective and objective.

So, I'm currently in the USA. More specifically: Oregon. Beautiful state - I'm taking tonnes of photos. Only wish I had one of those fancy cameras so that the beauty of what I see, really does come across in an actual photo. Anywho. A weird thing seemed to happen when I was transferring money over by Internet Banking with BNZ and I'd be keen to hear from anyone who has experienced the same thing (or something similar) due to time differences between countries.

Oh yeah, it's test execution time on my current project. Bow chika wow wow. Time to run test cases which I wrote a few weeks ago. Where else is this behaviour occurring? How does it affect other parts of the system? How have my expectations changed based on seeing how the system actually works? Is it normal for people to add test cases during test execution so that as ideas come to their head as the execute tests, the new test case ideas will be included in reporting? If 1. is the case, then what fraction/percentage of test cases ideas arise from actual test execution? Don't get me wrong, I make sure I do some exploratory testing to see what happens then record my findings/raise a defect if need be.  But then since these test case ideas aren't 'formally covered' in test cases it makes me wonder about reporting if they only look at defects and test cases run/passed. I started a discussion in Software Testing Club asking: What do you think

So an activity I like to do in my free-time is play games on the computer. Truth be told, I do go through phases where sometimes I stay up 'til 2am, then later I won't play a single game for 3 months. But yes, I do enjoy it - and I recognise it as a fabulous form of escapism. Now, I just finished playing Bioshock Infinite. This was followed by about an hour of Google Searching what the hell the ending meant. I had to read the plot on Bioshock's wiki at least twice for anything to properly sink in.

So today I'm writing Part II. Even though it's no longer July 2 in New Zealand, it still is in Europe and the USA. So I'm gonna roll with it and continue going into what I've learned in my first year.

My oh my does time fly! Today is my 1 year anniversary with Assurity as a Test Analyst and boy have I learned a LOT in my first year. I've been surrounded by some amazing, talented, supportive, on-to-it people at this company and grateful for the opportunity that has been provided. Anywho. Here's a quick run-down of what I learned.

Michael Larsen retired from a career as a rock and roll singer to pursue software testing full time at Cisco Systems in 1992. Larsen has worked for/with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. For the better part of his career spanning 18 years, Larsen has found himself in the role of being the "Army of One" or "The Lone Tester" more often than not. This unique view point, along with ideas and advocacy regarding continuous education and learning/re-learning for testers, is frequently the grist of the mill for TESTHEAD

To start with, I think getting feedback as a Software Tester is very important. In general, I think it's great to solicit feedback to see what you're doing well, what you're not doing so well and what you could just stop doing altogether. A man from our office gave us a presentation on personal radars and how to be awesomer, then asked specifically for feedback after the presentation and then again in an email the next day- thanking us for our time. Good stuff. No ambiguity involved. If there was anything that I think he could've done better, I had a green light to let him know. And what he did well? I made sure to tell him what I thought regarding that too. And you know what?! I did it Toastmaster Stylz! That's right. The CRC approach- Commendation, Recommendation, Commendation.

Questions I ask myself when Testing Software So I'm working on a project, am given a project brief and then find some questions floating in my head. Now aside from the obvious where I want to help detect any bugs before the system goes live I also find myself thinking the following things.... What's the point of this new system? OK so we would've already been told this. But really, in simple-man's terms - what the point of this new piece of software? How does this add value to the users/business etc?

To be honest, I don't have a whole lot to say  Just smile and read :)

How would I Promote the Software Testing profession? I ask myself this so that I can try and explore how I would go about promoting Testing as a Profession. To see how this came about, go here Now, I have a theory and I do think it's fairly plausible so bear with me :) You know despite the fact a lot of people seem to end up in careers that are not only unrelated to their education (whether that be teritary, polytech etc), I also think a lot of people end up doing something 40 hours a week- that they had not heard of as a career in high school. Or scratch that- even university! Therefore, I propose a national Software Testing Competition for high school students and a separate competition for those in Tertiary study.  In New Zealand there are similar competitions for Maths, English, Science, Economics and Debating (sponsored by a law firm)- so why not do the same with testing? It'd be a great way to get the word out there of software testing existing as a

Nadine is responsible for Assurity's HR, recruitment and graduate recruitment. She plays a key role in helping to drive the company into its next stage of growth. Her strong background in IT recruitment - she worked as HR Manager at Intergen for three years - gives her the knowledge and know-how to recruit the best people in New Zealand

Hope you guys liked my previous blog post on tips for the ISTQB exam :) I got some great feedback on LinkedIn when I posted it on a discussion there that I thought I'd follow it up with a few more tips and Part 1 of explanations of some sample ISTQB Questions. (Source: http://www.istqb.org/downloads/viewcategory/41.html ) More Useful Tips for the ISTQB Foundation Exam Process of Elimination As the ISTQB Foundation Exam is multi-choice, process of elimination is a pretty good idea. The good thing is you can get rid of the trash quickly and then focus on the 'realistic' possible answers when you read the question or when you come back to it later Highlight the key words Especially words like "not" and "most" that change the entire meaning of the sentence but can be easy to miss. Watch out for questions that contain the word "MOST" I'd like to draw attention to this because chances are all of the options will be correct if yo

Markus Gaertner has been a software tester since 2006 and is located in Germany. Personally committed to Agile methods, he believes in continuous improvement in software testing through skills. Occasionally he presents on Agile and testing related conferences. He is a black-belt tester and instructor in the Miagi-Do school of software testing, and a co-founder of the European chapter of Weekend Testing.

Software Testing - The Hidden Profession After working at Assurity for a few months, I decided to catch up with some friends in Auckland. Given that most of my friends have left uni in the past few years; it’s safe to say that our lifestyles have changed; and a major topic that would arise would be what we’re doing with ourselves these days. That is, what exactly are we doing 40 hours a week? The other person would start it off and go into how they’re enjoying their job as a lawyer/accountant/marketing co-ordinator. I’d ask about what their typical day is like; do they miss uni (and everything that came with it such as lectures and exams); do I know anyone who works at their company; and so on and so forth. And then it would be my turn. I’d say I’m working as a Test Analyst with Assurity Consulting Ltd. I would then be faced with a blank look. “So do you write code?” No, not exactly. But some people in Testing do need that skill. I suppose you could say we want to

What is the difference between Path Coverage and Branch Coverage? (ISTQB) To explain this I’m going to do 2 things. First I’m going to use an analogy to try and make this situation more ‘real-world’. Second I’m going to draw a diagram and elaborate from there.     So let’s use the example of walking from ‘Hunting and Fishing Westgate’ (Point A) to the traffic light on the yellow road on the top of the screen (Point B). To achieve Path coverage you need to explore every possible route that you could take to get from ‘Hunting and Fishing Westgate’ to ‘Traffic Light on the Yellow road’. Here’s what you could do: From H&F Westgate you could turn left then left again onto Fernhill Drive and walk straight until you reach the Traffic light. You could turn right then right again onto Pinot Lane then turn onto Cellar Crescent then turn right onto the yellow road, keep going straight until you reach the traffic light. You co

How to do well in the ISTQB Foundation Exam So here you are, about to sit the ISTQB Foundation Exam.  Maybe you want to enter the world of Software Testing and want to get a related qualification on your CV/resume. Maybe you're already working as a Test Analyst and now your company has a new initiative where everyone needs to sit this exam.  Either way, I  hope some of the tips below can help. But first, I'd like to thank ISTQB for this picture. This is a visual summary of what to expect in the ISTQB Foundation Exam. For more tips go here : Time and Format of the Exam There are 40 multiple choice questions. You have 1 hour to answer all of the questions. Bear in mind that a fair number of the questions are tricky so you definitely want to leave time at the end (10-20min) to go over answers and make sure that you didn't accidentally pick the wrong answer because you didn't read it correctly. Here's a link that summarises the exam stru

This is Part III of the Journey of a Test Analyst series. Part I: The Beginning Part II: Getting my foot in the door Starting work as a Test Analyst After 4 weeks of training  I was finally... DUN DUN DUN Off to my first project as a Test Analyst! Inside, I felt a mixture of this And this I was nervous as this was my first project and part of me was a bit worried that I'd put my foot in my mouth and say something stupid or not ask smart enough questions. But then I was also pretty excited as this is what I've been working towards this whole time. On my first day, I had two people ask me if this was my first (ever) project. I gotta admit, that didn't sit too well with me as from that point on, on my first day, I was worried that I looked a teeny weeny too fresh-faced. But hey, it is what it is so I smiled back and responded yes it is. Here are a few things that struck me the most about my first few weeks on the project  I should h

This is Part II of the Journey of a Test Analyst Series Part I: The Beginning Part III: Diving into the Big Bad World of Testing Now let's launch straight into it shall we. The Application Process Well to start with, the thing that really caught my attention was the fact that a handwritten cover letter was asked for. So this caught my attention for a few reasons. I figured, since we're actually using snail mail to submit part of our application; they're more likely to be read No backspace was available for my cover letter (Shock! Horror! Old school it is then.) Will my handwriting be legible? Most people can't read my handwriting when I don't make an effort to be legible. I'd liken to a doctor's. I also prepared and submitted my CV, placing emphasis on the skills I possess that applied to the role of a Test Analyst. Quick tip: Make sure to proof-read your application. I've been told time and time again that attention to detail is mu

This is Part I of The Journey of a Test Analyst Series. Part II: Getting my foot in the door Part III: Diving Into the Big Bad World of Testing So in this post I'm gonna go over how I got into the IT industry in the first place; i.e. how and why I first started thinking about it. First off, I saw the job advertisement on Careerhub. For those who do not know, Careerhub is a website for job seekers that are currently in (or just graduated from) a tertiary institution. A few parts of the job ad stood out to me. These are: A career in the IT industry --> given our reliance on technology these days; job prospects would be good. Assurity are thought leaders and that was something I wanted to be a part of. Exposure to different projects and industries Focus on innovation and improvement. And last, but most certainly not least- training. I'm now going to proceed to focus on this last point. You see, I didn't study Software Engineering or Computer Science.

All XML Elements must have a Closing tag Unlike in HTML where some elements don’t need one. This is very important- when I update existing XML documents so that I can send a message to another system à this is a basic thing I check so that I don’t get annoyed by a stupid error message Oh, and if you need more incentive. It’s ILLEGAL. XML tags are Case sensitive Opening and Closing tags must be written with the same case Otherwise, they are technically different. XML Documents Must have a Root Element In other words, all of the elements need a mummy. At least one element must be a parent to the others. For example it should be: <Book> <Title>Hunger Games</Title> </Book> You can’t put just: <Title>Hunger Games</Title> (P.S. The Hunger Games Catching Fire Trailer is out now- trés excited!) XML Attributes Attributes provide more information about the element. These always have to be in either single or

What exactly is XML? XML is eXtensible Markup Language. What's it used for? To transport information and send data. For example: Between 2 systems. XML is designed in such a way that XML enables 2 systems to 'talk' to each other. An important distinction to note between XML and HTML is that whilst XML is used to transport information and send data; HTML is used to display information. There are not really pre-defined rules regarding tags. So if you want to send information on, say, someone's favourite chocolate- you could type in: <chocolate> Butterfinger </Chocolate> Why do I want to learn XML? I'd love to explore of the possibility of getting into Integration Testing later in the future. How am I learning XML? W3 schools website - it's an awesome website (I definitely recommend it) At work Bit of Youtube

The Pros and Cons of RTC First and foremost I'm gonna elaborate on exactly what this sexy thing is. RTC stands for Rational Team Concert. On the website that link on the left refers to; it calls it an "Agile Application Lifecycle Management Solution". Which I guess kinda makes sense, in the sense that "Agile" seems to be very "in" in the world of Software Testing these days. (I did a bit of a Google search and Google agrees) But then what do I call it, you might ask? I call it a place where documentation gets stored (Source Control) and work items (like Defects, Issues, Change Requests and Risks) are put up. Mind you, I've only been using RTC as a Test Analyst since end of August so I'm sure I haven't fully understood/embraced its intricacies yet. So gotta keep in mind that these Pros and Cons is from that sort of mindset. Pros   My favourite pro would probably the nifty dashboards you can create. Someone from the PMO in my pro

4 Cool Things I learnt from Dr. Alistair Cockburn Use Cases to User Stories Last week I went on a 2-day course held by Alistair Cockburn.  I found it pretty intense (being the only TA (Test Analyst), and having to familiarise with all the TLAs (Three Letter Acronyms) and XTLAs (Extended Three Letter Acronyms) but I got there in the end). But before I dive into the cool things I learnt; here's a quick intro to who Dr. Alistair Cockburn is: He's one of the parents of Agile Development. According to Cockburn, if you were to describe Agile in a elevator-spiel it is "early delivery of business value" and "less bureaucracy". Oh and on a random note he's fluent in at least 4 languages (I might've forgotten one), English, German, French and Swedish- so that's pretty darn cool in my books. 1. Developers prefer user stories. Testers and business analysts prefer use cases I found this little tidbit of information rather interesting. Apparent