One of the reasons I decided to get into software testing was the appeal it had as a job which would keep me interested and not become repetitive and boring, as so many jobs can be. I think software testing can be as interesting as you want to make it, within reason. My main caveat would be that you have a much better chance of achieving job satisfaction if the company you work for has the right attributes of a forward thinking company, such as one which adheres to as many of 'Deming's 14 Points' as possible; which can be seen at the following web page (http://leanandkanban.wordpress.com/2011/07/15/demings-14-points/)
One of the main factors I've found in maintaining interest in is continual reading around the subject of software testing, including not only books specifically about testing, but also books covering wider subjects such as the industry you're in or books about how our minds work. Although not directly related to testing, the knowledge gained from many other areas can be useful to have in the back of your mind when testing. One example is Thinking, Fast and Slow, by Daniel Kahneman, which is a book about how we appear to have two distinct ways of thinking about things, the instinctive gut reaction (thinking fast) and then secondly the more conscious considered approach (thinking slow). I intend to write about my thoughts on this book in a future blog.
I started using Twitter about 6 months ago and have found it a great way to access lots of current thoughts, trends and blogs from people who have vast experience of software testing. There is no shortage of views and ideas and twitter has become part of my daily routine.
Although testing our product is classed as my main role, there are lots of interactions with other areas of the company necessary to fulfil my role as a tester. As we're all based in the same building those interactions are usually immediate and face to face so feedback loops are short and progress is made quickly. We also release new kits on a regular basis and constantly add new, and improve existing features. So although we have a stable product, we as individuals and as a company are in a constant state of progression in terms of continually improving and polishing our skills and our service. This goes not only for myself and the test team but everyone in the company; we are all pulling in the same direction.
So my job not only involves testing, it also involves meetings with the product owners to discuss upcoming product enhancements and planning how best to test them. It also involves working closely with developers to get visibility of the features as they are created first hand and as early as possible. That way I can find out how they intend to code the requirements, with an eye on testability and automation of tests where possible. The more of the predictable, repetitive tests that can be automated the better as that leaves the more unusual scenarios, which only a human tester can carry out and/or interpret. That is the sort of testing I want to be doing as it engages my mind and allows me to be creative.
It's this variety which keeps my job interesting and I hope any non testers who read this can take it from me that getting into software testing is well worth the effort.
Wednesday, 30 May 2012
Sunday, 29 April 2012
April 2012 - Time is Precious
One of the natural consequences of working in software development is that requirements can change at any given time. Because we're an Agile team working in an Agile environment this is not a big problem as it means we are prepared and able to react quickly to the changing demands of management and customers. If we were working in a Waterfall environment (which I've heard about but not experienced for myself) I imagine we would find it a lot harder to adapt to such short notice changes. Therefore, we are not always in control of how much time we will have to carry out development and testing. I don't see this as a negative as it just means we have to be adaptive and flexible. I have also found that it brings out the creativity in the team and makes for a challenging and rewarding experience.
On a team level and also on a personal level this means that we have to make the best use of the, sometimes limited, time we have. In an ideal world customers would work to dates we could set them and not mind if the dates kept slipping out so we could take our time to create even more polished applications. Obviously, in reality, this would never be the case as customers want to move fast and beat the competition to market. They want to have use of a product we can provide them before they find a similar product created by one of our competitors.
To achieve this we must have all areas of the company working together to meet the customers requirements. When this happens and we all pull together to realise what the customer wants and when they want it, it is very satisfying knowing that we are driving the company forward by meeting customer expectations and improving our reputation.
One of the conclusions I am coming to is that there's nothing like a deadline to focus the mind. I'm not thinking of this in terms of cramming everything in, such as doing your revision last minute on the night before the exam. But rather planning what needs to be done today, what needs to be done this week, and also what contingency plans do we have if requirements change. I don't think deadlines necessarily need to be dictated by customers either. When the implementation of a piece of work is not directly customer dependent it should not mean that we rest on our laurels until the next 'real' deadline comes along. If we can commit to a target date for all tasks undertaken then we should be able to have a gauge, at least in our minds if not visible to the team, of how our tasks are progressing in relation to the deadline we have committed to. Commitment based tasks are something we are considering where I work so the results should be interesting. The theory is that our time management and work rate ought to improve as we have a defined static target to aim at.
On a team level and also on a personal level this means that we have to make the best use of the, sometimes limited, time we have. In an ideal world customers would work to dates we could set them and not mind if the dates kept slipping out so we could take our time to create even more polished applications. Obviously, in reality, this would never be the case as customers want to move fast and beat the competition to market. They want to have use of a product we can provide them before they find a similar product created by one of our competitors.
To achieve this we must have all areas of the company working together to meet the customers requirements. When this happens and we all pull together to realise what the customer wants and when they want it, it is very satisfying knowing that we are driving the company forward by meeting customer expectations and improving our reputation.
One of the conclusions I am coming to is that there's nothing like a deadline to focus the mind. I'm not thinking of this in terms of cramming everything in, such as doing your revision last minute on the night before the exam. But rather planning what needs to be done today, what needs to be done this week, and also what contingency plans do we have if requirements change. I don't think deadlines necessarily need to be dictated by customers either. When the implementation of a piece of work is not directly customer dependent it should not mean that we rest on our laurels until the next 'real' deadline comes along. If we can commit to a target date for all tasks undertaken then we should be able to have a gauge, at least in our minds if not visible to the team, of how our tasks are progressing in relation to the deadline we have committed to. Commitment based tasks are something we are considering where I work so the results should be interesting. The theory is that our time management and work rate ought to improve as we have a defined static target to aim at.
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)