Category: Testing

Any discussion on testing techniques

Management, Testing

A Change in Perspective – Moving from Tech Lead to Manager

I’ve been in Software Engineering since I left University as a graduate in 2006 and have performed many roles such as Software Developer, Scrum Master, Build Engineer and then in 2010, I moved into Software QA. At that point, I had several awesome mentors who I owe so much for fueling my love and passion for all things Testing/QA.

Fast-forward 6 years and I had moved teams and become the QA Tech Lead in my new team which are an Operations Engineering team. I finally got my head around the complexities of the systems we were responsible for as a team and was starting to move the teams focus to processes and ways in which i felt could move the team forward. So at this point, I felt I had got to grips with the production process.

In 2017, I started working towards becoming the manager of the local team and also taking on hiring a new team for a second project. That team were to be located in Ireland and I took on building that team from scratch. Hiring that team was my first real taste of management responsibilities. I had previously been involved in hiring from a “who would I work well with?” perspective, where as now, I was looking at the overall dynamics of the team, how they fit salary wise with the rest of the team and whether there was anything about them that might make them difficult to manage. This really opened my eyes to how things would change with my new role.

Over the next year or so, to now, there were several other parts of the role which opened my eyes to there being more differences than me just taking on line management duty of my team mates.

1. Trusting the team to be Technical

Once I got the Irish team set up, it became obvious that I couldn’t be the technical point of contact for two teams and had to start backing away from the deep down technical details and trust the teams to pick that up. It really became clear that I had to trust my team to pick up the details and I needed to enable to do them that.

 2. Time is for your People

I soon learnt that to enable the team, it required them to be my main focus. Therefore, giving them all time with me, through 1-1s and spending time sat with them at their desks, meant that I started working longer hours to give them the time they wanted/needed and then still performing the other duties i still needed to do. Over time, this has got easier to manage, but with two teams on completely different projects, it’s certainly been a challenge.

3. Difficult Conversations

One element of the role which I needed to adjust to, was having to have conversations which I wouldn’t have previously had to worry about. It really was about working out where the line is in situations and then being strong enough to talk to team members when that line is crossed. Then also being consistent to ensure that everyone is treated the same way.

4. Technical Advocate rather than Technical Leader

With having to trust the team to take on the technical leadership role, it became clear that although I still need to understand the technical detail to some degree, I would give the team the freedom to advise me on technical directions, then be their advocate when talking to others about the technology, ensuring the team know I have their back and support their decisions. While also still offering my opinion and helping to guide the team, the directions of the team would not be down to just me.

5. Someone Resigned! Was it Because of Me?

This was a tough lesson, and caused a lot of over analysing and over thinking. But ultimately, I had to try and not take it personally. Then, secondly, try to turn it into a positive as it would give me a chance to re-build the team in the way that I feel works.

6. No Favourtism

Before I became a manager, I felt I got on well with all the team I worked with, but becoming manager changed the dynamics. Some suddenly started being more formal with me and I couldn’t understand why as I hadn’t changed. There were some members who I found very easy to talk to, but I had to show that I valued all members of the team. That meant backing away from socialising with them regularly over lunch or out of work and only really doing so when all the team is present.

The Future

I love my role and I love the fact that I am learning and developing every day. I value the work my team are now able to do, with my guidance and seeing them become more self sufficient, means I am starting to be able to focus on more strategic work and still see my teams move forward, knowing I have their back, encouraging them to do the best they can.

 

 

 

Testing

It’s Been A While – A #MakeATester Update

In Summer 2016, i kicked off the #MakeATester project on social media, asking for the community and beyond to tell me what skills are needed for new testers to get started in a testing career. I published the results in early 2017 and since then, have been working hard to try and push the awareness of the project with it’s original aim, which was to get more awareness of Software Testing in Universities, enabling graduates to consider testing roles when they leave university.

So what has happened since then?

  1. I submitted a talk to several conferences (maybe i haven’t quite got the hang of the talk submissions for some conferences) and in March this year, i have a slot at UKStar 2018. As part of a “Conversation Track”, I get to share my message and urge others to consider reaching out to universities.   https://ukstar.eurostarsoftwaretesting.com/submission/if-the-universities-wont-help-us-how-do-we-makeatester/
  2. I have started reaching out to universities to give careers talks on testing. Some have been re-buffed with a “sorry, we don’t teach that!” message. I have two lined up in the next few months. One of which is a pure Software Testing careers talk, the other is more focussed on the CyberSecurity careers, but I am fully intending to have a few slides mentioning Testing 🙂
  3. I’d like to find other methods and media to get this message out further, so if anyone has any ideas, please get in touch, either through the blog, or through my twitter account (@siprior)

What would I like next?

I have two things I would like to start from here:

  1. It would be good if I could add a bit of meat behind my message to Universities and as part of reaching out to them and offering career talks, I’d like to also provide the universities with the types of topics they should be covering if they run a Testing module or two.
  2. I can’t do this alone, I would love for all of the testing community to feel empowered to reach out to Universities and other talent who may be unaware of testing careers and would be good fits for roles, and let them know of the rewarding options they have in front of them.

Getting new people into testing should not be as hard as I have found it when hiring for my team.

We have the resources available to get people interested in testing. Podcasts, blogs, online courses, videos, and an immense community always willing to help people with their testing questions.

Now it’s time to start building on what we have and start looking outwards from our community and drawing more in.

Am I barking up the wrong tree? Am I making a mountain out of a molehill? Maybe elsewhere, this isn’t an issue. Let me know your thoughts. 🙂

Testing

What Skills #MakeATester – The Results

Last August I kicked off a little social media project on the back of my shock at the lack of content on University syllabus’ for Software Testing or QA. With this, I asked the increasingly awesome Testing community to list the skills/attributes that are required to make a good tester.

Life then kind of took over and my second son was born in December, so it has taken longer to collate all the responses from Twitter, this site and also responses on Post-It notes from the #AylTest event which i kicked it off at. After spending time merging categories and ordering them, there were 28 skills defined and over 400 votes. I can’t say I’m hugely surprised by the outcome but it does make for interesting reading (at least in my view 🙂 ).

So I won’t bore you with the full list, but let’s look at the top 5 skills/attributes which were voted for:

5th  – Coaching & Facilitating – 9% of votes

Being a good tester also requires the ability to mentor more junior testers, coaching them through any struggles they may have. Also from experience, it is usually QA/Testers who end up stepping forward and acting as Scrum Masters or facilitating project meetings and discussions, just because they feel more comfortable doing so.

It might also be a possibility that they may have to work with the developer to teach them good practices around unit testing or just trying to ensure their code is testable.

4th  – Ability to Continuously Learn – 13%

After 10 years in Software Engineering (last 7 in QA/Testing), I can honestly say that in the last few years, I have genuinely felt like I have learnt a new concept/technique/tool atleast every week, maybe even more frequently. This is largely due to the mass of amazing information and discussions that occur through social media or the testers slack channel or discussion forums through the Ministry of Testing or other sites.

Also, with the rapid change of technology, it always helps to be one step ahead and understand tools and techniques which will help you tackle the next app/web site/system that needs testing.

2nd = – Problem Solving & Analytical Thinking – 14%

Every piece of software is a new problem to solve as far as ensuring you have tested it enough to mitigate any risks and validate it is of a shippable level of quality. This of course then requires a degree of Analytical Thinking to understand how to overcome the problem. There isn’t one particular way to do this and every tester may have a slightly different way to tackle the problem

2nd = – Good Communication Skills (Written, Verbal and Listening) – 14%

Needing to be able to articulate well is a must have skill for all testers. Whether it be a defect report, a test case, test charter or even just discussing concerns with a co-worker, it is crucial that any communication is clear and concise to avoid any confusion or misunderstanding on the back of what was said/stated. It is therefore also crucial that a tester is able to listen to any response and be able to communicate further if needed.

1st – Curiosity & Asking Questions – 20%

If a tester isn’t curious, then they won’t ask the right questions, if they don’t ask the right questions, they won’t be able to test the software effectively. These questions could be asking the developer why things are working in a certain way, or it could be asking questions of the software during exploratory or test case/scenario identification. Without this ability, i would fear for the quality of the products being shipped.

Asking questions is clearly the most important skill when it comes to testing, and it starts at the conception of a project. From day 0, the tester can start raising questions and queries which will get other members of the team to think differently and look into ideas which could lead to a higher quality deliverable.

So what’s missing?

There have been a lot of debates over the last couple of years over whether coding skills are needed for testers. My view is even if you can’t code, you should atleast have the ability to read code and understand what is going on to be able to have a fighting chance at testing effectively. But my data shows that only 5% of the votes were for this skill so it would suggest that it may not be as high on peoples list of desired skills as i first thought.

 

What Now?

The next step for me is to find a way to look at showing anyone interested in testing roles that it isn’t necessarily about the technical skills you need, but more about making the most of the soft skills you may already possess. Being able to work through problems, communicating clearly and asking the pertinent question would be a huge asset to to QA team, possibly more than one individual who could automate all the testing.

I would love to reach out to students who are studying  a Computer Science degree course and show them that Software Testing is an option for them and maybe eventually even push the universities to start including content in their courses.

Testing

What Skills #MakeATester? – A collaborative approach to help future Testers get a chance.

So as my last post showed, Universities aren’t really considering Software Testing as a core topic of Computer Science degree courses. Therefore, by the time graduates are looking for jobs, testing isn’t really on their radar. The same can be said for potential testers who haven’t got degrees. As shown in a recent “Let’s Talk about Tests, Baby” podcast and the following survey, a fair amount of people fall into testing roles, some have qualifications in other areas sometimes not even related to IT atall and end up in software testing. This is not necessarily a bad thing, but surely there is a way in which people may want to be able to train themselves for that first Testing position, rather than only accidentally falling into the position? I know from my own experience, I learnt what QA did while still working as a developer and then transitioned across to become a QA Engineer when the opportunity arose. If I had known the areas to focus beforehand, maybe I would have been better prepared to decide the path to take at the beginning.

So, i don’t know whether this has been done before, but I intend to collate a list of ‘ideal skills’ to become a tester, these may be soft skills, more technical skills or any one particular ability which is useful in the role of testing. Using this amazing Testing community, we must be able to come up with a sizeable list of ideas. I will then cut down the list to the top 15-20 and hopefully use it to encourage students or other non-testing folk who may have the skills that Testing is a genuine option for them.

So how can we create this list?  Two options for you:

  1. Tweet #MakeATester to @siprior with your suggestions
  2. Fill in the form below

I can report back in a month or so on what my findings were

 

Testing

Software Testing at University – Is it an Option?

When I left university 10 years ago, I had no clue I would end up in QA/Testing. I didn’t even realise it was an option! Looking back on my degree course (and I really enjoyed my degree), it was very Programming heavy (C#, C++, Java and Prolog all taught) and testing was only taught as part of the Software Engineering module where maybe a week or two of lectures were given and there was a group project where one person was responsible for ‘testing’.

So, ten years on, have things changed? I’ve looked through the course content for the top UK universities for Computer Science to see how much content on Testing is available. Here are my findings:

  • The first University to have a module on ‘Software Testing’ was Swansea (ranked 11th)
  • Newcastle (ranked 14th) has a ‘Software Engineering Professional’ module in year 1 which covers ‘testing and debugging tools’ and a ‘Software Engineering’ module which covers the testing fundamentals
  • Surrey (ranked 8th) had a ‘Software Quality’ module in it’s ‘Software Development for Business’ degree
  • St Andrews, Oxford & Cambridge have modules on Model Checking which is not strictly testing but instead a pre-execution activity.
  • 6-7 of the top 10 have Software Engineering modules where Testing was a line item in the module description

So in a short answer, not a great deal of universities cover testing in any great detail. Swansea and Newcastle cover more than most.

I imagine a lot of students are leaving the top universities thinking Programming or Software Development are the main options for careers. How can it be changed? The software industry has evolved over the past few years to realise the important role testing plays in the software lifecycle. Can universities be made aware of this too?

I’m potentially going back to my university to give a careers talk in the near future and really want to paint this picture of the importance of testing. If students could see and feel the atmosphere at conferences such as Testbash or at Tester Gatherings up at down the country and feel the passion that so many testers feel for the job they do, it would open their eyes and make them realise the potential of other careers available to them.

Testing should be seen as an equal to development or at least a close second but a lot of these degrees are portraying it as a much smaller element of the SDLC.

I think maybe the issue with most/all Computer Science degree courses is that they are very Programming heavy, maybe they could teach slightly less of that and cover a lot more topics not just Testing.

If anyone has any suggestions for stuff I could share with Students about testing, if and when I get to give a careers talk, please comment here or tweet me @siprior.

 

 

Testing

Making Your Testing Effective

I’m sure most of us will have worked on projects where without having to do any particularly extensive test scenarios or having hardly dived into exploring the product, you find things that break that would be immediately obvious to the customer. This kind of project depresses me (even though it is fun to find defects), I like nothing more than a project where I struggle to find defects and all user scenarios work correctly, as this means (generally) that the code has been well thought out, it usually also means I have been able to work alongside the developer and ensure that quality has been built into the code and of course it may also mean that the customer has been listened to and the requirements have been developed against. As mentioned in a previous post, for me, testing starts as soon as I have started thinking about a project, so if we have got to a point where user scenarios are being met and minimal defects are being found, this would suggest I have done a reasonable job of asking the right questions and verifying that all the features work correctly through whatever method of test execution I have followed. But if I did have to raise a lot of defects, and the user scenarios didn’t work, does that mean my testing wasn’t effective? Of course it was, if it hadn’t been effective, I wouldn’t have found the issues and proved that the level of quality needed for release wasn’t there. Testing can be effective in both scenarios, it’s just about preparing your testing in the right way, so you can have confidence in what you are doing, regardless of the standard of the product under test.

So how would I define ‘effective’ testing? I would suggest these ideas:

  1. Know The Product – Read any documentation you can. Ask any questions which will help you understanding (however stupid they may seem, if you need to know the answer, then how stupid can it be?). Review code and unit tests to understand the flow of the system. Spend time exploring the paths through the product so that you are familiar with the expected routes from end-to-end. Having full confidence in the product will ensure you know what to test.
  2. Understand the Risk – Fathom out the areas of the product which pose the most risk to testing and ensure that these are prioritized before you start writing any scenarios. Understanding how to mitigate the risk for each of these will enable you to focus on testing the areas fully.
  3. Document Your Plan of Action – Now that you feel confident about the product, find a way which works for you to document your planned testing. This may be a mindmap, a word document or even scribbled on the back of a beer mat ;). What is important is that you have some way of being able to look at what you have thought to test and identify if there are gaps.
  4. Review with Peers and Stakeholders – Now maybe that beer mat wasn’t the best idea. It would be easy to hand your test plan over to someone else to look at, them to skim through it and hand it back to you without comment. Reviewing for me, would ideally mean walking through the test plan as a discussion with team members (dev & testers) and also with the people who provided the requirements. Talking through the plan with others will highlight how confident you are with what you are going to test, you may find additional scenarios to cover and also maybe get some suggestions on how to improve your approach.
  5. Be Prepared to Evolve Your Testing – There’s a good chance your original plan will not be exactly what you end up completing when executing scenarios. There will be additional options or configurations which may not have been obvious before. Don’t be afraid to divert from the plan, it should never be a hard and fast commitment, it should be seen more of a ‘Plan of Intent’.
  6. Review Results – When you have completed your test plan, go through the results again, ensure you understand the outcomes. Discuss with another team member who may highlight something that you hadn’t initially noticed.

No two projects may be the same, and there may not be one particular approach to Test Scenarios which can be used for all projects, but following these suggestions will hopefully ensure you have confidence in your testing and will give you a definite view of the quality of the product.

The ultimate goal is to ensure that your testing is doing it’s job, it’s finding defects if there are defects to find and it is proving the good quality of the product so that the team can have a distinct understanding of when it is good to release.

Testing

The Testing Mindset

For me, Testing is a mindset, not just a role that needs to be performed. Testing isn’t just part of the development cycle, it should be ingrained in every stage. Every aspect can be ‘tested’, whether that be requirements, architectural diagrams, code, unit tests, test scripts, user docs etc.

When Does Testing Start?

If I’m starting work on a project, I am starting to test from the moment I am assigned. There is a good reason for this, I feel that testing is more than just writing test plans, executing test cases, developing automation or even exploring the product in a time boxed exploratory session.

Testing isn’t just Test Cases

From the moment the first discussion about a new product or feature starts, I am testing, I am learning about the changes, I am understanding the features, I am thinking of pertinent questions which will both aid my understanding and assist development with design decisions and enhancing the testability of the code they will be producing. Yes, I will be documenting my thoughts and providing some form of test plan (maybe as a mindmap), I may be writing test cases, I will be involved in creating automation to verify test cases and raising defects, but these are just part of the overall role.

Testing is used to Improve Quality

Testing isn’t just about how something can be broken, it should be about how we can help to improve the quality of the delivered product, if that means having a discussion at the start of a cycle where you question the design and offer improvements to enhance quality, then you are finding a way to create better quality products, this is still a form of Testing. It is certainly more efficient and effective to invoke the change at the design phase than raise a bug and development having to fix an issue later. That’s not to say that when you ask those questions in the design meeting, you aren’t highlighting a possible test case that can be executed at a later point and it is true that test cases can be identified at any point, not just when you are writing a test plan.

When is Testing Finished?

A testers job is never done, there may always be more test cases to identify and more scenarios to run, but it’s about being confident that a high enough level of quality has been proven and the risk associated with the outstanding work is low. This will often be defined by criteria set by the team or by your own standards. That means, just the fact that all tests are passing is never enough to say testing is complete, there is always more that could be done. 

And with it being a mindset, the fact more can be done, will sometimes mean you probably could’ve signed off earlier than you did on the testing but you “just want to make sure”. 

In fact, I’ve never met a tester who signed off before they’ve put in a bit of extra work.

Testing

Testing Certifications – Are they worth the paper they are written on?

There has been a lot of buzz around this topic at recent testing events and in forum discussions between testing professionals, there are a fair few different certifications around but are they of value? A quick google and I found the following certifications:

  • ISTQB – Foundation, Advanced (Test Manager, Test Analyst and Technical Test Analyst) and Practitioner
  • Certified Software Tester (CSTE) – Varying levels and also offer a separate Certified Software Quality Analyst (CSQA)
  • Certified Agile Tester (CAT)
  • Certified Software Test Professional (CSTP)

There are many others and courses which don’t provide ‘Certifications’.

Now, let me state that I have the ISEB/ISTQB Foundation and Intermediate Certificates in Software testing, I attained them a long time ago and at the time they worked well as a base knowledge to get me going in the testing world. That is what I saw them as, a way to gain an understanding before applying the knowledge and diving deeper on my own into the different topics. I have done lots of reading and many free online courses around certain aspects which may have been briefly mentioned in the ISTQB courses.

Now here comes my rant… Doing the courses is one thing, for most of the courses, passing the exam means you have digested the definitions and content from the course and been able to answer most questions correctly in a multiple guess exercise. THIS DOES NOT MAKE YOU A GREAT TESTER! Stating you are a certified tester sends out the wrong message. Putting it in your profile name on linkedin – “John Smith – ISTQB Foundation Certified Software Tester” is wrong, it should not be something you are shouting from the rooftops. You should be saying something like the following:

I am an experienced Software Tester with advanced skills in x,y and z.

(note the lack of mention of the certification). They should not define you as a tester, you should be considered for roles on your skills, not on whether you attended a particular course and passed an exam. Companies also need to stop specifying certifications as part of their job specs, there are plenty of very good testers which may not have them who would do the role better than some of those who have.

There are plenty of courses worth doing out there that don’t give a Certified stamp at the end, ones that still have some form of assessments such as the BBST series (link here), these are courses I would like to get around to doing, but they are not 3 day courses with a multiple choice exam, they require continued effort for a period of weeks/months with practical assessments aswell as an exam.

Another course which comes highly recommended is the Rapid Software Testing course by James Bach, Michael Bolton and Cem Kaner, three industry gurus who give students confidence they can test anything in any timeframe (linky).

I guess the point I’m trying to make is, these ‘Certifications’ should be treated as any other training course, if you feel you will get value attending then go on them, just don’t hold the certifications up as a badge because it shouldn’t give you any additional kudos over other testers who haven’t got the certifications.

Testers are people and people learn in different ways. Testing is a field of work where there are constantly new things to learn, new skills to develop and new concepts to get your head around. Not everything you need to know will be in the syllabus of a certification course.

Like i said before, I have nothing against some of these courses, but they don’t make you the complete tester. Use them as stepping stones to further your knowledge and grow in the testing role.

Personally, I find now, that I learn just as much from reading other testers blogs or attending testing events and hearing new ideas. Learning opportunities can arise in many forms, all will be useful in making you a better tester.

So my answer is, certifications are only worth the paper they are written on, if they are then extended upon, knowledge is applied and not just used as a “that is everything I need to be a good tester” approach.

Testing

Spreading the Word – Being the Sociable Tester

For me, testing is a mindset rather than just a role and sometimes that can and does affect other aspects of life. The amount of times I have gone to try and break something intentionally, just to check that it can handle error cases. That would be fine, but doing it to the TV while my wife is trying to watch it may not be the best idea (just for the record, the TV didn’t break) or even worse than that, ‘testing’ one of my 9 month old sons interactive toys!  🙂 It’s a habit that is sometimes, difficult to avoid…

It is sometimes easy to forget that not everyone has the same attitude towards testing, I was recently asked by someone who is not technical atall:

“Why do you test?” What needs testing?”

I tried to suggest the usual examples:

“Would you be a passenger on a plane if you thought they hadn’t tested that it worked properly?”

“Would you put your child in a car seat if it hadn’t been safety tested?”

Then I suggested software is no different and that everything on a PC/Mac/Phone/Tablet SHOULD be tested in some form before it being deemed good enough to release to its intended audience.

Having this discussion got me thinking of ways I could help improve the attitude towards testing, especially from people who aren’t testers and also improve my own skillset at the same time.

The first place to start  for me was at work, with my colleagues, aside from doing my job to the best of my ability, I have also done the following:

  • I have printed out James Bach’s blog on ‘A Testers Commitments’ (http://www.satisfice.com/blog/archives/652) and put it up next to my desk.
  • I have my software testing books on show so anyone can come and read/borrow/discuss parts of them
  • Not being afraid to talk about testing and suggest ideas to developers on how to make their code more testable, hopefully raising the awareness that they need to think about this before they develop their code
  • I have started putting together mindmaps of how testing could improve projects that currently don’t have the resource
  • Attempted at starting an internal community where anyone who wants to discuss testing, has somewhere that they can share ideas with.

Then there is the external testing community:

  • Joined online communities such as the Software Testing Club
  • Attend conferences, there are plenty of these all year round, some are testing specific, some are software or even IT specific but it’s the people present that make the conferences.
  • read blogs (James Bach’s as mentioned earlier or look on ‘my favourite blogs’ in the menu bar at the top and listen to podcasts (“Testing in the Pub” or “Let’s Talk about Tests, Baby ” to name a couple that I have listened to recently)
  • Started a local tester gathering where people from all around the area can join and share ideas, and not limiting it to just testers but anyone who has an interest with testing (https://priorsworld.wordpress.com/aylesbury-tester-gathering)

Obviously, not everyone want’s to be sociable but I genuinely believe that my skillset and my people skills have improved no end since I started being more open to discussing/asking questions and sharing ideas and stories with other like minded people.

So what’s the next step with non-like minded people? How do we raise the profile of testing so people understand the importance of the job we do?  Some thoughts:

  • Holding some kind of event were non-testing people get chance to try and find problems in a buggy piece of software?
  • Getting out into schools and teaching testing alongside programming in the new curriculum?

Any other thoughts? Would love to hear some ideas. 
Next stop… The world! 😜

Testing

Not Familiar with Testers? – Proving Your Worth With a Development Team

Last June, I had the opportunity of a new challenge within my current company, which I grasped with both hands. I moved from a team which had a very well-oiled engineering process, a very stable test framework which gave the team confidence in their product and a team which I had worked in since I graduated from University 7 years earlier. The team I moved to had no active Testers and was still trying to define their engineering processes.

This has proved to be a challenging but enjoyable change and has really made me work hard to show what I can bring to the table and show why testing/QA teams are important.

One of the first actions when I joined the team was to ask to be added to code/peer reviews, previously the code had been reviewed between developers only. This brought some resistance initially –

  • “Why do you need to be on Code Reviews, you’re only QA”
  • “What benefit will it bring having you on the review?”
  • “It will take longer”

I went into more detail on this in a previous post, but the point was that they were not keen to start with and then the next stage was to bombard me with so many code reviews that I had very little time to do anything else. I stuck with it and eventually got through them.

There was initially a reluctance to involve QA, but to be fair to the team of developers, they were open to try once we started to discuss things with them.

Over the next 6 months or so, as a team we worked hard to prove ourselves and we are now at a point where QA are considered in design discussions, code reviews and any major decision making. It’s been a challenge but we are now showing signs of working as one team. There’s still a way to go but we are happy with the progress. But how did we get to this stage? I put it down to 3 things:

1. Getting the Right People – The team being put together has to have a solid set of skills across the team, a good mix of traditional testing skills and good technical developers to work on the frameworks. The testing mindsets need to be there and all of the team need to be strong enough to question things and follow through when something needs doing. It helps in the scenario of the developers being reluctant to work with testers, that the test team have the right people skills to get to know them socially or atleast be prepared to talk to the team about non-project/work topics to build up enough of a relationship that it becomes easy to discuss work topics with them.

2. Find Ways to Be Involved  – Asking questions, listening to conversations, being willing to take tasks which will involve working alongside a developer, are all things which will help aid understanding of the functionality. Know your stuff, if it needs looking up, spend some time reading around the subject so that you can have discussions with the developers about it.  Ultimately, it is about doing all you can so that the developers trust that you know what you’re doing and you will test the product effectively and verify the quality. Set up bug scrubs, or design discussions and invite development along, it’s things like this which will prove that you are all fighting for the same cause.

3. Find Issues Through Testing  –  It might sound obvious, but if the team are previously used to relying on Unit testing and their own dev testing, then the QA testing needs to enhance the coverage and find issues that their testing wouldn’t find. Whatever way the testing needs to be done, put together a framework which will enable the team to spend their time testing, rather than constantly having to fix issues and not be sure whether the issues found are due to the framework or the product under test. Then the next stage in proving worth, is to find issues which may not have otherwise be found, issues which would have caused major problems if released.

Having these 3 things, will give you a fighting chance of a testing team which will work well with development. Maybe we’ve been lucky with the people in our team, but the difference in the last 6-9 months in the attitude towards the testing team has been huge, but here’s hoping it will continue to improve.