Skip to main content

5 Tips Ensuring Effective Context Driven Testing

Great post... Thought I should share!

With so many controversies in the field of software application testing you can never be sure best testing practices will work in the context of your software or application. That’s why the need for context-driven approach to testing has arisen.
And here are the 5 tips on how to smartly perform context-based, or context-driven, testing.

1. Ask Questions

What context-driven testers seem to be emphasizing the most often is the need to ask questions of everybody involved in the project. To fully grab the project’s context and get the maximum test coverage, you should ask a number of questions to stakeholders, development team, your fellow testers, etc.
Asking questions can just as well be your perfect driver of career improvement beyond any specific project. By asking questions constantly and questioning the current status quo junior testers are able to learn from mentors and even the other way round. There is every evidence that successful testers are those who are the most curious and apt to spread their gained knowledge around them.

2. Plan Ahead

No one would probably argue that all the knowledge is of no use if you have no efficient way of putting it in practice. Thus, building a test plan and sharing it with the whole team will make you increasingly efficient, build rapport within the company and generate more meaningful conversations.
It doesn’t mean you should expect feedback from every person in your organization, of course, but you should share the initial test plan details with the foremost stakeholders to give them idea about what type of return to expect and show them there are some fixed guidelines your team is following and any changes of their own plan can impact your testing strategy greatly.

3. Adjust Your Plan

Once you’ve got a plan you should in no way expect it’s ultimate though. A software project goes fully as expected in very rare cases, so you must be ready for possible adjustments. If you fail to be flexible to some extent, your test strategy is likely to lead to frustration and unthorough test coverage. With changing schedules, newly added features and arising priorities, it’s a must to adapt your strategy accordingly.
Meanwhile, make sure that after showing your testing plan to stakeholders you aren’t made to go backwards and make up for earlier stage project mistakes. Since your ultimate goal is achieving the possible maximum test coverage under parameters at hand, you don’t have to stick to the plan if those parameters are ever-changing for such a plan doesn’t serve your goal any more.

4. Let Stakeholders Decide On the Project Completion

For everybody’s sake, it makes sense to hand over the power and responsibility to the stakeholders to decide the timeline of the project. It’s their job after all and this also releases testers from the responsibility to decide whether they should hit or miss the deadline.
Testers often forget that their direct responsibility is to test the product as fully as they can given the limitations set by stakeholders, and to then provide as much data back as possible.

5. Avoid Applying Any Practice Blindly

This is apparently the pillar on which the whole context-driven ideology stands. That is, best practices and tips won’t work in every situation and in the end it will all boil down to how much you can do with the information at hand at any given moment of time.
This kind of flexibility is exactly what will keep context-driven testers elevated to the new heights in their field for the coming decades.


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …