Nicky Tests Software: March 2013

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.





Tuesday, March 19, 2013

The joys of 2 screens

Why I love having 2 screens at work

Oh 2 screens, how do I love thee? Let me count the ways.

You may think that this quote by Elizabeth Barrett Browning is a wee bit over the top to describe my love of 2 screens. But let me tell you this. It's great to work in my role with that extra screen to make testing that much more convenient (and let's be honest: easier.)

But to start off with, let me recount my experience on life WITHOUT an extra screen as a test analyst. I REALLY hated it. I saw other test analysts with 2 screens. I looked at them with envy. I'd ask my test lead, why don't I have an extra screen? :( He then told me this was his first project with an extra screen. Flippin heck. I couldn't believe that man. It's so much quicker to test with an extra screen- why would you disturb efficiency by limiting someone to one measly screen?!


About 3 months into my project, I came into work and a computer with TWO screens was waiting for me.

Shit yeah girl. That's what I'm talking about.

I was now able to run tests on the testing tool AND test the system that was yet to be released on 2 different screens. No longer was there a need to squish both of them up on the same screen and use the darn horizontal scroller. I was now able to execute more test cases in a shorter space of time because of the addition of the extra screen.

Another reason why I love having an extra screen is being able to use one screen to go over a Design Spec and use the other screen to look up the definitions of terminalogy I was unfamiliar with. Some people are happy to flick back and forth between 2< screens. But I'm not a member of that club.

Oh and on a side note: it's pretty cool having your 2 screens be "facing the opposite direction" If you press Ctrl + Alt + (down arrow) then your first screen will turn upside down and the second screen will stay the same. (I know I know.. it's a bit silly but it is entertaining nevertheless)

Monday, March 18, 2013

What is a test analyst?

What is a test analyst?

How I try to answer this question when people ask me what a test analyst is.

So... what exactly is a test analyst? I get asked this question all the time when I catch up with old uni and high-school friends and to be honest, I do find it a hard question to answer simply.

If you were to google this you'd probably find something along the lines of...
"The Test Analyst is responsible for designing, developing, and executing test plans and test cases that verify a software conformance to defined acceptance citeria."

but then, what exactly does that MEAN?

I then try to explain to my friends, I work in IT and am a consultant on IT projects.

So then they ask- are you a developer? Do you write code?

Nope, sorry. But I do check the code of developers by running tests and making sure the system behaves as it should.

So then how do I answer this (still somewhat dreaded question because it can be a bit hard to describe) might you ask?

I say; we help build quality into software. As software is being built; as the documentation is being written etc etc test analysts need to be there to analyse the documentation to make sure it does meet the requirements (what the business "requires" of the technology) and they need to be there to find defects so that (ideally) things will be smooth sailing once a piece of software goes live (i.e. out to the general public).