Nicky Tests Software: 2013

Wednesday, November 13, 2013

My Experience at WeTest Auckland 2

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.


Monday, October 21, 2013

Teaching someone how to write Test Cases

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.

Monday, September 30, 2013

Breaking Bad Communication Habits

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?

Monday, September 23, 2013

Using Mind-maps as a Collaboration Tool

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, too, have also helped developed your team's ideas.

Another reason why I'm becoming quite a fan of mind-maps, is the fact there's so many ways you can organise your test case ideas. I, myself, find it interesting to watch 'live' my other team members work on the mind map and see how they organise their test case ideas, whether it be by part of the software or splitting it into different types of non-functional testing (and which of these would be suitable for the software).

Other than the obvious benefit of a mind-map helping you come up with ideas for test cases, it does have another handy benefit. It helps you understand the system and develop your thought processes visually as you explore what exactly the system entails. I'd almost liken mind-maps as a 'thinking out loud' process, where you answer your own questions by just delving deeper into the mind-map and generate more test case ideas.

Friday, September 6, 2013

But look there's a bug, shouldn't it get fixed?

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 make a decision of whether or not a bug is worth fixing. The idea of writing a statement on the risk of not fixing the defect has crossed my mind, but I'm not comfortable assuming I know what exactly constitutes risk for the client.

I've found that if something just looks weird and you think that the client would be interested in seeing it - you ask to show them something. You replicate the defect in front of them and then ask what they think.

If this option is not available, part of me also wants to try something a tad unconventional. Say - putting the defect in a 'real-life' scenario, and describing the defect in such a way that the impact of the defect is clear.

For example:
You want to grab one of those awesome deals on GrabOne. (This is a website similar to GroupOn)
Look - there's a superb deal for a gym membership for $20 for 2 months.
You read through the description thinking "Looking good, looking good"
Scanning through the terms and conditions, you notice that they are rather ambiguous with when the deal expires. Offer ends 30 November 2013. Hang on - does that mean you need to start the gym membership by the 30th of November or you need to have used up the deal and finished your membership by the 30th of November?

Now, the problem is, the Start the Discussion hyperlink doesn't work. It sends you to some error page. This could deter people from grabbing the deal.


Do you add extra information to a defect in order to help it be assessed? If so, what information? Do you ever have trouble convincing someone to fix a defect because they don't think it is important/likely, even though it actually is?


Monday, September 2, 2013

Getting excited about organising a Testing Meetup


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, based on how people give feedback/ask questions on the Experience Report.


c) The Dice Game

Yes, it can be very frustrating - especially considering you can break the rules (which really forces you to think outside the square). But it's very satisfying when you finally do figure it out and think back to previous rolls and how it satisfied the rule.

d) The Experience Report

Donna McIntosh will give an experience report on Automation. Other than the fact it's a topic often talked about in testing, I'm keen to see on what she has to say about her criteria on when Automation is viable.

Thursday, August 22, 2013

Interview with Aaron Hodder

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

Wednesday, August 7, 2013

How your Judgement on the Quality of Airlines and Software can depend on your past experiences

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.

Saturday, July 27, 2013

A Weird Observation whilst Internet Banking

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.

Friday, July 19, 2013

So how do new Test Case Ideas during execution, affect reporting?



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?


  1. 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?
  2. 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 of coming up test case ideas as you do test execution? How would it affect reporting?

    I was asked if I had to, in fact, write test cases.
    Answer: Yes I do on my current project

    You see, I think it's important for any form of test reporting on the current system to reflect the actual state. 

    At the moment, as new test case ideas come to my head, I am making an effort to jot them down on a spreadsheet so I can properly track them. I'm also planning to mind-map my new test case ideas as they come to me.

    Monday, July 15, 2013

    Playing PC Games as a Test Analyst: Part I Bioshock Infinite

    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.

    Tuesday, July 2, 2013

    Happy 1 Year Anniversary with Assurity to me Part II

    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.

    Happy 1 Year Anniversary with Assurity to me Part I

    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.

    Wednesday, June 26, 2013

    Interview with Michael Larsen

    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


    Sunday, June 23, 2013

    Getting Feedback as a Software Tester

    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.

    Monday, June 17, 2013

    8 Questions I ask myself when Testing Software

    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?

    Sunday, June 16, 2013

    Wednesday, June 5, 2013

    How would I Promote the Software Testing profession?

    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 career and to get young people interested in exploring this possible career path.

    So to focus on a specific example: The Monetary Policy Challenge. This is an Economics competition aimed at high school students. The long and short of it is that it is organised by the Reserve Bank of New Zealand (New Zealand's central bank) and participants need to come up with an Official Cash Rate then justify it. (BTW the Official Cash Rate is like the interest rate at which the central bank lends money to the other banks- i.e. OCR goes up, interest rates go up --> mortgages are more expensive, saving is encouraged etc etc).

    Anywho. Enough of that. I don't want to lose you just yet. Let's get straight into it shall we!

    So what I'm going to do is outline, in bullet points, what this competition would involve, and then draw attention to some possible benefits that could be reaped from such an idea.


    Here's a Bullet Point format of what it would involve:

    • You need to be in a team of 2-6 people to enter
    • A few companies collaborate to run the competition and write requirements, build a piece of test software, change their minds with what they want etc etc to make it more 'real-life'
    • The competition is promoted to those studying IT in high school and uni through lecture bashes and newsletters- but NOT limited to those studying IT. 
    • Potential prize could be an internship for members of the winning team
    • Judges' criteria will include creativity, effectiveness, ability to justify, accuracy etc
    • Networking event after the prizegiving ceremony takes place

    Possible Advantages:

    • Students have more career choices, they now know what software testing as a career path could look like
    • Potential Employers are able to meet students and listen to their viewpoints from a fresh perspective
    • More exposure to software testing as a career
    • Student get a better idea of what it's like to work on an IT project and can relate it back to websites they are familiar with like Facebook, Tumbler, Twitter, ZMonline etc
    • Friends and family of participants also gain awareness of the software testing industry
    • Sponsors will be exposed to students and perhaps students will see that as a more desirable work location
    • Sponsors can build important networks among themselves
    • Sponsors can see this as a step towards building strong relationships with tertiary institutions and secondary schools


    Tuesday, June 4, 2013

    Interview with Nadine Henderson

    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

    Monday, June 3, 2013

    More ISTQB Tips and Explanations of Sample ISTQB Foundation Questions

    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 you're asked something along the lines of: "Which goal is the MOST valid to try and achieve?" At least 2 of your options will definitely be valid, so don't just circle the first correct answer you see as you go through your options

    Learn the different ways to say the same thing

    For example: Confirmation Testing and Retesting --> They're the same thing. You don't want to be thrown by a question that you should know the answer to because you didn't know about different ways of saying the same thing.

    Learn the different types of Coverage

    You're guaranteed a few questions that will check you actually know the difference between Decision coverage, path coverage, branch coverage etc. I've written a blog post on the difference between Branch and Path coverage here.

    Make sure you learn the 7 Key principles of Software Testing

    Here they are:

    (Source: http://www.universalexams.com/iseb-istqb-certification/the-7-key-principles-of-the-isebistqb-foundation-level-exam)

    Principle 1: Testing shows the presence of bugs (but a failure to find bugs does not necessarily mean that none exist). Tests must be designed to find as many bugs as possible, and since it is assumed that every product initially has bugs, a test that identifies bugs is better than one that finds none.

    Principle 2: Exhaustive testing is impossible because there are usually too many variables that come into play. Therefore, testers must focus efforts on only the most critical priorities and risks.

    Principle 3: Testing should be done as early as possible after the product or application has been created, in order to fix issues as fast as possible. Errors identified later in the process tend to be more expensive to mitigate.

    Principle 4: Use defect clustering, as software problems tend to cluster around narrow areas or functions. By identifying and focusing on these clusters, testers can efficiently test the sensitive areas while concurrently testing the remaining “non-sensitive” areas.

    Principle 5: Use a variety of tests and techniques to expose a range of defects across different areas of the product. Avoid using the same set of tests over and over on the same product or application, because this will reduce the range of bugs you will find.

    Principle 6: The same tests should not be applied across the board because different software products have varying requirements, functions and purposes. For example, a website should be tested differently than a company Intranet site.

    Principle 7: Don’t buy into the absence of errors fallacy. In other words, a test that finds no errors is different than concluding that the software is error-free. It should be assumed that all software contains some faults, even if said faults are hidden.

    Confirm answers

    Not only should you make sure that your answer is correct but that the other answers (that you did not select) are definitely wrong. This is a great way to stop yourself from being caught out.


    Explanations of Sample ISTQB Foundation Questions




    Which of the following statements BEST describes one of the 7 key principles of software testing?
    a) Automated tests are better than manual tests for avoiding the Exhaustive Testing
    b) Exhaustive Testing is, with sufficient effort and tool support, feasible for all software.
    c) It is normally impossible to test all input/output combinations of a software system
    d) The purpose of testing is to demonstrate the absense of defects


    Ok let's start from the top.
    a) This doesn't make any sense. How does automation help avoid exhaustive testing?
    b) Exhaustive testing (note this is also known as complete testing) is not feasible for all software. The keywords here are ALL software. Even with the addition of the words "sufficient effort and tool support" makes that option seem possible, the "all software" part cancels it out.
    c)Yep this looks good. Since software systems are so complicated, testing all input/output combinations of a software system would indeed be very difficult and "normally possible". Let's hold on to this one for now but check the last one just to make sure.
    d) Nope. It is to demonstrate the presense of defects. BUT say you didn't learn this particular key principle of software testing. Then you could also ask yourself, how exactly would testing a piece of software prove that there is nothing wrong with it (i.e. there are no defects).

    Answer: C




    Which of the following statements are TRUE?


    A. Software testing may be required to meet legal or contractual
    requirements.
    B. Software testing is mainly needed to improve the quality of the
    developer’s work.
    C. Rigorous testing and fixing of defects found can help reduce the risk of
    problems occurring in an operational environment.
    D. Rigorous testing is sometimes used to prove that all failures have been
    found

    a) B and  C are true. A and D are false.
    b) A and D are true. B and C are false.
    c) A and C are true. B and D are false.
    d) C and D are true. A and B are false.

    With these sort of questions I like to use the process of elimination technique and figure out which sentence out of the ones above is true so that I can eliminate 1 or more options as soon as possible.
    Let's start with A.
    Yes- A is true. It's feasible that software testing may be required to meet legal/contractual requirements (e.g. for peace of mind for people 'above' and to know that the software is of a certain quality)
    Now that we know that sentence A is true. Let's eliminate options a) and d)
    Let's read sentence C. Yep definitely- rigorous testing and defect fixing can reduce the risk of problems occuring in an operational environment. Let's put this one on hold and check sentence D.
    D- nope you can't prove all failures have been found. It's not feasible. Similar to the idea of Exhaustive Testing is impossible.

    Answer: c)



     

    Thursday, May 30, 2013

    Interview with Markus Gaertner

    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.


    Tuesday, May 28, 2013

    Testing - The Hidden Profession

    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 verify the quality of software before it goes live and plan how to break it.

    I’ve had many conversations go along these lines and I’ve come to the conclusion that a lot of people not only don’t know what exactly a Test Analyst does- but the fact that they exist.

    Well I suppose that shouldn’t surprise me, given that I, for one, honestly thought that software development went a little like this (before I discovered the world of Software Testing):

    1. Project Managers and Business Analysts tell the developers what they want the system to do
    e.g. I want a search website that finds what I want, is not case sensitive and comes up with a maximum of 10 search results per page.
    1. Developers write code for this
    2. It goes live
    Oh and I suppose the developers and/or Project Managers & Business Analysts would try out the system to see how it was.


    It didn’t occur to me that there are people whose profession is dedicated to ensuring software quality is present.
    It didn’t occur to me that this role could branch out to many more roles such as a test engineer, test manager, integration specialist, automation...
    It didn’t occur to me that this role is in high demand in NZ

    Little did I know.

    Now that the world’s reliance on technology is increasing, it makes sense that careers surrounding these changes are plentiful. Don’t get me wrong. I’m not in any way saying that it is easy to get a job as a Test Analyst. But I think I could say that the market is promising.

    But you know what really irks me?

    The fact that some people think that anyone can be a Test Analyst.

    I’m pretty sure there are people out there who think they can just haul someone in front of a computer, tell them to ‘test’ it, and then go-live based on that person’s findings (who, in fact, has another day job).

    Now maybe, this is suitable for a really small company where it doesn’t make sense to have someone devoted solely to software testing because everyone at that company has a range of roles in the organisation.

    Or maybe it’s a start-up and no financial resources can be allocated to do software testing.

    Both of the above scenarios are realistic, and dare I say justifiable.

    But if you want to make sure that the system is performing the way it should be- then you know who to call.

    Maybe it’s the fact that many people aren’t aware of how IT projects actually operate.
    Maybe it’s the fact that people don’t see the point in hiring someone dedicated to ensuring software quality.

    But let’s face it- Testing is the Hidden Profession.

    So now what are we going to do about it?

    My intention in this blog is not to raise awareness among those who already understand the  benefits of testing. But I do want people to raise awareness around this profession.

    Tell people what you do day to day.
    Tell people what makes your role important in an IT project
    Tell people what makes being a Test Analyst stimulating.

    Have that conversation, then see what happens next.

    Wednesday, May 22, 2013

    What is the difference between Branch Coverage and Path Coverage? (ISTQB)


    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 could turn right then right again onto Pinot Lane then turn right until you reach the end of the road (at Fernhill Drive) then turn left and keep walking until you reach the traffic light.

    And so on and so forth.

    My point is, for Path coverage your goal is to take as many different possible routes from Hunting and Fishing Westgate to the Traffic Light


    To achieve Branch Coverage, you want to make sure you walk along each road at least once when you walk from Hunting and Fishing Westgate to the traffic light.

    There are 4 routes from Points A to B to ensure 100% branch coverage.
    1. On Monday you could turn left then left again onto Fernhill Drive and walk straight until you reach the Traffic light

    1. On Tuesday you could turn right then right again onto Pinot Lane then turn right until you reach the end of the road (at Fernhill Drive) then turn left and keep walking until you reach the traffic light.

    1. On Wednesday 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.

    1. And on Thursday you could turn right then right again onto Pinot Lane then turn right until you reach Asti Lane, turn left onto Asti Lane then turn right once you reach the yellow road and keep walking til you reach the traffic light.

    Now using 2 pictures I just drew using Paint, I’m going to attempt to explain the difference between Branch and Path Coverage.

    Here’s my first diagram which shows 100% Branch coverage, note that each branch has a colourful line drawn over it at least once.



    Now here’s my second diagram which shows 100% Path coverage.





    Note that in the first Paint picture, my aim was to make sure that each branch (black line) had a colourful line drawn over it at least once. I.e. each branch had to be covered at least once -->achieving 100% Branch Coverage.

    In the second Paint picture, my aim was to explore as many different possible routes to get from the green box at the top to a yellow circle at the bottom.

    The second picture is the same as the first picture with the addition of 4 orange lines.

    So how did you find this post? Let me know if it helps you tell the difference between Branch Coverage and Path Coverage.Do you prefer my analogy explanation or the pictures I created using Paint?










    <!--[endif]-->

    Tuesday, May 21, 2013

    11 Useful Tips on how to get a Great Mark in the ISTQB Foundation Exam:

    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 structure. This is VERY useful. Make sure you look at this.
    http://www.istqb.org/certification-path-root/foundation-level/foundation-level-exam-structure.html

    Here's the number of questions allocated to each chapter
    Chapter 1: Fundamentals of Testing - 7
    Chapter 2: Testing throughout the Software Cycle - 6
    Chapter 3: Static Techniques - 3
    Chapter 4: Test Design Techniques - 12
    Chapter 5: Test Management - 8
    Chapter 6: Tool Support for Testing - 4 

    K1 (50% weighting) Remember, recognise and recall
    K2 (30% weighting) Understand, explain, give reasons, compare, classify and summarise.
    K3 (20% weighting) Apply in a specific context

    Models, Levels and Types of Testing

    Make sure you learn the different models (V-Model, Waterfall etc), Levels (User Acceptance Test, System Testing etc) and Types (Regression, Functional, Non-functional) of Testing

    When I say 'learn', I mean this:
    • Learn the definition of each of them
    • Learn their advantages and disadvantages
    • Learn the order of the levels and what they involve. i.e. User Acceptance Testing, System Test, Integration Test, Unit/Component Test
    • Learn how to compare things with each-other i.e. Models with other models, Types with other Types

    Practice Practice Practice!

    Make sure you do not only the mock exam questions at the back of the textbook, but also past exams online.
    Here are some useful websites to get you started:

    Testing Techniques, Tools and Dynamic & Static Testing

    With regards to Testing Techniques, as you learn them- think about how you can apply them to the real world.
    For Dynamic and Static Testing- not only should you learn the definitions but what it actually involves. i.e.

    • Static Testing is Testing without execution e.g. going over documentation to make sure there are no defects.
    • Dynamic Testing is Testing WITH execution e.g. once you have a Test Environment, playing with the system to see how it's going
    For tools, learn the different types, how an organisation would go about introducing it into an organisation and potential benefits and risks of testing tools.

    The Fundamental Test Process

    Learn the order in which the 5 key areas take place and learn the activities performed in each area
    1. Test Planning and Control
    2. Test Analysis and Design
    3. Test Implementation and Execution
    4. Evaluating exit criteria and reporting
    5. Test Closure Activities

    Extra tips that don't necessarily apply only to this exam

    Read the question carefully

    When I was studying for this exam doing mock/past exams, it never ceased to amaze me how many questions I got wrong because I thought I knew the answer before I finished reading the question- and I ended up picking answers prematurely

    Don't get stuck on a question

    If you get stuck on a question, highlight or circle it then move on. There are 2 reasons for this:
    1. You can let your brain 'process' the question so that when you come back to it later you're more likely to know the answer
    2. You won't risk not having enough time to answer questions you knew the answer to because you got stuck on one single question


    When you first learn something, revise it within 24 hours so that it really sinks in

    Someone taught me this tip in first year uni and I've made an effort to do this ever since. It works.

    Reword your notes

    Don't just straight out copy them from the textbook/internet
    That way, you're more likely to understand it

    Display your study notes in a visual way

    Highlight
    Brainstorm
    Draw pictures


    Study with Friends and Partake in online Discussions

    That way, you can bounce ideas off each other and explain concepts that others may struggle/ be taught concepts you're having trouble grasping.

    In NZ, it costs $300 + GST to sit the Foundation Level exam 
    Should you need to resit it, the price is the same.

    So there you have it, hopefully you came across some useful tips in this blog post for when you sit the ISTQB Foundation Exam.


    COMING UP: Tips on how to differentiate between Path Coverage and Decision Coverage


    What tips did you find most useful? What other tips do you have for people about to sit the ISTQB Foundation Exam? 

    If you've already sat the ISTQB Foundation exam, how did you find it?





    -->

    Monday, May 20, 2013

    The Journey of a Test Analyst: Part III Diving into the Big Bad World of Testing

    This is Part III of the Journey of a Test Analyst series.

    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 have kept notes on which Design Specs referred to which part of the functionality. 
    Since I was working on a pretty big system, there were a decent amount of Design Specs I had to 'study' to understand how the system was expected to operate. I wish I kept better -coughlegiblecough- notes.

    There are HEAPS of people that work in IT projects in roles that I never knew existed
    Namely, architects and infrastructure. Up until this point, I only associated architects with home design and infrastructure with cities.

    Face to face communication is much better than email and/or phone
    Even if you're a super-guru with the written word- it can still be difficult to articulate your thoughts in such a way that what you say, and what the other person hears/reads are actually the same thing.
    One of the Grads from the previous intake gave me such advice which is to hold face to face conversations then email the other person a summary of the discussion to make sure you're both on the same page.



    Only using 1 screen can be rather difficult
    This is particularly true as I can look back on only using 1 screen after being exposed to the joys of 2.
    For more info, please refer to this: The Joys of 2 Screens

    Time is precious
    Make sure I get straight to the point when I ask other people questions so that:
    1. They don't see me as a time-waster
    2. They're more likely to be happy to answer questions in the future

    You can expect A LOT of reading in the first few weeks
    I had to not only read the Design Specs to learn how the system was supposed to operate but also read up on the terminology of the organisation that wanted this system built.


    And here's what else I learned from my first project (other than in the first few weeks)

    It's great to make friends on the project, who work in separate areas to you
    Other than the obvious perks of having friends, I liked hearing about what Developers, Business Analysts and Technical Testers need to focus on in a project.

    If you want to upskill- just put your hand up
    We used Sterling Business Integrator to check what was happening between a few systems. Since, I wanted to learn how to use this tool- I asked for help and guidance on how to get started. One of my best friends on the project, who has since gone back to Australia, and my mentor were great at showing me how to use this.

    How to take a screenshot of just the active screen
    It took me about 6 weeks to realise that there was another way to take a screenshot other than Ctrl + PrtScn
    Answer: Alt + PrtScn

    You need to be very clear in what exactly you are raising a defect against
    Since you only have the written word (and screenshots to support what you say) at your disposal, it helps to describe exactly what you did that resulted in you discovering the defect and state clearly if the defect is against code, design etc.

    You don't always have to go for gold at shared morning teas etc
    There'll always be plenty more





    Tuesday, May 14, 2013

    The Journey of a Test Analyst: Part II Getting my foot in the door

    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 muy importante to be an effective Test Analyst- so I like to think I possess this trait.
    BUT, if you get a haircut and I don't comment on it, please don't be offended and throw this blog post in my face.

    Now, onto the next stage: Phone interview.
    I had this during exam time on the top floor of the uni library, so thankfully this was short and sweet.
    My impression of this was that it was an opportunity for the company to gauge what I'm like and how I communicate.
    I do remember thinking: OK Nicola answer the question but don't talk her ear off. (I once had a 6 hour phone conversation- I really can be quite a chatterbox).


    Luckily I made it through that stage as well. *fist pump*

    So it all came down to the face to face interview.

    This was done through video conference. Admittedly, I did find the start a bit distracting as I kept on checking myself out on the corner of the screen to see if I looked OK.

    I also appreciated the fact that they made an effort to make me comfortable and used some humour to diffuse the situation.

    Looking back, I was quite glad that I did some background reading (study) on Assurity before I came in. You see, you know how you usually get told to do your research on a company before you apply/interview, well in this case- I'm certainly glad I did.

    With regards to any specific questions on what I was asked in the interview..... hmm well let's not spoil that part :) some things are best discovering yourselves!

    The Graduate Programme
    And now we come to the Graduate Programme. Hmmm how do I put this?

    Well let's just say that one distinct thing that I remembered from the Grad welcome drinks was the knowing looks that the previous Grads exchanged among themselves when they realised we were just about to start the Grad Programme.

    I learned A LOT in the Graduate Programme including:
    • How to articulate your ideas clearly
    • Professionalism
    • ISTQB 
    • Public Speaking

    To be honest, I'm not sure I'd say it's what I had learned that stick out to me the most now that I look back on the Grad Programme- but more the people I had met (as cliché as that sounds). Don't get me wrong- the intense four weeks made having an exam period where I was tutoring and working (over 25 hours/ week) and studying for exams seem like a breeze. Completing 2 projects in a relatively short space of time, helped us understand the importance of time pressures and how, at the end of the day, you need to complete things (to a high standard) by the time they are due- even when circumstances may change on you.

    NEXT: Getting onto and starting my first project



    Monday, May 6, 2013

    The Journey of a Test Analyst: Part I The Beginning

    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. In fact, I studied German and Economics.

    So then you may be thinking "How do you get from a Bachelor of Arts and Commerce degree majoring in German and Economics to a career as a Test Analyst?"

    You see, I gained a lot of transferrable skills throughout my time at uni such as written communication skills (from my German translation course and the International Trade essays I had to write for my Econ assignments) as well as  analytical skills (from my participation in the Alternative Budget Competition).

    I've also been able to use these skills in my time as a test analyst so far. Although one may think that to be a test analyst you need to have a strong technical background, that's not true.
    Yes, for some roles you do need a fairly technical skill set, but I'm of the opinion that if you don't already possess the technical skills- then just learn them. You do, however, need to pay attention to detail and have strong communication skills.

    So I soon found myself typing out my CV and writing out my handwritten cover letter (meanwhile freaking out that I would make a mistake and have to start the letter again).........

    NEXT: Application process and Grad Programme

    And for now, here are some funny IT pics!






    Tuesday, April 16, 2013

    Learning XML Part II

    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 double quotes.
    Also, they only need to be in the opening tag, you don’t need to repeat the attribute in the closing tag.
    Example:
    <Recipe cuisine=”Italian”>
    <Name> Spaghetti </Name>
    </Recipe>
    (Next week: Excitedly planning for a trip to Oregon)

    Saturday, April 6, 2013

    Learning XML Part I

    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

    Saturday, March 30, 2013

    2 Pros and Cons of RTC

    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 project showed me what magic you can create when you know how to create widgets to add to your nifty dashboard. I made some to track the number of open defects by severity and area (of system), to track testing progress against various test plans in order to see how many tests were passing; failing; blocked and to track how long defects take to get fixed. It's weird, but this dashboard business appealed to the part of me that misses organising my notes at uni while I was studying so I could be more efficient.

    It's not standalone.

    On our project, RTC is linked with RQM (Rational Quality Manager) which is the testing tool we use to actually execute tests. That way you can do some nifty things; like create a widget (refer to  my first pro) that informs you of testing progress. You can also refer to specific tests when you raise a defect by raising a defect (in RTC) from the test you execute (in RQM).

    Cons

    It's very hard to find things in RTC.

     Maybe I'm used to the very high standard Google has set when it comes to searching. But it's very annoying. I usually have to ask people in my team whether or not a defect has been raised regarding a certain part of the functionality- I'm yet to find out what exactly the search thingy in RTC searches for (i.e. the title, or the body).

    This con morely applies to RQM (than RTC) but I gotta say- I wouldn't mind a screen recorder.


    Sure a picture (a screenshot) can say a thousand words. But a visual recording of what exactly you did to create that defect would be super-dooper.












    Sunday, March 24, 2013

    4 Cool Things I learnt from Dr. Alistair Cockburn

    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. Apparently developers prefer user stories as it goes straight to the point of what they need to do. Whereas testers and BAs prefer use cases, as it helps put things on context. It's important to note that they are not substitutes but more like complements.


    2. The Full Requirements File

    Flippin heck this list was intense. It essentially lists all of the types of requirements that should be taken into consideration when building a software system. These requirements ranged from Privacy Requirements, to Safety-Critical Requirements, to Personalisation and Internationalisation Requiremnts to User Documentation Requirements.


    3. Story mapping

    We used a grid to depict functionalities and by whom/ when they will come into production. What I found really interesting about this, is that we were encouraged to "think across" by making sure that when we put down a functionality for a role, that we also stated what functionality came into the same release for a different role.
    Take Facebook for example. Say for the first release you wanted to allow the person logged in to post photos on FB. Then in the same release, it would make sense to allow both the person logged in, and their friends and family to comment on these photos.


    4. Motivational Context

    This is where we brainstormed ideas on who exactly was using the system and their motivations behind it.
    Ok, let's take Facebook as an example again.  (Hey, I use it a fair bit and most people are familiar with it).

    Here's how the Brainstorming session could go.
    Me: I want to use Facebook to keep in touch with people I hardly get to see. Post funny videos and photos to my wall. And every now and then see what exciting things other people are up to (usually it's the people who travel that I FBstalk a little bit more than others hehe)
    My friends: I want to see what other people are up to -coughfacebookstalkingcough-, update photoalbums from the weekend and use it to chat to other friends in the evenings.
    FB Shareholders: I want FB to make a profit in the long-term so I get more bang for my buck.
    Founder of FB: I want FB to be the best social networking site and stay ahead of the competiton.