Monday 26 March 2012
March 2012 - Phases of Testing
As it becomes more instinctive for me to decide what part of our application to test next, e.g. smoke testing a new kit, what bug fixes to concentrate on, or new story features to explore; I can start to focus more attention on exactly how I'm going about my testing. This includes the preparation/planning, the main phase of testing itself, and the reporting of my findings afterwards.
Pre-Testing
I have started to get into the habit of using Mind Maps (XMind) to get the main topics down in black and white. Although it's a very straight forward premise I find it very useful as I can easily forget even the brightest idea pretty quickly if I don't write it down. Mind Maps also double as useful information for future reference. So anyone who wishes to test a feature they haven't seen before can view the Mind Map for test ideas to get them started. I find them of particular use when testing a brand new feature or area of the product with which I am less familiar.
Testing
When I first started testing I was paying more attention to what was going on in front of me on the screen rather than making notes of what I saw. This was very bad practice as memory tends to be a lot less reliable than a written word. The smallest changes in steps to reproduce a bug or unusual behaviour will mean you can no longer produce the desired result. However memorable it seems at the time there is no substititute for recording your findings. I have now started to try and make an effort to make notes when I test now (using Notepad++), especially when testing something new in an exploratory way as it could prove invaluable when trying to recall steps in producing any bugs found.
I also tend to use Firefox a little more than other browsers so that I can have firebug running in the background. Then I can include the firebug error output along with my description when I make a bug report, which can sometimes be useful for developers in pinpointing the origin or cause of the defect.
Screen grab tools and videos are also very useful to back up a description and can often make things a lot clearer than a written description alone in visualising what's gone on.
Re-Testing
Under this heading I include retesting in the sense of Regression testing and also Re-Testing bugs which are believed to have been fixed.
When I run regression tests I do not make as many notes since the paths followed are already well trodden and the steps taken are already recorded step by step. However I use the same methods for recording findings if a bug is found whilst running regression tests.
When Re-Testing bug fixes it can be very easy to fall into the trap of only testing the 'happy path', or the scenario in which the bug was originally found. It's also important to test around the edges of the happy path and test the bug scenario with similar but not identical variations in order to be confident the bug(s) have been fully fixed and will not resurface later on. The number of different paths you can test is obviously time dependent but the more you have time for the better.
Reporting Test Findings
Once testing is complete it is important to quantify what areas of the product have been tested and in what way. This is especially important when describing how to reproduce a bug as if this is not accurate then the developers may not be able to reproduce it for themselves. The steps to reproduce are also important when the bug is fixed and you need to repeat the original steps used to create the bug. You must also make sure you include all relevant setup information such as the browser which was used, the kit version, user credentials, scenario, and any accompanying event logs. This will give the developers the best chance of identifying and reproducing the bug and reduces the chance they will need to come back to you with further questions. It should also minimise the chance of the hearing the well known 'It works on my machine' response.
Wednesday 21 March 2012
February 2012 - Why I made the right choice
I have now been a Software Tester for two months. It seems like only yesterday I started, as the time has gone so fast, but at the same time, I have probably learnt more in the last two months than I did during the last year at my previous job. This says a lot about the difference between my previous employer and my new employer and how they make me feel about going to work.
I think the word Agile probably sums up the difference. Although this is generally a Software Development methodology I think the values below (taken from the Agile Manifesto) can and should apply to multiple industries:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
I think the word Agile probably sums up the difference. Although this is generally a Software Development methodology I think the values below (taken from the Agile Manifesto) can and should apply to multiple industries:
I think the list above highlights quite accurately why the way things are done where I work now make much more sense than the monotonous planning, processes, documents and contracts my former bosses seemed disinclined to get us away from.
Where I now work there is a lot of emphasis on learning both through colleagues but also by self driven education. When there is a positive atmosphere where everyone wants to learn and use their knowledge to help others it instills in me a desire to improve my own knowledge outside of work. I think it helps that Software Development and Testing are such a vast and ever expanding area which the world is becoming increasingly reliant upon, as companies go online and start using the cloud, rather than the high street, to sell their wares. In hindsight I probably would have gone down the Computer Science rather than Sports Science route at University.
As a tester, one of the main lessons I've learnt so far is that there are some core aspects of working in a Test team which must be right to allow a smooth and efficient delivery of work. For me, two of the most important aspects are communication and time management.
Communication so that everyone has a good idea what other individuals in the team are working on and therefore tasks are not duplicated. Also, to be aware of what other teams are working on and how that may affect what your own team is doing. We achieve this through daily team stand ups followed by a scrum of scrums stand up. This means that every individual need not listen to every other individuals update which saves a lot of valuable time.
It really helps that we sit in very close proximity to the developers so that as soon as a bug or issue surfaces we can immediately grab one to demonstrate the problem and they can look into it straight away. Sometimes bugs are known about and a fix is already in the pipeline, or they can be put down to a limitation with the system or feature which hasn't been built yet rather than a fault in the software. I'm sure as time goes on I will come to learn more of these possibilities and will become one less bug for the developers myself.
I've also learnt that effective time management is very important in testing as time can very easily be eaten up by going off on tangents. By this I mean you have to be focused on the task at hand, whether that is testing a bug is fixed, testing a new feature or exploring a new area of the software. In any of these situations you can easily spot a bug or unusual behaviour and decide to investigate a little further. Before you know it you have lost half an hour and wonder where it went. This can have a doubly negative effect in that you have lost focus on your original task and you are probably not 100% focused on the new quirk you have found as you know you have digressed and ought to get back to what you should be doing. Now, when I spot something new I will make a quick note of it as something to look into later when I can allocate time specifically to it, as tempting as it may be to pursue at the time of discovery.
After two months Testing I really feel part of the Development team and appreciate the way the team works. I've learnt a lot and am sure I won't stop learning whilst I'm still a Software Tester. I'm quite sure I have not written anything revelationary as yet. Hopefully over time my posts will offer more insightful views and I'll be able to talk more about experiences that other testers may value.
Where I now work there is a lot of emphasis on learning both through colleagues but also by self driven education. When there is a positive atmosphere where everyone wants to learn and use their knowledge to help others it instills in me a desire to improve my own knowledge outside of work. I think it helps that Software Development and Testing are such a vast and ever expanding area which the world is becoming increasingly reliant upon, as companies go online and start using the cloud, rather than the high street, to sell their wares. In hindsight I probably would have gone down the Computer Science rather than Sports Science route at University.
As a tester, one of the main lessons I've learnt so far is that there are some core aspects of working in a Test team which must be right to allow a smooth and efficient delivery of work. For me, two of the most important aspects are communication and time management.
Communication so that everyone has a good idea what other individuals in the team are working on and therefore tasks are not duplicated. Also, to be aware of what other teams are working on and how that may affect what your own team is doing. We achieve this through daily team stand ups followed by a scrum of scrums stand up. This means that every individual need not listen to every other individuals update which saves a lot of valuable time.
It really helps that we sit in very close proximity to the developers so that as soon as a bug or issue surfaces we can immediately grab one to demonstrate the problem and they can look into it straight away. Sometimes bugs are known about and a fix is already in the pipeline, or they can be put down to a limitation with the system or feature which hasn't been built yet rather than a fault in the software. I'm sure as time goes on I will come to learn more of these possibilities and will become one less bug for the developers myself.
I've also learnt that effective time management is very important in testing as time can very easily be eaten up by going off on tangents. By this I mean you have to be focused on the task at hand, whether that is testing a bug is fixed, testing a new feature or exploring a new area of the software. In any of these situations you can easily spot a bug or unusual behaviour and decide to investigate a little further. Before you know it you have lost half an hour and wonder where it went. This can have a doubly negative effect in that you have lost focus on your original task and you are probably not 100% focused on the new quirk you have found as you know you have digressed and ought to get back to what you should be doing. Now, when I spot something new I will make a quick note of it as something to look into later when I can allocate time specifically to it, as tempting as it may be to pursue at the time of discovery.
After two months Testing I really feel part of the Development team and appreciate the way the team works. I've learnt a lot and am sure I won't stop learning whilst I'm still a Software Tester. I'm quite sure I have not written anything revelationary as yet. Hopefully over time my posts will offer more insightful views and I'll be able to talk more about experiences that other testers may value.
January 2012 - New Year, New Career in Software Testing
Hello, my name is Andrew. At the beginning of the year, 2012, I entered the big wide world of software testing. Although I am obviously new to this arena I am quite confident that my use of the words big and wide are unlikely to be in debate. However, I welcome any debate or correction on anything I write here.
In my short time in this industry, I have become aware that software testing is regarded as different things to different people. From what I can gather the majority of software testers fall into two broad camps; for the purposes of argument I will call one group 'Checkers' and the other 'Testers'.
The 'Checkers' see software testing as a mundane day job in which they follow a set of instructions from which they have no interest in deviating. They believe they are not paid to do any more than this and have no particular desire to.
The 'Testers' are in complete contrast to the 'Checkers'. They see their job as a challenge and look forward to trying new ways of testing every day. They enjoy their job because they get a feeling of fulfillment from taking on new challenges and doing things differently and with variety. These two categories are obviously rather generalised and at two opposite ends of a spectrum. I think that the reality probably falls somewhere in between these two extreme ways of working.
My previous background is in Telecoms, I won't mention which provider, as I don't wish to confirm what are probably correct assumptions. All I can say is that the cultures of my previous workplace and that of my new employer are worlds apart. Although the work was not software testing I can still recognise that the mindset of most people was anagalous to that of a 'Checker'. I would say that any ambitions people had were made very difficult to realise by the working culture that surrounded them.
I believe that it is largely down to the individual to take responsibility for which way of working they choose to follow. Although it is not the employers responsibility to make an employee think in a certain way, they can do much to support them by providing the tools, resources, training, people and culture which will all make a tester more conducive to progressing as a 'Tester' rather than becoming a 'Checker'. As is probably clear I am very much in favour of staying as close as I can to the Tester end of this scale. I am happy to report that my new employer does fulfill the supporting role I feel I need to enable my testing career to progress and flourish. This very blog is one prime example of this. I have never written a blog before but having read others I feel a desire to record my thoughts, if not for others to read, then at least to keep as a record for myself of my views as my testing career progresses.
In my short time in this industry, I have become aware that software testing is regarded as different things to different people. From what I can gather the majority of software testers fall into two broad camps; for the purposes of argument I will call one group 'Checkers' and the other 'Testers'.
The 'Checkers' see software testing as a mundane day job in which they follow a set of instructions from which they have no interest in deviating. They believe they are not paid to do any more than this and have no particular desire to.
The 'Testers' are in complete contrast to the 'Checkers'. They see their job as a challenge and look forward to trying new ways of testing every day. They enjoy their job because they get a feeling of fulfillment from taking on new challenges and doing things differently and with variety. These two categories are obviously rather generalised and at two opposite ends of a spectrum. I think that the reality probably falls somewhere in between these two extreme ways of working.
My previous background is in Telecoms, I won't mention which provider, as I don't wish to confirm what are probably correct assumptions. All I can say is that the cultures of my previous workplace and that of my new employer are worlds apart. Although the work was not software testing I can still recognise that the mindset of most people was anagalous to that of a 'Checker'. I would say that any ambitions people had were made very difficult to realise by the working culture that surrounded them.
I believe that it is largely down to the individual to take responsibility for which way of working they choose to follow. Although it is not the employers responsibility to make an employee think in a certain way, they can do much to support them by providing the tools, resources, training, people and culture which will all make a tester more conducive to progressing as a 'Tester' rather than becoming a 'Checker'. As is probably clear I am very much in favour of staying as close as I can to the Tester end of this scale. I am happy to report that my new employer does fulfill the supporting role I feel I need to enable my testing career to progress and flourish. This very blog is one prime example of this. I have never written a blog before but having read others I feel a desire to record my thoughts, if not for others to read, then at least to keep as a record for myself of my views as my testing career progresses.
Subscribe to:
Posts (Atom)