Founder and CEO of @TentamenHr. Organizer of Zagreb Software Testing Club meetups.
670 stories
·
0 followers

Dear tester! Others care about quality, too.

1 Share

Dear tester,

I know that sometimes it feels like people you work with just want to mark the cards in JIRA as Done without proper testing. Sometimes they tell others “…once it passes the QA” or create tasks for you subjected “QA X” like it is being done just because “they have to”. The feeling of annoyance caused by urgency to complete the task immediately without reporting any bugs is inevitable because of the way they tell just to “pass the QA”. I did write of that before on why “pass the QA” makes me cringe, so I can feel your pain really well. Especially, that even after me trying to explain QA vs Testing vs Checking many times in my company and clarifying, the very same wording is still being used. I would like to share with you a story that happened to me which made me think that sometimes we a little bit exaggerate assuming that others do not care of quality as much as we do.

Today one of developers in my company came back with initial implementation and results to “QA”. The task was fairly simple – there is a lot of data generated by an algorithm and we should check it (I’m using here check consciously as it’s not really testing at this point): does it make sense, what patterns of fault we notice, does algo actually work? All of this should evaluate the quality of results produced by this new algorithm.

The wording of this task’s formulation and documentation with the data had QA mentioned around 5 times in various forms and I’m sure you are familiar with most of them: “data to be QAed”, “for the QAing” or my least favorite “pass the QA”. These terms do not feel too good as they are not correctly used and it may feel slightly insulting sometimes that your colleagues may not bother to even understand what you’re doing. However, you cannot teach all people to use the terms and it’s important to let it go sometimes. Remind yourself that we all have biases (and I do have a story on Managing your biases which made me slow down a little bit before judging). I decided not to exaggerate and think from that developer’s point of view: we both know what he wants as a result – the quality should be evaluated even if he is using the wrong terms.

Some colleagues may use the wrong terms and confuse testing/checking/QA, but don’t go and nit-pick on that. Words matter, but not everyone cares either how to name the rose: all you can do as an empathic quality specialist is to show people that you are open to explain to them, but only if they want to. 

This is not why I’m writing to you, though – this colleague of mine may have used the wrong wording, but letting go of that wasn’t the main takeaway I got.

When the colleague created the task description, it lacked one thing: any description of implementation details of algorithm. No documentation was yet created, no code mentioned, only thing provided was the generated data and vague explanation what should be done (compare columns and say if it’s okay or not using some human sense and research on each of options).

I really wanted to see implementation details: how else can I assess actual risks? Maybe there are areas and patterns that are design flaws and can be seen before even looking at the data generated. This developer tends to work alone as well, so there isn’t much of code review going on.

When I asked if there is any documentation on this algorithm, this was the response I got from the developer:
“Not yet, this is not ready for production yet. When it passes QA there will be a documentation page with all the changes that have come out of the QA process.”

This wasn’t something that I expected to be honest – I replied that to do the QA process we need to know the implementation details and this shouldn’t be made visible only when the algo goes to production. We shouldn’t check in the dark.

My reply has made this developer write to me personally and the words that were used by them again were a little bit rough I could say. The arguments on why the documentation wasn’t created were that “it is too big overhead” and then eventually “it seems that we disagree on the QA process here: for this task, there is no need for implementation details”. How would you react to this, my dear tester? Developer is claiming that as someone who is hired to test and give quality evaluations you shouldn’t look at implementation details at all.

As someone who recently encountered several design flaws in built products which caused issues and could have been spotted years ago, I felt ridiculed. Of course testers or QA (whatever way people want to call these specialists) should see implementation details. Is this developer really thinking that their design and implementation is perfect that we should look just at the results produced?

Issues can be spotted when getting to know algorithms and implementation: you may spot a logical error which causes certain bugs before you even look at the data obtained from running the algorithm

I stood my ground then, though. I tried to explain that I would love to see the implementation because it will help me to do the “QA processes” faster, more efficient and may display me some of issues before I actually look at the data. I want to be familiar with what it is actually doing.

And, to my surprise, it worked. This very same developer who was fighting that QA does not need any details on implementation shared with me the code they wrote to produce the results. It turns out that they thought I needed detailed documentation, but even code was enough which could easily be provided.

In the end, I realized that I could have given up. I could have closed myself up and exaggerated thinking that it’s only me who cares about proper quality judgement and people just assign tasks blindly without even considering that there may be issues in their logic of implementation. I could have felt hurt by the words used and impressions I got from this person, but in the end, even if we spoke in different terms, we both aim to finalize quality assesment (not to pass the QA, just understand if this implementation is good enough). I stood up for myself trying just to do my job better and I got help even if it took an extra step.

So, dear tester, believe that your colleagues are there to help you – you all want your products to be successful and of great quality. It is not only you, just sometimes others don’t know what you exactly need to do your tasks – open yourself up and ask for it. Only by sharing your needs and communicating you can make others understand your tasks better. 

 

 

 

 


Read the whole story
karlosmid
6 hours ago
reply
Zagreb
Share this story
Delete

Considering Conferences: A Reflection

1 Share
The last week I have had a series of interesting thought/introspection sessions. The kind where I pour a decent measure of good whisky sit back and look out the window and think. It helps to have a nice garden to see when I look out the window - and since the house does not have a fireplace and it is too bloody cold out to have a fire in the garden, well, staring into the fire is out of the question right now.

The gist of my thoughts? Let's see.

After speaking at many conferences a year on for several years, on various topics, then filtering down to a few conferences each year, and now one or two conferences a year - I have observed things that make me wonder why I should keep going and speaking at conferences.

Don't get me wrong. I really enjoy the conversations and sharing ideas that happen. Most of these, for me, happen in the hallway or "after hours."

Perhaps it is just that I've grown cynical with regard to the desire of so many people to belong to the cool-kid-club.

What do I mean?

For example - Cool-Kid A and Cool-Kid B talk about an exercise or a book and how awesome it is. They write about it and talk about it. In a short time, loads of other people are jumping in - recommending the same book or exercise. IN a year or so - SCADS of people are talking about how awesome it is and how cool it is. A year later they are all onto something... else. Typically endorsed by the cool kids.

People stopped talking about what they KNOW - what they have experienced and can demonstrate and instead talk about ... whatever the cool kids are talking about. Presentations - even keynotes - get more hand-wavy and full of dancing unicorns (the kind that are on the screen and don't really have a bearing on what is happening with people in the room) and truisms get spouted and straw-men get setup and then slain and people applaud and talk about what a great presentation it was.

My question is - What was the presentation about and how will it impact your work when you get back to the office?

Is the information really new to the people who think it was awesome, or does it merely confirm their beliefs on a subject. Are they so shallow as to not be able to consider going to a presentation they disagree with? Are they afraid of learning something new or taking on material that might lead them to reconsider what it is they think or believe?

I feel the same way about the cool books or exercise - the cool kids advocate.

How has this changed what you do as a tester? NO - Don't give me more bullshit answers about how it changed how you think. LOADS of things can change how you think. Good whisky can change how you think!

How did THIS book or THIS exercise change how you do your daily job? Because frankly, I suspect much of it is little more than mental self-indulgence (I had another word but a proof reader said it might be too explicit for some folks...)

And don't even get me going on so many bullshit keynotes I have heard. The abstracts were... harbingers of hand-wavy crap. Somehow the reality of the presentation so many times has been... more hand-wavy than the abstract. I find it actually quite depressing.

Why?

When I read proposals for conference presentations, I see a series of similarities and "sameness" among them. There are the ones that regurgitate ideas from 20 years ago. There are the ones that claim a new take on a topic - and when I dive in I find them to be regurgitating ideas from 20 years ago.

I see the cookie-cutter, instant solution to all your problems so frequently, I swear (as in take an oath) when I review proposals for conferences, I will not go to any conference that has people presenting such shallow rubbish - ever.

What is one of my warning signs? If the speaker or potential speaker cannot carry on a conversation for 40 minutes ON THE TOPIC THEY ARE PRESENTING ON - do they have any experience in the area or are they babbling theory only? Do they have any real-world applications of what they are presenting? Or...

I'm not sure why this is. I am not sure why people latch onto certain ideas and never vary from them. I am not sure why hand-wavy bullshit is so appealing to people, except for one small thing - it takes no effort to think about because there is nothing there TO think about.

I expect keynote speakers to be exceptionally well versed in their subject. When talking with them, either in advance when preparing a program or over drinks at a conference, I expect them to be able to cite specific experiences - nothing that would violate an NDA, but something like...

There was this problem where... The possible solutions I saw and presented to try were... The team tried this approach... The results were... 


IF they worked - fantastic. What was it that made the solution work? Why did this work? If not - then why did it not work? Talking over drinks (or over the phone) I want to know if the person has "been there and done that" to steal an over-used phrase, or if they are telling a fairy tale/war-story.

When I try to coach new speakers - to help them find their voice - the ground they are going to stake out as their own, I try to help them find a message that is uniquely their own. I try and help steer them away from the ground so often trod on by others and show a little used path they can take.

I expect that speakers will give me something I had not thought of before, some insight I have not considered or some point of view I can make use of when I get back to the office.

Avoid the band-wagon cool-kid trends. Speak and write on what you know and are passionate about.

That might just convince me to read what you write and maybe even go to the conference where you are presenting the idea.

Until then, be well and be.
Read the whole story
karlosmid
6 hours ago
reply
Zagreb
Share this story
Delete

For years, programmers used .dev domains for testing code. Those days are over

1 Share
Comments
Read the whole story
karlosmid
7 hours ago
reply
Zagreb
Share this story
Delete

ROBOT: For When the Metal Ones Decide to Come for You

1 Share

Clever Name, Derivative Attack

Dust off your Old Glory Insurance policy, ROBOT attack is now a real thing that can happen to you.  Researchers Hanno Böck, Juraj Somorovsky, and Craig Young have a new attack to tell you about, and they have named it Return of Bleichenbacher’s Oracle Threat (ROBOT).  To sum it up in one sentence, their whitepaper says “We didn’t go for the full solution to this problem, and it came back.”

Their main finding is that a specific padding oracle attack from ’98 can still be used against modern TLS stacks.  Transport Layer Security (TLS) is supposed to provide you with confidence that messages you send back and forth with a server are secure.  Only the real server should be able to read your messages, and only they should be able to sign messages back to you so you know they are from the real server not some hacker in between you.  The researchers proved that this classic attack works by forging Facebook’s signature.

To make this work, the attack has to open many thousands (possibly millions) of connections to the server with different cryptographic payloads, and monitoring how the server responds.  There are more efficient ways to exploit this, but the researchers stuck to the original plan of attack.  So, in the coming weeks and months, we can probably expect someone to build a faster ROBOT.

It’s clear that the researchers are trying to emphasize the similarities to the original research done by Bleichenbacher in ’98.  In their whitepaper, they make a compelling case that complicated mitigations are not an effective long-term strategy to fix a basic flaw.  In this case, the basic flaw is using RSA key exchanges to facilitate encryption.  In their words: “In our opinion this shows that it is a bad strategy to counter cryptographic attacks with workarounds. The PKCS #1 v1.5 encoding should have been deprecated after the discovery of Bleichenbacher’s attack.”

 

Is this a Big Deal?

Being vulnerable to this attack is a sliding scale.  It could take a few thousand connections to decrypt a captured message, or millions, or be impractical to pull off at all.  If you are vulnerable to this in a way that an attack is practical, then a sophisticated attacker could use it to do real harm.  In my opinion, you almost certainly have vulnerabilities that are more easily exploited and can be used to do more widespread harm.  Please fix this if you have it, but don’t forget about your boring old SQL Injection and XSS!

ROBOT is something you should pay attention to, and look for patches to your TLS library.  Better yet, consider dropping all support for RSA key exchange based encryption, if possible.

I would still call this attack a big deal because it has the potential to educate on an overall issue of wallpapering over security weaknesses to close specific vulnerabilities.  This basic problem comes up every day for us at WhiteHat, as we keep overcoming blacklists and workarounds to exploit the underlying vulnerabilities.  We try to always coach the full solution, and it’s great to see hard evidence to support it.

This attack also demonstrates once again that for TLS to remain secure, we need to keep marching forward, removing support for old cipher modes and adding new ones.

 

What is WhiteHat Doing?

We consider ROBOT worth reporting, and we’re currently working on detection that won’t DoS your server for our DAST and Mobile customers.  We’ll put an update in the Sentinel portal when we have more information. 

In most cases, people will be vulnerable to ROBOT because of specific issues with your TLS stack.  If it’s in your code and you have Sentinel Source, we’ll automatically report those once the CVE’s publish.

The post ROBOT: For When the Metal Ones Decide to Come for You appeared first on WhiteHat Security.

Read the whole story
karlosmid
7 hours ago
reply
Zagreb
Share this story
Delete

How to work with distributed teams

1 Share

For most people, especially old-school Agile devotees, distributed work is just impossible. According to some of them, interactions won’t be as productive, there will be knowledge silos, physical kanbans will not be possible, no one will pay attention to the flow, and everything is going to explode!

Well, those are all good points. Really. However, all of those are remediable. Nowadays you cannot say that distributed teams don’t work. You need to make it work! That is the reality of the world.

But enough of whys, let’s get to how. How can we remediate all those problems? Or even avoid them? How can we be agile without ever seeing each other?

Communicate, talk, say, share!

The first thing that you need to think about when working with distributed teams is communication. And since it is already difficult to improve it in a colocated team, you may imagine that the difficulty adjusting it in a distributed team is even higher, right? Not necessarily, actually. Those are different environments, with different challenges. And this difference is the key.

If you try to adapt what you do in a colocated team to use it in a distributed one, you’ll likely fail. Things like talking to someone at their desk is not the same as a private message on a channel, for example. In the first example, other people can hear you and enter the conversation if needed. A private message is like going to a sound-proof room with your colleague and talking about something. Therefore, keep an open mind and try new things. Below I list four things that you could change to improve your communication.

No more poking

Zach Holman calls that “remote first”. The idea is that you need to prioritize the use of asynchronous communication tools when in a distributed team. That means that those poking-and-talking meetings will be converted into written discussions, or video conferences, using your preferred communication tool.

“Oh, but we already use Slack!”

It is not about using it; it is prioritizing its use. And that is extremely difficult. Let’s say that you have five people on site and two offshore. Those onsite need to communicate every minimally important thing through the communication tool, with the preference for open channels and not private chats. Otherwise, you’ll develop an information silo, will decrease trust between people from different locations, etc.

Online meetings? Really?

Ceremonies and meetings are usually a dreadful experience when online, and there’s not much we can do about that… After all, the internet connection fails, you need to repeat everything ten times, the audio quality is never perfect, and it is just annoying to not interact with people.

However, there are some things that you can do to improve that experience. You need to have the right tools, and a clear goal for the meeting, you’ll find more on that in this blog post.

Besides that, each person should preferably be in their own machine, even if you have some people together in the same building. In my experience, people that are together in a room tend to share information while the microphone is muted. However, that information could be useful to the offshore team.

But one thing that I want to demystify is the necessity of meetings.

Please, only have meetings if you need them! And that is something to consider even in a colocated team. Most people start working with Scrum, Kanban or whatever methodology that comes with their set of necessary ceremonies. You need to think, and re-think, all the meetings objectives and check if they are necessary for your context. And if they are, check if all invited people are required. Don’t waste people’s time with unnecessary meetings.

But I’m in LA and she is in China!

If you have distributed teams in just one time zone, you are a lucky one. However, people usually have distributed teams across the entire world, going from 1 to sometimes 12 hours of difference. And each team needs to adapt their process to make sure that everyone receives the same information and participates in decisions over the future of the project.

The important point here is to stay as a team and try to have at least part of the day (or of the week if the time zones are too different), like an hour, that everyone is online. With that synchronized time you can put everyone on the same page.

Fly!

You’ll need to meet in person eventually. Not frequently though. Once a month, or even once a year, might be good enough. The idea of this encounter is to humanize people since we will often only interact with faces and texts on screen. That improves trust among everyone and brings the team back together. Think of it as a reset for group relationship. Bringing everyone together will relieve stress and improve interactions.

Different places, different cultures

Culture is a crucial point to consider when having distributed teams. We often expect people to behave as similarly as we would in the same circumstances, and it can break our expectations, hence, causing stress. I’ll detail two points that I often face in distributed teams that could help you.

Can I invite everyone to Carnival?

Whether you are hiring someone that will work remotely or are entering a team that has people from other countries, you need first to understand the countries’ differences. I’d suggest a comprehensive analysis of the country’s culture, how people usually behave when facing difficulties, how they say things (if directly or indirectly), what are their working times and related subjects. With all that information, you can manage your expectations and change your actions accordingly.

Hola, how você esta?

That is a very tough subject to address. What if you are working with team members that don’t speak the same language? Well, we’ve been there, and the answer is pretty simple: you need to communicate somehow, and it doesn’t matter how. Sometimes we opt for a common language, Esperanto most of the time (just kidding), and sometimes we try to learn the other person’s language if it is possible, like Spanish. But it doesn’t matter if you speak English, Latin or whatever. What is important is that, at the end of the day, you understood each other.

Just give them this bunch of tasks!

Especially when you have part of a team distributed in another region, it is common to have them as a “black-box team.” It is important to avoid scenarios in which you select demands for that team, instead of having the stories being pulled by whoever is free at the time. It is better not to have this kind of differentiation.

Ok, but what tools should I use?!

Before surrendering yourself to products that claim to be the silver-bullet for distributed teams, think about your process and how you can improve it. Then, if you need a tool, you’ll know what to search for.

However, if you want to know some of the tools you may need, we have an already extensive guide in this blog post. To make it easier for you, I’ll just mention some of the tools we use.

  • A video conference tool, like Hangouts with a microphone handler like Shoosh
  • An asynchronous conversation tool, like Slack
  • A place to put findings and documents, like Google Drive and/or Basecamp
  • A wiki like Confluence may also be useful
  • For your Kanban board, you may use something simpler like Trello or something with more options (but less customizable), like Jira.

Conclusion

The takeaway from this post is to improve communication and have empathy to understand the other. It is all about the process, not the tools you use.

I presented a huge number of things to do in a distributed team. Ergo, if you are seeking perfection you would need all of them, but to be better than yesterday, you just need to implement one at a time. 😉

Do you agree with our approach? Leave your thoughts below!

Subscribe to our blog
Read the whole story
karlosmid
7 hours ago
reply
Zagreb
Share this story
Delete

An epic treatise on scheduling, bug tracking, and triage

1 Share
Comments
Read the whole story
karlosmid
7 hours ago
reply
Zagreb
Share this story
Delete
Next Page of Stories