Posts Tagged ‘Testing’

I like to engage in good healthy discussion. I don’t mind taking a contrary position or having an argument. I want my friends and colleagues to challenge me. It helps me learn and think in different ways. I’m not a zealot about it. I’m okay with people being wrong on the internet, but every now and again there is the invitation for dialogue that I find difficult to pass up. It can be tough though when the person who has requested said dialogue is reluctant to engage.

I had just such an experience recently over on UTest’s blog where Rex Black of ISTQB fame was interviewed for ‘Testing the Limits’. Mr Black was hopeful of conversation between himself and readers of the UTest blog. Being a reader and having a number of questions I was happy to oblige.

Unfortunately the dialogue has, at least thus far, not been what I was hoping for. Now I don’t want to be unfair. Mr Black is a busy man. He did go into quite some detail on a number of the questions I asked. He indicated his lack of time a number of times during his replies. I had a number of other questions and made several statements though that I was hoping would prompt further dialogue. I’d like to think he will at some point he will take a well earned breather and spare a few minutes to come back and continue.

He was kind enough to point me in the direction of their psychographic analysts. I did put in an a request to them for more information, but have thus far received no response. Should that change, I will be sure to amend this paragraph. (Mr. Black, if you are reading this, perhaps you would be so kind as to have a word on my behalf and have them forward the relevant materials)

In the event that the conversation moves over here, let me list the areas where I would like to continue discussion:

What do you think the value is (to the certificate holder) of a certificate that pretty much anyone can achieve after a multiple choice exam that involves no practical examination of testing?

Would the testing industry not be better served by an examination process that rigorously tests the candidate’s ability to apply in pratice the theory and techniques they have learned, even if such a process was time consuming, difficult and did not scale well?

Wouldn’t the ISTQB serve the industry better by helping busineses realise that excellent testing is difficult to do well and that not everyone is cut out to be a professional tester?

There were a couple of other questions that I was waiting to ask. I wanted to get the current set squared away before I continued, but since I am not sure when this discussion will continue, let me state them here.

You say that ISTQB’s competitors have obvious commercial interests. Is the ISTQB a not-for-profit organisation? If that is the case, what happens with the $100 or so that examinees pay for their certification. 160,000 x $100 is not a small sum of money, even over 10 years.

I should say that these last couple of questions are not only for Mr. Black, but are open to anyone from the ISTQB who can authoratively answer them.

Once again, I’d like to invite you to read through this PDF, at least slides 8 to 14, but the rest is very worthwhile also. There are questions and assertions there that I think you really need to answer, for the sake of your credibility if nothing else.

The floor is yours.

The new job (well, not so new now, but in any case my latest job) uses quite a bit of tech I’d not dug into previously. As far as source control goes, I’m used to centralised SC like SVN (or even CVS in a pinch), so getting my head around a distributed model (Git) took some doing (more work required there, but that’s fodder for a different post). Working with a new language and framework as well – I hadn’t touched Ruby on rails up to now, which was stupid of me – I’m finding it pretty freaking awesome for the most part.

It’s taken me longer than I thought to come up to speed. I’ve been scraping the rust off my unix-fu and with unfettered access to the codebase and the command line, I feel like a long-lost missing limb has been reattached. Between that and the whole ‘learning new stuff’ thing, I’ve not had much time for anything else. There seems to be light at the end of the tunnel though. I’m grokking more of the code base and starting to make some useful code contributions.

One of the things that I’m trying to do at the moment is put a little bit of structure in the way that the business group and the development group communicate. Right now there is lots and lots of communication, which is great. The confusion comes in where the lines blur between the business telling dev what they want and going to the extent of speccing out everything in such minute detail that there’s not much design work left to be done by the dev group. That might not really sound like a problem to some, but in practice I’ve found that it can make the dev guys feel micromanaged or like their opinion is not required/valued – especially when design-level decisions are architecturally difficult to implement. If non-tech design reaches too far and gets it wrong, it can mean wasted time and effort either for them when the developer rejects it, or for both if the developer codes it in order to prove the point. The thing I love about my current place is that there are no passengers, and this stuff tends to get worked out, but I think I can do more.

This is where I am hoping that Cucumber will help out. If I can put together a series of tests that step out the current behaviour with a DSL that both the business side and tech side can build their communication around, then I suspect we will find it a little easier to step through the desired behaviour in enough detail to be clear about functionality while leaving the dev guys to work out the implementation. It’s not the only reason I want to use Cucumber, but I do have high hopes in this area. It probably won’t hurt that people will be able to see this stuff turn into checks that can be executed automatically. The key is still in the communication. I’m looking to make the clarity of that communication easier.

Cucumber is new tech to me as well. Conceptually I get it, but it’s different when you start to get your hands dirty. After a lot of reading, I decided to go with Cucumber, Capybara and at this stage, I think a combination of Selenium and TestUnit (Ruby’s in-built unit testing framework). I’m a Capybara noob as well, so I’m up to my elbows in new stuff and loving it. Mostly. Sorta. Apart from the frustrating bits.

Almost the entirety of the literature I’ve found on this setup is for BDD – which is to be expected, given that’s what its for. All of the setup and how-to stuff is for building stuff that doesn’t exist yet. Great if you’re building from scratch, but not super helpful if you have an existing code base you want to fit tests to.

I had an utter bastard of a time getting Cucumber and Capybara to work at all. Granted that it’s probably because I’m working with code that does a few unusual things, but I didn’t expect quite as much screwing around as I had to do – so, I’m going to detail it here in case there are any other poor bastards out there who are trying something similar. Hopefully this will save you some frustration.

My setup is (as of writing) Ubuntu 10.4, using rails 2. I already have selenium installed, and the installation of that is not arduous, so I’m going to omit that part.

I installed the following gems:

libxml2 libxml2-dev libxslt1-dev
gherkin cucumber cucumber-rails nokogiri capybara database-cleaner

I’ve listed some that should be pulled in automatically by other gems’ dependencies. For instance, gherkin should be installed when installing cucumber, but for some reason I had to do it manually. YMMV.

After installing the requisite gems, it should be a simple matter of generating all of the cucumber goodness from the root of your rails project

(ruby) script/generate cucumber –capybara
(you can add other options if you want to have them built in)

If all your bits and pieces are installed correctly, you should see a bunch of files and directories get created.

Here are some things that tripped me up:
I thought I might do some work with rspec as well, so I pulled those down. If you’re thinking along the same lines, then Cucumber seems to barf if you install anything beyond rspec 1.3.3
I also had to mess around with the dependencies for the json gem in my project as cucumber seems quite particular about wanting 1.4.6

By default, cucumber will clean the database after each run (as is generally considered good automation practice). In my case however, I have enough stuff in the db that it doesn’t make sense right now to load from scratch or mock the bits I need. Maybe down the track but for the moment I’ve just switched this off in the environment file (more on this shortly).

Anyway, moving on. From root, there should now be a features directory. edit features/support/env.rb
You can either make your settings changes in here, or in another file and require it from here. This file is automatically generated, so if you plan on making a lot of changes here or you think you’ll have cause to regenerate this file, the latter might be a better option.

Here are the changes I put in

Capybara.default_selector = :css
Capybara.run_server = false
Capybara.app_host = <url of my testing area>
Capybara.javascript_driver = :selenium

One of the things that really screwed me around was not realising that Cucumber starts its own webserver and runs on that. I tried pointing it at the server instance that Rails kicks off, only to find that things were falling over and there was nothing in my logs to tell me why. I felt like a complete moron once I did find out, but then again, the docco in this area appears to be awfully light so I don’t feel too bad. Anyway – be warned. If you don’t want Cucumber to use its own webserver, you need to tell it so explicitly.

As I said, there’s bugger all out there right now on retrofitting scripts for an existing code base. It sounds like it’d be easy, right? The code and functionality is already there, so skip the red/green/refactor bit and go straight to green, right? Not really.

Rather than conceptually pre-fabricating your functionality, you get to look through your existing functionality, decide what is most important to test, work out where you need to retroactively install test hooks and build use cases that serve a business purpose, while not getting lost down a rabbit hole around functionality that currently exists, but perhaps doesn’t work quite how it should. Yay! Given that there is the potential for test to ‘just light up green’ when you write them, I’ve also found it a good idea to write checks that fail so you know they’re actually doing something, then correcting them – it sort of keeps the spirit of BDD/TDD even if you’re not driving any development just at this point.

Retrofitting Cucumber tests to your site is not as simple as it might sound. I am hopeful that it will be rewarding. It’s a little too early to tell just yet, but the signs are positive. If there’s any interest, I may follow up with a post about some more of the specifics of the actual hands-on retrofitting bit. If you have questions, fire away.

I spent the last week in Grand Rapids, Michigan, attending CAST2010 (Conference of the Association for Software Testing). It is difficult to describe the value of a conference like this. It is a collection of some of the most respected minds in software testing, of my peers and of people full of passion for the craft.

I attended an awesome workshop by Fiona Charles on ‘Speaking Truth to Power’. There were some fantastic presentations by testers from all over the globe. There were a series of lightning talks (I made one on the use of Japanese language as a learning mechanism). If that wasn’t enough, there were some excellent hallway conversations and exchange of ideas and the opportunity to meet some very talented minds. I met old friends, and many people with whom I had exchanged emails, but never met. It was all over far too soon and I am very much looking forward to the next one.

If you only attend one testing conference in 2011, I urge you in the strongest possible terms to make it CAST2011.

Here is what some other attendees had to say about CAST2010

Michael Hunter
Selena Delesie
Mark Vasco
Carsten Feilberg

Edit:
For those that want a small taste of what CAST is like, the keynote speeches are available online

Tim Lister
Cem Kaner

I’d like to say thank you to everyone who participated in this little puzzle exercise and most especially to everyone who provided feedback. I hope you had fun with it. Well done again to Rushmila Islam who was the first to work out the puzzle.

I have posted .the solution at the bottom of this post. YOU HAVE BEEN WARNED.

I learned a lot more than I thought I was going to. Firstly and probably the most obviously, I learned a lot about cryptography that I didn’t previously know. Thanks to James Bach for the collection of links.
Braingle was probably the best of the bunch. Thanks also for the link to Sebi’s puzzle.

I found Jürgen Plasser‘s answer fascinating. I hadn’t encountered measuring entropy of text as a way to inform possible encryption techniques. It’s something I’d like to look into further.

It was interesting to see how close people got with their responses. Many people had several correct pieces of the puzzle, but not quite enough to solve it completely.

I think most people gave me way too much credit for the amount of crypto knowledge I’d have had as a high-school student. I didn’t have access to teh intarwebs back then, and time that I could have spent in the library was more likely to be spent playing role-playing games or painting miniatures or similar valuable life skills.

One of the things that this puzzle made abundantly clear to me was the value of information before and after it becomes known. Without the key information, it was a real puzzle. Far more so than I had originally anticipated. Having all the information at hand, the puzzle seems obvious and simple in hindsight.

It drove home for me just how difficult it is to convey the value of a tester to those who don’t understand what good testers do. Even the distinction that testers are a source of information (so is a book. so what?) doesn’t necessarily convey the effort that is involved at producing this information.

Some people went to a great deal of effort; tried some very cool things. That was the most gratifying thing for me. The answer was ultimately irrelevant. I got to see how you guys think. As testers, we are often showing others the fruits of our effort, but not the beauty of the effort itself. Having been able to do that here, at least in part, I think is pretty cool. Thank you again to everyone who shared.

SPOILER ALERT – Explanation of the cipher follows.

The message was encoded with direct character substitution with a few added extras. The message reads top-down, right to left. The first two characters provide the character offset – character 1 – character 2 = offset.

The spaces themselves mean nothing, but exist primarily for obfuscation though I did put them in diagonally in the first puzzle to give a clue to the direction of the word flow. Spaces in the actual message are represented by vowels, so in this sense, vowels do double duty in that they can represent their offset character or a space.

I’m having a lot of fun with this Selenium gig (shh, don’t tell anyone). There have been a few yaks shaved and I’ve seen the inside of some rabbit holes, but there seems to be a lot of good material online to guide you.

At this point, I’m running my tests directly from eclipse, though we’ll be looking to kick them off with Ant in the near future. I’ll jump off that bridge when I get to it.

LoggingSelenium
I’ve set up loggingSelenium to log test execution. I’m not sure what its current development / support status is over at SourceForge. The documentation it comes with is not real flash, but there’s a decent example here (via here). I have made a couple of custom modifications to the source of loggingSelenium as there are a few gripes that I have with it.
Some of the pluses are:

  • it will automatically grab screenshots for you when your scripts bork.
  • it color-codes your asserts and failures
  • it can wrap JUnit asserts and log them alongside your selenium commands.

Some of the not-so-good things are

  • it requires a hardcoded path for writing output
  • it looks like it’s geared to non-windows systems, given that out of the box, the screenshot links in html output don’t work.
  • the color of failed selenium asserts is different to JUnit asserts, the former being an easy-to-miss beige color.

The mods I made were quick and dirty hacks, one to fix the screenshot link and the other to make the beige color more noticeable. If I find myself with a spare second I want to get rid of the need to use a hardcoded path, or at least make it more nicely configurable. I also want to add a color selector so you can customise your output.

Autodocumentation
I’ve set up doxygen to generate documentation from code comments. I’ve not hooked it up to anything yet, but either an SVN pre-commit hook or getting ant to kick it off shouldn’t be a problem.

Test Structure
JUnit 4 does not require you to extend tests from a test class, which is quite nice, actually. Instead, I have written a parent class for my tests to extend from. The parent holds all of the setup and most of the methods that drive the tests themselves.

Currently I’m writing one test per class. The class contains a single method containing calls to methods in the parent and nothing else, so it ends up looking like a set of test case steps. The parent has the potential to get quite big, so as test case numbers grow, it’s likely that I’ll add further abstract classes between the current parent and the tests to group them more reasonably.

I’m importing data via Properties as a resource stream. I have data that is used to drive the tests and data that is variable, but predictably constrained. For instance, I use a vehicle class number as a driver. The class number refers to a class of vehicle whose data is stored against that number. Depending on the number selected, different vehicle data is populated during setup.

On the subject of Properties – If you’re developing in a language that uses double-byte characters (such as Japanese), if you are generating your Properties files as flat files, you’ll need to run native2ascii on them to convert your double-byte code to unicode. Otherwise, they will not be properly interpreted and things will fall over.

I have just started playing around with the @Parameterised tag and @RunWith(Parameterized.class) to get iteration working with data variation. I haven’t decided quite how I’ll run with that yet. I could do this at a suite level and control iterations of tests by feeding data to them, or I can have each test take care of its own iteration by setting up parameterisation within the tests’ parent class.

Browser setup
I’m doing mobile emulator testing at the moment, so I’ve set up a firefox profile specifically for it. I’m using the user.js file to alter the plugin config so that the browser starts up with the plugin activated and a particular device switched on.

When starting seleniumRC, I specify this browser profile specifically so it is automatically used when firing up the browser. I was hoping to be able to change device type on the fly by mucking around with chrome urls, but I’ve not found an elegant way to do this yet. Instead, I am swapping the user.js file out whenever I need to change. Essentially, you can load up the user.js file with calls to your plugins to switch them on/off and configure them based on what configuration the plugin makes available.

It’ll end up looking something like

user_pref(“<plugin.configItem1″, “value1″);
user_pref(“<plugin.configItem2″, “value2″);

You can hunt down config items by typing about:config into your browser. Any config item that is not set will be invisible however, so I ended up looking through the plugin’s jar file to see what else I could see.

So at this point, I have a loose collection of parts that are not quite all tied together but it’s getting there.
Other things I’m contemplating in the not too distant future is a web front-end so non-technical testers can select test suites and kick them off at will.

While I haven’t gone into code-level specifics, the links should provide a fair amount of detail. Let me know if there’s something I’ve not explained so well. If you have comments or questions re any of this, I’d love to hear it.

So I mentioned some of the inherent issues that I dislike about QTP 10. One of those appears to be that reusable actions intermittently fail. An action in QTP is a tool-defined item that collects a number of GUI manipulations (or function calls) into a named action. It sounds handy. It probably would be if it worked reliably, but it doesn’t – at least not for me. The other thing is that if you have reusable actions (let’s say for instance that you keep your common ones in a single file and call them from other files), you cannot modify those actions without first closing your current test file and opening the one where the action is defined.

Instead, I have organised my scripts into a series of user-centric actions, which I have defined as functions in function libraries. To be clearer, each function executes a series of steps in the gui that an end-user would recognise as an action. e.g. log in, navigateToQuotationScreen and so on. This seems to work pretty well. I end up with a QTP screen that looks like a high-level checklist of how to execute a particular workflow. You do not have the editing restrictions that you do with reusable actions, as you can have as many function libs open as you like.

Neato. So I’ve been using the record tool to get something that works. Mostly because I dislike VBScript. I think it’s the Orcish of programming languages (Maybe not even that. Maybe it’s Kobold </nerd>). The recording tool creates a bunch of objects and sticks them in the object repository. That’s fine, saves me having to do it myself. Drawbacks to this are that for dynamically created objects, you may end up with a bunch of identical objects with different names. Not too hard to figure out, given that you should be naming your objects something sensible anyway. You can weed out the dupes when you do this and update your script accordingly. I’m definately going to check out Albert Gareev‘s suggestion of dynamically loaded object repositories. That sounds quite handy. I will say though that at the moment I’m being assisted by some not-so-technical testers who I am weaning away from the keyword view and the active screen.

The recording tool doesn’t always use the best code for the job. It’s the same old story – want the job done right? Gotta do it yourself. After the initial script is in place, I’ve been reading through the code and separating it into user-centric actions. At the same time, I look for:

  • places where the code can be optimised
  • places where data should be dynamic
  • any fluff commands that QTP put in
  • potential duplicates in the OR

At this point, what I’ve ended up with is having a series of user-centric ‘tests’ – I’ll call them transactions. Each one is an action (as every QTP test has 1 action by default), but consists of a series of calls to function libraries.  Each function is named for a step that a user might consider part of the transaction. For example, if we were talking about a program that provides a quote for car maintenance, the list of function calls might look like this:

  • enterVehicleDetails
  • selectServiceTypeAndLocation
  • selectPreferredDates
  • completeQuotation

Each of these functions lives in an associated function library. These functions may in turn call helper functions (such as date/time functions to enter date ranges in the future). Each transaction hides the ugly details of what is going on under the hood and while you don’t get to use the ‘keyword view’ anymore, you do have a clearly labeled set of steps.

So at this point, I have some scripts. They work. They’re not robust and they don’t do any data verification to speak of, but it is a beginning. Next up – parameterization and making use of the data table.

Jonathan Kohl beat me to the punch on this blog entry by a good margin, but since I was already working on this thing, I’d like to go ahead and basically say exactly what he said in probably a far less cogent fashion.  A lot has been written about the good and bad things about Exploratory testing and the writing and (mis)usage of test cases.

I don’t see a lot written about harmonious use of both. I’m sure people do it. I know I do. Is it like airing dirty laundry? Do context driven testers not want to admit to using test cases in case James Bach reads their blog and decides to tear them a new one? Do factory testers (sorry – what do you BDUF testers call yourselves anyway? Factory tester brings to mind a grey-clad downtrodden peon, which I suppose is appropriate, but not very flattering) – anyway, do you lot not want to admit to doing exploratory testing in case your overseers beat your for not following the script? Am I missing something? Is this just not a big deal?

Johnathan advocates using a blend of both and uses the terms prescriptive and descriptive testing, which quite appeals to me. Michael Bolton’s recent highlighting of the difference between testing and checking as something we should be more conscious of helped me to frame this better in my mind.

There are things that you can plan ahead for. There are risks you can identify and tests that you can design to mitigate against them. I see no reason why you shouldn’t use test cases for these if that is what you are comfortable with.

One of the issues I have with test cases is that some people see them as a magic artefact that covers all possible problems in a given area, because one or more tests have been written that mention it.  They fail to see that many test cases are highly focused on verifying a very specific item somewhere, and just because we go through a bunch of steps to get there does not mean that those steps have also been verified.

This leads me to wonder if I have been thinking about scripts all wrong.

I recently read Michael Hunter’s work on setting up test frameworks. One of the things that was a lightbulb for me was separating the verification from the action. Very very obvious in hindsight, but if you think about it – this is basically a use case and a checklist.

We have a series of steps from point A to point B

We have a list of things that we want to make sure are as we expect them.  Why do we need to mash them together? Why do we need to repeat the list of steps over and over and over so that we can list a different verification point next to it?

An argument I hear for test cases is that if you write them well enough, then anyone can execute them. I really hate the way that thinking goes, mostly because I read it as ‘anyone can do testing, you just follow the scripts’. That being said, a clear set of instructions and a checklist could mean that you could get a non-tester to do checking, even of mission-critical information. That, I might hold with.

Checklists and Check scripts? I think this is something worth exploring further.

For those of you (us) whose Japanese reading skills aren’t comprehensive, you might find some valuable assistance with a firefox plugin called pera-pera kun. It is an extension of the also excellent rikai-chan.

It allows you to hover over Japanese words and phrase fragments and get a popup with dictionary / grammatical meanings. I couldn’t do without it.

You can find the plug-in here
and the required Japanese dictionary here

I believe there is also a Chinese dictionary out there, don’t think they do hangul (sorry Jared :)   )

For those that are studying Japanese (or anything where flashcards are useful, really), check out Anki.
I am creating my own study deck, but if you want to dive right in, there are a bunch of pre-made decks available and plugins if you like that sort of thing.

I wish I’d found both of these years ago. Seriously. Hopefully they’re handy for some of you.

Clearly I’ve had it far too easy for the past 10 years. Working for internet-based companies with unfettered access to install whatever I like on my machine, all the internets I could eat, complete control over my testing environment(s).

I have a question for all of you who have in the past experienced complete machine lockdown in your role as a tester (or developer or similar). Imagine the following completely hypothetical situation:

You need to install stuff on your local box, but can’t because you don’t have privileges. Getting stuff installed on your box requires going through a cubic buttload of bureaucracy and can literally take 3 weeks. No (instant or semi-instant) comms with the outside world, disabled USB ports, the works. Does this hypothetical situation sound familiar to anyone?

Does one

a) Politely request that ones machine (and the machines of one’s team mates) be unshackled and cite decreased productivity as a reason (and possibly offer to instead abide by a set of guidelines that are reasonable)?
b) Rant against the concept of treating intelligent adults like naughty children or criminals?
c) Say nothing, but add a couple of weeks per app one may need to install to project test estimation?
d) None of the above, but something awesome that I have neglected to mention here?

Teh Google shows a lot of hits for people who are in favour of lockdown. Guess it’s okay when you’re on the other side of the fence. I found a few articles that were in favour of trusting users – I enjoyed reading through the comments here. I think it comes down to finding (begging for?) balance. I know not every user out there is savvy enough to stay safe on the internets, but there are plenty that are. Why should they suffer?

I’m interested to hear how people have handled this situation and what the results were.

It’s funny how one word can have multiple meanings. I’ve been thinking about this a lot lately in relation to learning Japanese, and especially Japanese grammar where identical grammatical structures can have quite different meanings depending on context.

There’s also an English word that’s been bugging me a bit lately. The word ‘just’ can be an awesome word. It can mean ‘fair and honourable’, or ‘precise or exact’, but I’m not so much of a fan when it is used in the following sentence fragment – ‘You’re just a tester…’

It often is accompanied by phrases or questions like ‘you wouldn’t understand’, ‘you don’t need to worry about that’, ‘what are you asking about that for?’, ‘you don’t need access to that’ or ‘what do you mean you should be paid as much as a developer?’

As grating as the assumption that you’re not techie enough, or that anyone can do your job (or similar ignorance) may be, my advice is to not take it personally.

I could choose to feel insulted, but I don’t. It generally means to me that I have to help educate someone. I’ve heard it from developers, project managers, salespeople, executives, all sorts of people who think they have a handle on what it takes to be a tester. It may be that their previous experience has been a negative one with low-skilled testers. Maybe they have no experience with testers at all and are going on assumptions and second or even third-hand information. Whatever the reason, it is clear that their understanding of software testing is framed differently to mine.

Sometimes, a short conversation on what our differences in understanding are is all it takes, but if someone has the idea firmly in their head that testers are (just) monkeys that click on stuff toward the end of a project, you’re probably going to have to be a little more hands-on in demonstrating your value.

Find out what they think your limitations are, then find a way to add value that goes above and beyond what they’re expecting. At the start of a project, analyse the design and put together a risk analysis (along with what can be done – not just testing – to mitigate them). Are there unit tests or other automated tests you can review (and possibly improve)? Have developers put their money where their mouth is with Mike Kelly’s 5 bugs in 5 minutes challenge (PDF link – see page 5).

You might demonstrate the value of exploratory testing by conducting a paired testing session with them. What you do will of course depend on your own situation. Be proactive about it though. You can point them at blog posts and pdf links all you like, but until you actually demonstrate to them the value of a tester in a way that they’re going to notice or care about, you’re just going to have to deal with being thought of as ‘just a tester’. You might not have created the situation, but if there are people (who matter) whose point of view needs adjustment then the onus is on you.