Do you ever feel guilty for not meeting the standards set by others in the Software Testing community? You’re in the right place then.
In this episode I talk to Dave (@theguiltytester). We discuss traditions, open questions and how to work within contracts which are specifically requesting traditional test practices based on large numbers of test cases.
Artificial Intelligence (AI) and Machine Learning (ML) can perhaps solve some testing challenges, but not all testing. The testing vs. checking debateand all the shift-left of checking, have revealed that some of testing is about critical thinking and some…
More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.
These are the phases of a recent project:
Environment Acceptance testing
Hardware and integration testing
Component- integration testing
Operational acceptance testing
Service Level testing
It’s a challenge in the vendor reply. The vendor will want to reply to all test phases in order to be compliant with the tender, and not loose points. There is no room for elaboration or discussion if you want in on the bid process.
Quite often the requester comes back and say “we didn’t want all those weird testing things, we just want something that works for us”. But when the contract is signed and the work set in motion the project team have challenge to make the testing practical within the framework of the contract. This goes from both sides. Many good hours can be wasted with unwinding cumbersome contractual terms.
What I usually do in such a situation is to bundle the contract’s testing scope into fewer activities, and setup a mapping so that everything is covered. That is if the client allows me to make the activities practical and context-driven. If not – my hands are tied, and we deliver according to spec – even if the chapters of the test plans are set in stone.
Let’sworktowardsbetterdealsfortestingactivities. If you are looking to prepare a BID include a test manager – and have a discussion of the value-add and learning of testing up front. There is no one book of how to do testing. Instead spend the time and money figuring out your context. Figure out what phases are on the client side, and what is on the vendor side. Have a test management consultant on retainer for before and after the bid process. Do something to discuss your test strategy and put the guidelines in the contracts, so that the vendors can propose a solution.
The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.
In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.
You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?
Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.
Apparently my Internet habits are very teenage like… I miss my WiFi and cannot leave the phone in the pocket. What I am is a digital settler, connected to my processional community.
I realized this at a training recently, where it was noticed that I had my phone out DURING CLASS. Was it FOMO – no, I just had a thought about testing to share on twitter. As I would usually do during conferences and my working day. We had a good laugh about me always needing my internet and my phones. I took it as a compliment, as that would mean that I was a YOUNG digital rookie, sharing and collaborating. .. like only the cool kids would do.
When I model myself to the Teaching Trios model – I am a digital settler by age/ introduction time. But collaborating and having an online professional interaction is not based on age, nor should it be frowned upon. Online community interaction is done by all ages, diverse and really nothing new. It’s past hype, and not ground breaking. There are models now of how communities evolve and function. And the business, career and personal benefits explained over and over again.
Yet I have more followers on twitter than the company I work for. Sometimes when someone else at work shares curated testing papers, I have seen it already and have met the people who wrote it. (Read Meet the famous people)
When I model myself towards Simon Wardley‘s three-stage model (Pioneers, Settlers, town planners). I don’t jump anything brand new, but I do want to take the groundbreaking and turn it into a framework for others to succeed… So to my kids Netflix is TV, and my mom follows me on Facebook to see what I’m up to. (no good, I swear).
Treat your testing people as knowledge workers, not rote industrial resources. The later is a spiral to the lowest value, the former is about giving the business valuable knowledge. A modern tester is a knowledge worker – whose prime area is finding information, filtering information, relating information and presenting information. It is a non-linear process, that requires a touch of both creativity and consideration.
The best testing tool is the brain, and the knowledge worker ponder the problems both consciously and unconsciously. She can work without using the hands or legs, but not with a simple headache. It takes a lot of thinking and collaboration with the stakeholders to identify what questions about the product has value to the business. The (context-driven) knowledge focused tester focus both that it works, and that it adds value to the business.
The business focus are far from the classic mindset of testing established around the millennial (2000). where testing is about finding defects and going through the motion of deriving test cases from specifications. – I know I’ve been there. That era is long gone, even dead at some time to Whitaker and Alberto Savoia. Be provoked or even insulted, but it’s the future.
But wake up – it’s not where the testing world is today. The old tools of design techniques and coverage metrics makes less and less sense to the business. They are old-school and classic approaches, in the not so cool way. The cool kids on the block are poppin’ tags – getting new stuff, sharing and exploring. They know that change is the new normal and that what works in one situation doesn’t work in another. Their primary concern and focus is getting knowledge to the decision makers. They are the knowledge workers
I help you help me help someone else help …. help you help me help each other help us all
If all you bring to the meeting is what you have prepared in advance – what new do you learn by meeting?
I once was at a company that should have the motto “always prepared”, “semper fi” and “errors are not an option”. Every meeting had a check sheet, a resume form and a registration of preparation time. Because if it wasn’t measured it didn’t count. If it wasn’t in the play book it didn’t count either.
So one day we sat at the meeting reviewing a development story – the developer, an architect, me and the other roles required by the check sheet. Some had prepared written comments: everything from simple rephrasing, code changes and test case headlines. Some had not prepared a tangible thing – I had not.
So the interesting question came up: why meet at all, if the only purpose of the meeting was to go through the written changes. These could be sent directly to the developer or discussed bilaterally, and not heard by all five. The answer to this was not in the play book, and the meeting was puzzled.
I had prepared nothing in advance, yet I had prepared myself in advance to listen, think and wonder during the meeting. To me the purpose of meeting* was the joint collaboration of the participants.
The sum of the whole. That 1+1+1+1 can be five.
*: meetings can have other purposes. Sometimes I hold orientation/elaboration meetings, when things cannot be elaborated sufficiently digitally.