20 October 2011
Do I Join the AST?
The last couple of months I have been umming and ahhing about joining the AST. I'm hoping that replies to this will convince me finally, one way or the other.
17 October 2011
More Than Just a Bug Reporter
What is the output of testing? Since I believe testing is the act of providing information about the system under test, then the answer is 'Information'. This information can be imparted several ways, the most notable of which is a bug report. It is not the only avenue, nor is it the only information that testers gather. However, I do find that is seems to be the only information that is requested/expected from other project members. If they are only interested in bug reports, this leads to holes in the stakeholders understanding of the system. But what do you do when the people you are supposed to provide information to, do not tell you what information they require?
Leading on from this is the idea that the only time we can give useful information is during the system testing phase of a project. However, many times I have discovered issues with the design of an application that would have been recitfied mcuh earlier if only I was involved with the design phase. What is particularly annoying though, is that in numerous project reviews, it is stated that testers should be invovled earlier, and it is always forgotten/ignored for the next project. And so the cycle continues.
*Sigh*
Leading on from this is the idea that the only time we can give useful information is during the system testing phase of a project. However, many times I have discovered issues with the design of an application that would have been recitfied mcuh earlier if only I was involved with the design phase. What is particularly annoying though, is that in numerous project reviews, it is stated that testers should be invovled earlier, and it is always forgotten/ignored for the next project. And so the cycle continues.
*Sigh*
28 September 2011
Inconsistencies
Being a bit anal retentive (which is why I refer to myself as a Test Analyst rather than Test Engineer), one of the things I look for when testing software is that there is consistency throughout, e.g. that same colour scheme used, buttons are in the same place between windows and that the grammar is the same.
So you can imagine my annoyance when I noticed this in Blogger's new Stats page:
So you can imagine my annoyance when I noticed this in Blogger's new Stats page:
UPDATE: 11/11/11
Blogger has made another update and now the words are consistent.
23 September 2011
Sharing Knowledge
One of my colleagues has set up an internal wiki and I decided that this would be a perfect forum with which to note down my knowledge of various systems (particularly the things I have done with the Work Items and Process Templates in Team Foundation Server) and other esoteric knowlegde I have gained thoughout my career, with a view to help others in the company, and especially those testers that will come after me.
The problem I'm having is, since no one has asked me to do this, I have no idea as to what information is going to be useful, or how best to present it to make it clear and informative even if I did.
Which leads the question:
Is what I'm trying to do actually going to be useful to someone?
It is an important question, since if this idea falls under YAGNI, should I be spending the effort to do it? So far, the only answer I have to it is that I will probably find it useful, at least to practice being able to put my ideas down into words.
I'm not sure that is enough, since I have a blog for that sort of thing.
The problem I'm having is, since no one has asked me to do this, I have no idea as to what information is going to be useful, or how best to present it to make it clear and informative even if I did.
Which leads the question:
Is what I'm trying to do actually going to be useful to someone?
It is an important question, since if this idea falls under YAGNI, should I be spending the effort to do it? So far, the only answer I have to it is that I will probably find it useful, at least to practice being able to put my ideas down into words.
I'm not sure that is enough, since I have a blog for that sort of thing.
02 September 2011
Tracking Testing Efforts
Recently, I have been having problems with tracking what testing I have done, since over the last year or so I have moved away from creating test scripts (except for when I believe they are required), and instead deriving tests from various sources as I go. The main output I have is bug reports, but of course they only show what problems you found, not what testing you have done.
My idea then is to purloin the Session report used in SBTM and adapt it for my needs. Our company uses TFS 2010, so I created a new work item that could be used to capture my session information. This means that any bugs raised can be linked to a session allowing me to track what I was thinking when the bug was found, but also the session work items should let me show what I have done whilst testing.
The work item is created and in the system, but I haven't yet run a session. I suspect the weak link in this otherwise damn fine plan, will be my note taking (I've never learned note taking as a skill, to the point where I don't bother taking notepads into meetings, since I know they'll still be blank when it finishes). It relies on the tester being able to note what they are doing, whilst doing it, which can then be read back and understood further down the line. I shall see how it goes, but fully expect it to need further work before I can get it right.
UPDATE: I have used these session work items for a few days now. I find that I have to try writing notes as I think of things, because otherwise I'll perform the test and if I don't find a bug or issue I won't note that I've done it. Since this defeats the purpose, I'm trying to train myself to add the note, then perform the test.
The proof as to whether it is a suitable use of my time though is going to come when I have to refer back to the sessions, which so far I haven't had to do...
My idea then is to purloin the Session report used in SBTM and adapt it for my needs. Our company uses TFS 2010, so I created a new work item that could be used to capture my session information. This means that any bugs raised can be linked to a session allowing me to track what I was thinking when the bug was found, but also the session work items should let me show what I have done whilst testing.
The work item is created and in the system, but I haven't yet run a session. I suspect the weak link in this otherwise damn fine plan, will be my note taking (I've never learned note taking as a skill, to the point where I don't bother taking notepads into meetings, since I know they'll still be blank when it finishes). It relies on the tester being able to note what they are doing, whilst doing it, which can then be read back and understood further down the line. I shall see how it goes, but fully expect it to need further work before I can get it right.
UPDATE: I have used these session work items for a few days now. I find that I have to try writing notes as I think of things, because otherwise I'll perform the test and if I don't find a bug or issue I won't note that I've done it. Since this defeats the purpose, I'm trying to train myself to add the note, then perform the test.
The proof as to whether it is a suitable use of my time though is going to come when I have to refer back to the sessions, which so far I haven't had to do...
26 August 2011
Cardiff STC Meetup Writeup
I attended my third Software Testing Club Meetup last night, this one being held in Cardiff. As is usual for these events, I spoke to a lot of interesting people not just testers but recruiters and developers also. I had a conversation about automation is the big thing that companies are looking for, to a developers about testability and test driven development, as well as a number of other software testing activities (e.g. documentation, performance etc).
There were four lightning talks given, the first given by my friend and organiser of the event, Sean Robbins. He showed us how to use Watir to run an automation test (in this case, search for something on google and check for results) by using it to run the browser, or by just sending HTTP requests which allows the test to run much faster. Very useful if you do not need to touch the form, which can be very susceptible to breaking your automation test from the smallest of changes.
The second was presented by a developer, Warren Seymour, who was talking about testability in code. He expanded on the concept of MVC (Model View Controller), which normally is only used serverside, to show how you can use it for client side code as well. He recommened two javascript MVC frameworks, the cunningly titled Javascript MVC and Backbone.js.
Thirdly, there was a quick overview on performance testing requirements from Vicky Dibble. She made the very reasonable point that a performance requirement cannot be simply 'the page will load in under five seconds', since that is giving no information on user load or considering the simple fact that sometimes, especially with web pages, you just get a slow response without a seeming underlying reason (hence she suggested changing the requirement to '98% of the time, the pages will load in under five seconds'). What she showed that was of particular note, was to use the User Community Modelling Language (UCML) to build up a picture of your systems typical user flows and be able to work out what tests you need to create.
Lastly, Mark Coakley talked about the issues facing him where they have lots of very old legacy systems that require regression testing, but they are also hiring a lot of new people from outside the business and have to be able to get them up to speed as quickly as possible. What he showed was how they began testing their documentation looking for clairty and accuracy. They then build up a picture for each document with a red, amber, green lisiting for each area they are looking at, which indicates that it is completely wrong (red), wrong but usable (amber) or all ok (green).
I highly recommend these meetups, so be sure to check the Software Testing Club Meetup page for upcoming events and do be sure to attend one. I'm hoping there will be another in Bristol in the next few months and will be sure to ramble on about it here when it does.
There were four lightning talks given, the first given by my friend and organiser of the event, Sean Robbins. He showed us how to use Watir to run an automation test (in this case, search for something on google and check for results) by using it to run the browser, or by just sending HTTP requests which allows the test to run much faster. Very useful if you do not need to touch the form, which can be very susceptible to breaking your automation test from the smallest of changes.
The second was presented by a developer, Warren Seymour, who was talking about testability in code. He expanded on the concept of MVC (Model View Controller), which normally is only used serverside, to show how you can use it for client side code as well. He recommened two javascript MVC frameworks, the cunningly titled Javascript MVC and Backbone.js.
Thirdly, there was a quick overview on performance testing requirements from Vicky Dibble. She made the very reasonable point that a performance requirement cannot be simply 'the page will load in under five seconds', since that is giving no information on user load or considering the simple fact that sometimes, especially with web pages, you just get a slow response without a seeming underlying reason (hence she suggested changing the requirement to '98% of the time, the pages will load in under five seconds'). What she showed that was of particular note, was to use the User Community Modelling Language (UCML) to build up a picture of your systems typical user flows and be able to work out what tests you need to create.
Lastly, Mark Coakley talked about the issues facing him where they have lots of very old legacy systems that require regression testing, but they are also hiring a lot of new people from outside the business and have to be able to get them up to speed as quickly as possible. What he showed was how they began testing their documentation looking for clairty and accuracy. They then build up a picture for each document with a red, amber, green lisiting for each area they are looking at, which indicates that it is completely wrong (red), wrong but usable (amber) or all ok (green).
I highly recommend these meetups, so be sure to check the Software Testing Club Meetup page for upcoming events and do be sure to attend one. I'm hoping there will be another in Bristol in the next few months and will be sure to ramble on about it here when it does.
15 August 2011
An Agile Problem
I have myself a problem with the proponents of Agile. Before I state it, I'll need to clarify a few points:
1) I have read the Agile Manifesto and support the values and ideas behind it
2) I have never worked in an Agile environment (or even an iterative development style project)
3) I very much consider myself as a context-driven tester
With these points in mind, let me share my issue.
Through the things I have read from those who do work with and contribute to the Agile methodologies, I get the impression that Agile is always right, and if it doesn't work, it must be how it was implemented (see we tried baseball and it didn't work). Therefore, there cannot be any context where Agile may not be suitable. This sounds suspiciously like best practice to me.
However, I freely admit I may be entirely wrong here. As I say, it is an impression based on various things I have read and from a position of relative ignorance. I would like this impression to be changed and certainly to be less ignorant on the subject.
Links to suitable reading matter would be appreciated.
1) I have read the Agile Manifesto and support the values and ideas behind it
2) I have never worked in an Agile environment (or even an iterative development style project)
3) I very much consider myself as a context-driven tester
With these points in mind, let me share my issue.
Through the things I have read from those who do work with and contribute to the Agile methodologies, I get the impression that Agile is always right, and if it doesn't work, it must be how it was implemented (see we tried baseball and it didn't work). Therefore, there cannot be any context where Agile may not be suitable. This sounds suspiciously like best practice to me.
However, I freely admit I may be entirely wrong here. As I say, it is an impression based on various things I have read and from a position of relative ignorance. I would like this impression to be changed and certainly to be less ignorant on the subject.
Links to suitable reading matter would be appreciated.
Subscribe to:
Posts (Atom)