There are tons of good articles on Sticky Minds. This is one of them…
It’s been a while since I did anything for charity, so this year I decided to punish myself.
Yesterday, I took part in and completed the Total Warrior 10k 2013 – the worlds toughest 10k in Shap, Cumbria.
It is the toughest 10k on earth and involves doing some wild and crazy things like running through fire, climbing over obstacles, swimming through muddy water, navigating an electrified pit and all kinds of other wet, muddy, burning punishments.
I completed the course in 1hr and 41 minutes (last years average was almost 2 hours, so I think I did pretty well).
I have been trying to raise a couple of hundred quid for a great charity; The Butterwick Hospice. They really helped out my mum when she had Cancer and basically went out of their way to help make things easier for the whole family. They are run solely on volunteering and donations so its a very worthy cause.
If you would like to donate and to help me reach my £200 goal, then there is still time.
Head over to justgiving.com/craigearlwarrior and pop in any donation you can. From 10p to £10 it all makes a difference!
Have you ever been working on something and realised that you are not getting anywhere fast?
Are you finding it hard to motivate yourself to go the extra mile?
Have you thought of setting yourself goals to motivate yourself to achieve more?
I set myself goals all the time at work. Daily, monthly, yearly; I set myself goals and use checkpoints and to do lists to help me stay on track and motivated at work to do those extra things that are not necessarily part of my ‘role’.
Outside of work, I don’t tend to really set myself any goals. Sure, there are things that I want to do but I usually just make a to do list and check things off as and when I get round to completing them.
Recently, however, I have started to see how setting goals can really start to get results and how bringing my attitudes at work into my personal life could really push me to get more done.
I have been doing some training for Total Warrior 2013, the world’s toughest 10km run (see the whole course info here and when you see how difficult it is, sponsor me: JustGiving.com/CraigEarlWarrior).
I started off by just going out for runs a few times a week. I never set myself any goals or targets and it was going well, but after I reached running 3km in 20 minutes, I felt like I got stuck. For a few weeks I wasnt getting any faster or a lot further and I didn’t feel I was improving.
I couldn’t understand. I was running multiple times a week, I was eating healthier and sleeping better. It came down to the fact that I wasn’t pushing myself. By just tracking my runs and not setting any goals, I wasn’t motivating myself to do more.
There is a ton of information out there on the web about setting goals and achieving more; there are tons of ideas, articles and even websites devoted to it (MindTools has tons of info on goal setting). But, it was an article on ZenHabits about how to keep goals as simple as possible and to focus on one goal at a time to really get results that really got me into the idea of setting personal goals.
I started to set myself one goal for each run I did. “Do 3km 1 minute quicker than last time”, “Do 5km – don’t focus on time”, “Beat my last run time/distance”, “Beat my fastest Km on this run”. By setting one simple goal for each run, I started to see a huge improvement. After a week and a half of setting simple goals, I have pushed myself to do more and am now doing 5km in 27 minutes.
The results I have gotten in my running is making me want to revisit how I set goals at work and look at how perhaps focusing on just one goal at a time could help me get further, faster.
How do you set goals? What do you think works best?
So, its been a while since I made any blog posts.
It has been a super crazy time recently with trying to sort our wedding plans (only 6 weeks left to go til the big day) coupled with lots of stuff going on at work and outside of work too.
I am in the process of writing a proper blog post but in the meantime I thought I would share an interesting blog that I have been reading (the article on why Agile failed in the public sector is particularly good).
For anyone interested in Agile, I recommend you check out the Aterny Agile Blog. Its definitely worth looking at.
Answer the following.
When you look at your existing set of regression tests do you:
a) shake your head in disappointment
b) run away in fear
c) scratch your head in confusion
d) all of the above
How many of you chose the bottom answer?
Regression Testing seems to be something that we all want to improve on but that we don’t do a lot about. As a result, we can have huge regression tests that take days to run and when it comes to maintaining them it is hard to know where to even start.
Now, there is a lot out there written about regression testing but not very much of it is very user-friendly and for anyone just beginning to look at regression testing it can be a bit scary.
There is nothing to be afraid of.
Regression Testing is running a set of tests (ideally automated) against an existing system to confirm that the introduction of new code/features does not affect existing functionality.
Let’s say you have a blog page. On this page you have your posts, a ‘follow’ button and a ‘share’ button and that’s it. Your blog is live and it was thoroughly tested before it went live so you know it works. Now, lets say you introduce a new feature; a search bar. Obviously, you thoroughly test the search bar and everything seems like its working just dandy. This is the point where you would run your regression tests to ensure that the introduction of the new ‘search bar’ feature hasn’t affected any of the existing functionality.
The creation of regression tests should start as soon as there is anything to test at all and should initially include all tests for any new or changed functionality. As more features and new functions are introduced to the software under test, more test cases to check new or rewritten code will be scripted. As a result a regression test suite can grow very rapidly. Regression test suites can become so big in such a short period of time that it can be nearly impossible to run manually. For this reason, regression tests should be automated.
One of the biggest problems that I have come across when dealing with regression testing is choosing test cases for inclusion. This is not always easy. In fact, it is probably never easy. I don’t know if there is a set way of choosing tests for inclusion in a regression test suite (I am yet to find anything that provides lots of detail on how it should be done) but this is how I would do it…the Bearded Tester’s ‘Pie of Regression’.
So, as you can see, the majority of test cases in the regression test suite should be for the most commonly used features and functionality.
This should be followed by ‘found and fixed’ defects. By this, I mean functional bugs that have already been found and subsequently fixed. Fixed defects seem to have a habit of popping back up and regressing once new code is introduced so I think this is a must have area for any regression pack.
Finally, the remaining pack should include the lower risk, complex functionality and less commonly used features.
It doesn’t stop here though. Regression test suites are continuously evolving sets of tests. Once the regression pack has been decided then it needs to be continuously maintained.
As new features and functions are introduced, the new test cases for the release should become part of the regression test suite to be ran each time a new version of the code is introduced. Similarly, as older functionality is replaced, older test cases may need to be removed in order to keep the regression suite both efficient and up to date. Essentially, as the code changes and evolves, the regression pack needs to adapt and reflect the application.
In order to be most efficient, as the regression pack grows, then it could be split into different functional areas. The regression test could then be ran in stages (instead of one giant ‘over-the-weekend test run) and limited subsets from the test suite could be ran individually to strategically target areas that have changed. The individual subsets could also then be used to perform targeted testing in order to build confidence in other areas of the application.
This is not necessarily the right way to do it but I don’t think its a bad strategy.
What do you think? How would you choose your regression pack? Is there a right way to do it? Are there other areas that you would include?
So, my plane leaves for Australia in a few hours…
I will most likely be taking a break from posts for around a month whilst I am travelling.
In the mean while, if your in desperate need of a beardy post, check out this little introduction to me on the Software Testing Club blog. I have been featured for being part of the team :)
See you in February!
December; yes, it’s Christmas, but it is also the annual time to reflect on the year and look at what you have achieved. So , inspired by Trish Khoo’s latest post, I thought I would try and briefly recap on my 2012…
- Promoted from a Junior Tester to Agile Test Analyst
- Proposed to my lovely Partner (now fiancée)
- Booked our wedding (and got a pretty snazzy suit too!)
- Became an uncle!
- Started a blog (and actually followed through with regular posts!)
- Learned how to write HTML & CSS
- Joined Software Testing Club
- Became part of the Software Testing Club Team
- Created a popular SQL guide (now downloaded over 500 times! Awesome!)
- Wore a onesie for the first time (and whilst at work, strangely!)
- Had the opportunity of Team Leading for last few months
- Learned all about Session Based Test Management.
- Looking to learn more about Business Analysis & Project Management (a possible future role perhaps?)
It’s definitely been a busy year and definitely a pleasing one!
I’ve learned tons of new stuff, networked with a load of cool new people and am getting involved in some really fun and interesting projects.
I will be kicking off 2013 with a month long trip to Australia in January and hopefully will be making some real in-roads at work upon my return. All in all, I am really looking forward to what 2013 brings!
Merry Christmas & Happy New Year to All!
Where do you see yourself in 5 years time? Do you know where your going or what your going to be doing? Do you even know what you want to be doing?
Our company recently had to let a lot of people go. After the initial shock then relief at not being one of the ones who was let go, I started to think about myself. Questioning where might I be in a few years time?
Truth is, I had no idea. Having only been testing professionally for 2 years (almost), I had never put any real thought into it. Of course, I knew I wanted to succeed and to learn more and grow as a tester but I hadn’t really planned that far ahead or set myself a goal or aim for where I wanted to be.
I felt a bit lost.
I didn’t even know what career paths were available for a tester a few years down the line.
I started to look around at roles that existed within the company itself. Senior Tester, Test Team Leader and Test Manager were the obvious ones. I did a little digging to find out a bit more about them.
Senior Tester and Test Team Lead appear to be very similar roles. They are still involved in testing activities yet with a few extra duties. They are responsible for preparing test strategies and timescales, attending project meetings, escalating team issues and taking responsibility for team performance. It seems like a Senior Tester would do everything that a normal tester would do but with a lump of leadership skills to take the team forward.
A Test Manager on the other hand seems to be fairly removed from any actual testing and is much more a micro-management role. Test Managers would set objectives, manage one to ones and appraisals and report on the teams’ progress to corporate management.
When I started to look around the office, I started to see more options appearing.
There is always the option of going full circle and becoming a Developer. As a tester we frequently get to look at varieties of code and with free learning resources such as Codecademy, Udemy and Khan Academy it can be fairly easy to learn programming.
There is even the option of becoming a Business Analyst. Testers have a broad overview of the products that they test and those working in Agile environments are becoming more and more involved with the requirement gathering and changes from the business.
Another path to investigate could be a Usability Expert or Product Expert. Having such a profound knowledge of the end-user systems and customer workflows along with knowing what features and fixes are most important to customers can make you an instant expert. Focusing on user friendliness and raising interface issues as part of your testing is also a step in the direction of usability expert.
Coming back to the testing role, after a number of years experience in a multitude of companies, there is always the option of Test Consultant. Once you have a detailed understanding of a plethora of systems, tools, strategies and processes you could, in theory, consider yourself an expert in the field and wade into the waters of working alone or even mentoring teams.
It seems there are a multitude of avenues to explore, but as yet, I don’t know what I want to do.
If I focus on becoming a better tester, will opportunities present themselves or should I be chasing them?
What do you think? Do you have a clear view of what you are going to be doing in five years? Are you focusing on becoming a better to tester or are you aiming for a specific role? Have you already achieved the role you wanted? Did you chase it or did it come to you?
Ok, so a while ago I started looking at blogging some basic lessons on SQL for those testers (and perhaps developers) who haven’t used SQL before.
I only blogged a couple of lessons but I got some good feedback from the testers at work so I thought it may be useful to put together a printable guide that they could keep with them and use as both a learning aid and a reference later on. Anyway, I have linked to the SQL learning guide below (the link will open a new window and the guide is viewable online with the option to download / share within the page).
Hope you all find it useful, any feedback would be greatly appreciated!
In the current project at work, I am part of a stream that is picking up and fixing production defects and technical stories. As far as the testing goes, it is quite heavily exploratory work alongside a lot of regression and automated smoke testing.
I wanted to find a way of doing better exploratory tests. Although I have been testing for nearly two years, I still have a lot to learn and perhaps my experience and intuition could be further developed.
I had heard ‘Session-Based Test Management’ banded around before but (like many things) it was something that I put on my endless ‘to read about later’ list. Needless to say, I didn’t get round to reading about it later. So tonight, I did a quick read up on it and it sounds like a great way to perform exploratory testing.
Essentially, Session-Based Testing (SBT) is about having an uninterrupted 1-2 hour exploratory testing ‘session’ with a clearly defined goal (or ‘charter’) followed by the production of a report and a discussion with a manager or other testers about the session. You can read more about it here or on James Bach’s blog (the original creator of SBT).
Exploratory Testing can be seen by some as a case of ‘just have a play around and see what bugs you can find’. This is all well and good except for two things:
- The knowledge, experience and intuition of the tester will determine the quality of the exploratory testing.
- Having no defined end goal for the testing can leave you feeling ‘defeated’ if you dont find any bugs out of it.
This is where SBT comes in.
Although experience will always be a factor in exploratory tests, SBT defines a goal for each period of exploratory testing, giving the tester both a sense of purpose and aim in each session.
Before any testing begins, the test team create a ‘charter’. Charters can be created by looking at results from previous sessions, derived from specifications or test plans. An example charter could be as simple as “Explore the Online Account Webspace and report on Broken or Dead links” or it could be something much wider and more detailed.
Once the charter is in place, the session can begin. Ideally, a tester would plan a dedicated amount of time to be spent testing and would not be distracted at any point during the allocated time. The full attention should be focused on the aim of the session. The tester would create and run test cases based on intuition and experience or even any frameworks and supporting materials they have. The tester would then record their progress however they can, whether this is through the use of written notes, screenshots or anything else they want to use. The key is in the report.
After the allocated time is up, the tester records the test session in a report which would include all of the information they have up until that point. Starting with the charter, they would also include the area tested, steps they followed or notes on how the testing was carried out, a list of any bugs found or any issues or causes for concern, any files/screenshots/evidence that the tester used or created during the session, the percentage of time during the session spent on testing, bug investigation, reporting, setting up or other non testing activities and finally, the session duration.
After the report has been completed there is a final part of SBT which is the debriefing. The tester should then have a short discussion with either the manager or other testers about the session report. The discussion should cover what happened during the session, what was achieved, what problems got in the way of testing, what still remains to be done and finally, what the tester felt about the session. Jon Bach uses the PROOF acronym to structure the debriefing.
One of the key benefits of SBT is that sessions can be as long or as short as you like and this means that testers can both fit useful exploratory testing into any downtime they have as well as adjusting their testing to meet the needs of the project. By using SBT for exploratory testing, it can even make metrics easier by tracking time spent testing in each area along with the number of exploratory sessions completed.
Session-Based Testing sounds like something that could really provide benefit to projects and test teams (especially those working in an Agile environment) and I will definitely be suggesting this to the team at work and trying to use this going forward.
I can’t wait to get my teeth into this and really give it a go…it could be “sen-session-al” *cringe*