TestToTester

Web test heuristics


Hi All,

Thanks to Rob Lambert aka the social tester’s “36 days of Web Testing”. I have put together test ideas I have collected over the years for web testing in a mind map. For now I call it the web test heuristics.
I have attached a .pdf version and .mm version of the mind map so if any of you want to add in more test ideas please feel free to do so and share.


I would like to thank Rob Lambert, Daily Testing Tips, Santosh Tuppad, Weekend Testing, Joe Strazzere, Josh Poley, The legendary test heuristics cheat sheet by Elisabeth Hendrickson, James Lyndsay, Dale Emery and many others for sharing their test ideas.

Thank U Codecademy & Udacity


Hi All,

I share with you all Codecademy & Udacity the two brilliant sites for someone interested to learn programming. What I like about the two sources is that a lot of thought, hard work has gone in to developing the exercises and assignments on them.
I have been using Codecademy for close to 5 months now and Udacity for approximately a month and this is what I feel

Codecademy:

I came across the site Codecademy when I wanted to learn Java Scripting. I do not remember which blog or tweet pointed me to this awesome source but I am extremely thankful to whoever shared the link.
The site is extremely easy to understand and I guess it takes just over a minute for you to start typing your first program. I love learning when it’s hands on and less of theory and that is exactly what I found in Codecademy. You read a paragraph and then you code. There are a lot of exercises to practise and a lovely forum to help you around when you get stuck.
The site has now introduced more chapters like HTML, CSS, JQuery, Python(buggy, still in beta though).

Udacity:

Udacity blew my socks away when I signed up for their first course “Introduction to Computer Science”. I clicked on Introduction, the first chapter in the class and there they were my two instructors for the course. David Evans is a Professor of Computer Science at the University of Virginia and as of now he is my favourite professor. I am amazed how easy he makes it for us to learn programming. I had tried learning python at the start of my career but did not follow it up because I got bored after reading till dictionary. This time around I am flying thanks to David Evans and his brilliant team. The course is extremely engaging and interactive. I make it a point to at least learn one chapter a day and it is so possible!
Similar to Codecademy Udacity also has a brilliant forum that is very helpful and responsive.
Other than computer science and programming there are courses in physics, statistics, maths, AI, cryptography, etc

I appreciate and thank everyone associated with both Udacity and Codecademy for bringing such an AWESOME, EDUCATING, BRILLIANT course for FREE so everyone can benefit from it.

Thank YOU Codecademy and Udacity

If you have come across other sources which you feel is helpful for a beginner to learn programming please share it. Thanks

Test Case Syntax


When reviewing a test case document (now don't ask me if it was positive or negative or division or) I could not stop noticing just how many times the words ‘verify’, ‘check’,’ is displayed’, ‘should be displayed’ is used. A pattern repeats itself which I am tempted to call the “Test Case Syntax”

Syntax:

verify << copy acceptance criteria >> is displayed in <>

Or

verify << copy acceptance criteria >> should be displayed in << copy acceptance criteria >>

Or

check if << copy acceptance criteria >> is displayed in << copy acceptance criteria >>

Check with your test lead to choose one of the formats

Example:

//Test case to verify forename, surname, post code is displayed in accounts screen 
verify the fields forename, surname, post code is displayed in accounts screen

This is how intricate development of test cases is. I do not understand why some testers continue to do this and their test leads, managers want them to do this.

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow.

Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software.

Regression Checks

At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the difference between the two] This exercise helps us think better and ask more questions to the product owner and business people. It also bridges the gap between testers and developers in understanding requirements and developing test ideas. To me, this is not just an activity of developing feature files, it’s that phase when testers and developers together learn a lot from one another. Developers start to appreciate test ideas from a tester, his/her thoughts, strategies etc. Testers learn a lot technically about design, logic, memory management and tons of other stuff. I strongly believe that this pairing up helps in bug prevention as well. These feature files developed in Gherkin Syntax are now binded to the code a layer below UI and checked in. The team can decide if these tests have to be run automatically every time a build is made or manually as needed.

This is one of my answers to regression checks. Its brilliant, isn’t it? All tests are automated at the start of a story. Even before a code of line is developed? It’s great, but it does come at a cost – what these tests can do is checking and not testing. Also it takes time for both developers and testers to learn to develop feature files together. We did fall into trap of developing bulky, long and hard to maintain feature files initially. However, we put in a lot of effort to make it light, maintainable and stable.

To me regression testing is regression checks & regression testing. I am not trying to bring in my own terminology here. I am just extending the idea from Michael Bolton ‘Testing v/s Checking’. With feature files we now have automated regression checks. I think it’s very important for a team to recognize the value in anything they have invested their time on. We discern the limitations of feature files and the value it brings. So we started documenting regression test ideas using mind maps.


Regression Testing

We develop checklists in mind maps before we move a story to “done”. We call it ‘regression map’. As I write this, I think we need to have a better name for this document. Doesn’t the word ‘regression’ means decay, weak? A bit of investigation might help here.For now, let me stick to ‘regression maps’.

Regression maps can have one liners, couple words, screen shots etc which aid memorability when one looks at it. The regression map also includes paths, tests, ideas, risks and heuristics documented when we move a story to “done”. All this, when it’s fresh in our minds. At the end of a sprint or prior to a demo or when we need to run regression tests quickly, we refer to regression maps to drive our time boxed exploratory sessions.

This simple exercise of recording test ideas in a mind map helps us focus on critical tests and requirements when exploring a feature for regression. It is also the easiest document I have ever maintained. I do not want to get into more detail on how we report or maintain versioning among testers here. In addition to aiding regressing testing, regression maps help in “show and tell” demos. It’s also a great document to pass to support/maintenance team during handover.

With the regression checks and regression testing in place, our team now has a convincing story to share with our management. There is still a long way to go, however I think this is a good first step to move forward. What do you think?

Further Reading: http://www.developsense.com/blog/2009/11/merely-checking-or-merely-testing/

Test with me @

Tweets